Re: #9794: inset-modify tabular commands are incorrectly disabled

2016-01-07 Thread Guillaume Munch 

Le 07/01/2016 22:09, Guillaume Munch a écrit :

Le 03/01/2016 09:46, Georg Baum a écrit :

We have a script for updating the docs, examples and templates
(development/tools/updatedocs.py), and one for updating the ui and bind
files (development/tools/updatelfuns.sh). Or did you man something else?



Is there a reason why the scripts do not have exec permissions? I
initially ran "sh updatelfuns.sh" and this failed, emptying a dozen of
files. After the second try I found that it requires bash, which would
have been chosen automatically if it had been possible to run
./updatelfuns.sh directly.



It is even more serious than I thought, because running it with sh has:
* copied every single file in the repository directory (including
untracked files) to file.old
* emptied hundreds of files (including untracked files)

Having to undo this is going to be a bit annoying but it could have been
worse. Thank you Richard for doing backups without even expecting that
this was going to happen :)

I do not wish to spend time finding out what exactly went wrong (if
someone wants to find out, my sh is Ubuntu's default which is dash) but
I suggest to add a check at the start of the script as per the attached
patch.

Is there any other script where I should add this check?


Guillaume
diff --git a/development/tools/updatelfuns.sh b/development/tools/updatelfuns.sh
index 04c8c02..f771328 100644
--- a/development/tools/updatelfuns.sh
+++ b/development/tools/updatelfuns.sh
@@ -1,5 +1,10 @@
 #!/bin/bash
 
+if [ -z "$BASH_VERSION" ]; then
+	echo "You must use bash to run this script";
+	exit 1;
+fi
+
 function do_convert {
 	for i in *; do 
 		if [ ! -f $i ]; then continue; fi

Re: why Babel with dvi3 (LuTeX)?

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 09:14:02PM +, Guenter Milde wrote:
> On 2016-01-07, Scott Kostyshak wrote:

> The patch requires updating. Here is a version, that works with
> d7ff8c6e18752.

I just tried to use "git apply" and I get:
$ git reset --hard 
HEAD is now at d7ff8c6 ctests: address some test failures.
$ git apply /tmp/testing.mbox
error: patch failed: development/autotests/suspiciousTests:71
error: development/autotests/suspiciousTests: patch does not apply
$

Looking at the diff, the line numbers do not look correct to me. But I
don't know the format of diff well so perhaps I made a mistake.

Are you sure you are able to apply it cleanly on d7ff8c6? Below is your
patch as I see it. Maybe something is wrong because it is an inline
patch. Perhaps the mail client or the settings I use are at fault.
Indeed, the ü does not appear correctly in the From: field. Perhaps I am
missing the correct encoding setting for mutt.

Can anyone else apply the patch cleanly to d7ff8c6?

Scott

From 30b0e71be55a9a4b8cd5554bf00894dd305c3b8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=BCnter=20Milde?= 
Date: Sun, 3 Jan 2016 23:28:08 +0100
Subject: [PATCH] Use polyglossia also with DVI (LuaTeX).

Simplify the logic for language package selection and make it more consistent:

Use polyglossia with non-TeX fonts (system fonts/Unicode fonts) for all
export flavours (XeTeX, LuaTeX, DVI-LuaTeX), if the language package setting
is "auto" and there is no language not supported by Babel and no package
providing Babel.

This solves some Babel-related autotest cases and leads to some new failures
due to the polyglossia language nesting problem.
---
 development/autotests/suspiciousTests | 47 ---
 development/autotests/unreliableTests |  2 +-
 src/BufferParams.cpp  |  7 ++
 src/LaTeXFeatures.cpp |  4 +--
 4 files changed, 16 insertions(+), 44 deletions(-)

diff --git a/development/autotests/suspiciousTests 
b/development/autotests/suspiciousTests
index 6ddf611..3640faa 100644
--- a/development/autotests/suspiciousTests
+++ b/development/autotests/suspiciousTests
@@ -61,8 +61,8 @@ export/doc/(es|fr)/UserGuide_pdf4_texF
 export/examples/uk/splash_(dvi3|pdf[45])_texF
 
 # missing commands (polyglossia?)
-# Explore! (works with dvi3 or language_package==babel)
-export/doc/fr/UserGuide_pdf[45]_systemF
+# Explore! (works with language_package==babel)
+export/doc/fr/UserGuide_.*_systemF
 
 # Bug in Babel-Spanish with Xe/LuaTeX and Unicode fonts:
 #
@@ -71,21 +71,11 @@ export/doc/fr/UserGuide_pdf[45]_systemF
 # Workaround: add a line to the user-preamble
 #   \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
 export/doc/es/UserGuide_.*_systemF
-#
-# Export with DVI (luatex) uses Babel instead of Polyglossia.
-# Don't use the above workaround here - these documents don't require Babel
-# problem should be solved by fixing auto-selection of language package.
-export/examples/es/ejemplo_con_lyx_dvi3_systemF
-# Galician shares some code with Babel-Spanish (including the bug).
-export/doc/gl/Tutorial_dvi3_systemF
-export/examples/gl/exemplo_lyxificado_dvi3_systemF
-# document language is Spanish: changing to Basque solves the problem
-export/examples/eu/adibide_lyx-atua_dvi3_systemF
 
 # Missing characters (U+0361, U+1E61) in LM,
 # set different system font in the source?
 # + language nesting problem (may disappear after completed translation)
-export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
+export/doc/(de/|es/|fr/)Customization_.*_systemF
 
 # Probably language mess
 export/export/ja/wrong_auto_encoding_(dvi|pdf(|3))
@@ -99,14 +89,6 @@ export/export/ja/wrong_auto_encoding_(dvi|pdf(|3))
 # \c e -> 0229 LATIN SMALL LETTER E WITH CEDILLA
 export/doc/(|de/|es/|fr/)Math.*systemF
 
-# 1.) Unknown Japanese char in section if previous
-# paragraph ended in non-Japaneese language
-# This is the same error as in export/export/ja/wrong_auto_encoding 
(unreliableTests)
-# 2.) unknown chars üß in selected encoding in 'This is a German word: Tschüß'
-#
-# Both reasons invalid since the commit 
6b0632eea288348b912f98b79bc871830b6a3d98
-#export/doc/ja/EmbeddedObjects_(dvi|pdf|pdf3)
-
 # missing character: There is no ^^A in font [lmroman12-regular]
 # and all the line down to ^^Z and beyond...
 # XeTeX artifact? works with LuaTeX, explore:
@@ -118,9 +100,9 @@ Sublabel: lyxbugs
 # LyX bugs with a Trac number.
 
 # Language nesting and polyglossia #9633
-export/doc/(nb|sk)/Intro_pdf[45]_systemF
+export/doc/(nb|sk)/Intro.*systemF
 # missing characters + language nesting (may disappear after completed 
translation)
-export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
+export/doc/(de/|es/|fr/)Customization_.*_systemF
 #
 # Language nesting, document is OK, fails because of a bug in LyX
 # document is still worng, did only fail because of latin language
@@ -129,16 +111,14 @@ export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
 
 
 # use LuaTeX-compatible

Re: [PATCH] Use \AA and \aa for "latin letter A with ring above".

2016-01-07 Thread Guenter Milde 
On 2016-01-06, Georg Baum wrote:
> Guenter Milde wrote:

> After experimenting a bit I found out that it is possible to translate all 
> variants without special code and without fallback if using \AA and \aa, so 
> I changed my mind.

...

>> Also, instead of special tex2lyx code just for \aa and \AA, we could use
>> NFC (or NFKC) normalization¹ after the "LyXification" - this would not
>> only map \r{A} to 00C5 (via 0041 030A) but also other similar cases of
>> non-unique LICRs for pre-composed accented characters.

> I was about to write that we do not have code for doing that, but then a 
> vague memory appeared that I dealt with normalization in the past, and we do 
> indeed have normalize_c() in docstring.h, which does exactly what we want.

This is good news.

> The attached patch fixes all issues:
> - A new flag "deprecated" is introduced which makes it explicit that a 
> certain symbol should not be used for LaTeX => char_type conversion. It is 
> not strictly needed for U+00C5 vs. U+212B, since U+212B > U+00C5, but will 
> be useful for other symbols.
> - \AA and \aa are used in lib/unicodesymbols exclusively. This adds \aa to 
> the known symbols of tex2lyx
> - Apply normalization to precomposed form in tex2lyx for symbols from 
> lib/unicodesymbols, since editing in LyX is easier with precomposed symbols.

> OK?

To me, the patch looks OK.

Whether the new "deprecated" tag should go directly into 2.2.0 or wait a bit
is up to Scott (and may depend on the result of our autotests).

Thanks,
Günter

Re: Status on Mac with El Capitan

2016-01-07 Thread Kornel Benko 
Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes 

> Le 06/01/2016 11:09, Kornel Benko a écrit :
> >> It would be nice if we could converge to the same algorithm in the two
> >> build systems. If you disagree on what autotools do, we can discuss
> >> adaptations.
> >
> > In cmake it is an option, which is set _before_ we know the compiler.
>
> Actually it is the same in autotools, but the default value is "auto" :)
>
> > I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not 
> > confident enough to change it for MSVC.
>
> It would be a very good way to din out. People can always override it if
> the default is not correct...
>
> JMarc

The attached works for me. Cmake-gui looks good, deafault for  LYX_ENABLE_CXX11 
is string "AUTO".

Starting with empty CMakeCache.txt the variable LYX_ENABLE_CXX11 is saved as of 
type STRING.
Using already used (created before the patch) CMakeCache.txt it is saved as of 
type BOOL. Although this
is now wrong, it still works. One only cannot select "AUTO" in the cmake-gui.

Kornel

signature.asc
Description: This is a digitally signed message part.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f657fd5..ce35a53 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -140,6 +140,7 @@ LYX_OPTION(ENABLE_EXPORT_TESTS "Enable for export tests" OFF ALL)
 LYX_OPTION(ASAN "Use address sanitizer" OFF ALL)
 LYX_COMBO(USE_QT"Use Qt version as frontend" QT4 QT5)
 LYX_OPTION(3RDPARTY_BUILD   "Build 3rdparty libs" OFF ALL)
+LYX_COMBO(ENABLE_CXX11  "Build with options for c++11-mode" AUTO ON OFF)
 
 # GCC specific
 LYX_OPTION(PROFILE  "Build profile version" OFF GCC)
@@ -149,7 +150,6 @@ LYX_OPTION(DEBUG_GLIBC  "Enable libstdc++ debug mode" OFF GCC)
 LYX_OPTION(DEBUG_GLIBC_PEDANTIC "Enable libstdc++ pedantic debug mode" OFF GCC)
 LYX_OPTION(STDLIB_DEBUG "Use debug stdlib" OFF GCC)
 LYX_OPTION(PROFILE  "Build with options for gprof" OFF GCC)
-LYX_OPTION(ENABLE_CXX11 "Build with options for c++11-mode" OFF GCC)
 
 # MSVC specific
 LYX_OPTION(CONSOLE   "Show console on Windows, enforce with =FORCE" ON MSVC)
@@ -251,7 +251,29 @@ else()
 	set(LIBRARY_OUTPUT_PATH  ${TOP_BINARY_DIR}/lib)
 endif()
 
-
+if(LYX_ENABLE_CXX11 MATCHES "AUTO")
+  # Set to some meaningful default
+  find_package(CXX11Compiler)
+  if(NOT CXX11COMPILER_FOUND)
+set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
+  else()
+if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
+  execute_process(COMMAND ${CMAKE_CXX_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE)
+  if(NOT GCC_VERSION VERSION_LESS 4.3)
+set(LYX_ENABLE_CXX11 ON CACHE TYPE STRING FORCE)
+  else()
+set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
+  endif()
+else()
+  # Not a gnu compiler
+  if(CMAKE_CXX_COMPILER_ID MATCHES "^[cC]lang$")
+set(LYX_ENABLE_CXX11 ON CACHE TYPE STRING FORCE)
+  else()
+set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
+  endif()
+endif()
+  endif()
+endif()
 set(LYX_GCC11_MODE)
 if(UNIX OR MINGW)
 	execute_process(COMMAND ${CMAKE_CXX_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE)

Re: Status on Mac with El Capitan

2016-01-07 Thread Kornel Benko 
Stefan, are you sure using clean build-dir?
At least CMakeCache.txt may contain some include paths from previous run.
For instance changing -DLYX_EXTERNAL_BOOST=.. without removing CMakeCache.txt 
is asking for trouble IMHO.

Am Donnerstag, 7. Januar 2016 um 13:46:42, schrieb Stephan Witt 

> Am 07.01.2016 um 11:01 schrieb Kornel Benko :
> > 
> > Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes 
> > 
> >> Le 06/01/2016 11:09, Kornel Benko a écrit :
>  It would be nice if we could converge to the same algorithm in the two
>  build systems. If you disagree on what autotools do, we can discuss
>  adaptations.
> >>> 
> >>> In cmake it is an option, which is set _before_ we know the compiler.
> >> 
> >> Actually it is the same in autotools, but the default value is "auto" 
> >> 
> >>> I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not 
> >>> confident enough to change it for MSVC.
> >> 
> >> It would be a very good way to din out. People can always override it if 
> >> the default is not correct...
> >> 
> >> JMarc
> > 
> > The attached works for me. Cmake-gui looks good, deafault for  
> > LYX_ENABLE_CXX11 is string "AUTO".
> > 
> > Starting with empty CMakeCache.txt the variable LYX_ENABLE_CXX11 is saved 
> > as of type STRING.
> > Using already used (created before the patch) CMakeCache.txt it is saved as 
> > of type BOOL. Although this
> > is now wrong, it still works. One only cannot select "AUTO" in the 
> > cmake-gui.
> > 
> >   Kornel
> 
> With the patch CXX11_FLAG_DETECTED works but is reported twice to console.
> 
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done

Yes, I had to duplicate the code to be used for "AUTO"-case too.
This happens only on first cmake run though.

> -- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register"
> -- Found CXX11Compiler: --std=c++11 -Wno-deprecated-register  
> -- Using GCC version 4.2.1
> -- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register"
> -- Found Qt-Version 5.4.2
> -- Looking for magic_file
> -- Looking for magic_file - found
> 
> On my Mac with latest El Capitan the resulting Xcode project is
> not usable because of an compiler error:
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2075:40:
>  Constructor for 
> 'std::__1::__libcpp_compressed_pair_imp const lyx::Toc, 1>' must explicitly initialize the const member '__second_'
> 
> I cannot tell if this is a compiler bug but is seems so.
> 
> Alternatively I can disable CXX11 with -DLYX_ENABLE_CXX11=OFF.
> Then I’m back to the linker problem because of the conflicting
> versions of the system (external) and the LyX 3rdparty boost.
> 
> The error message are like this:
> 
> Undefined symbols for architecture x86_64:
>   "boost::re_detail::get_mem_block()", referenced from:
>   
> boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**,
>  boost::re_detail::saved_state**) in LayoutFile.o
>   boost::re_detail::perl_matcher std::__1::allocator >, 
> boost::regex_traits >::extend_stack() 
> in LayoutFile.o
>   
> boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**,
>  boost::re_detail::saved_state**) in ExternalTransforms.o
>   boost::re_detail::perl_matcher std::__1::allocator >, 
> boost::regex_traits >::extend_stack() 
> in ExternalTransforms.o
>   boost::re_detail::perl_matcher std::__1::allocator >, 
> boost::regex_traits >::extend_stack() 
> in Preamble.o
>   
> boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**,
>  boost::re_detail::saved_state**) in Preamble.o

This is linking for lyx I suppose?
Could you post the linker line
# make VERBOSE=1 lyx

or/and try to find the correct link command manually?
Maybe compare with autotools make output?

> If I add -DLYX_EXTERNAL_BOOST=ON the build stops with this error:
> 
> In file included from 
> /Users/stephan/git/lyx/src/insets/ExternalTemplate.cpp:14:
> In file included from /Users/stephan/git/lyx/src/insets/ExternalTemplate.h:16:
> /Users/stephan/git/lyx/src/insets/ExternalTransforms.h:19:10: fatal error: 
> 'boost/any.hpp' file not found
> #include 
>  ^
> 1 error generated.
> 
> The question is now: why does it work on the same system with auto tools?
> Probably it works because of using LyX internal boost and passing the
> proper include locations to the compiler calls.

See what I wrote at begin of this mail.

> ATM,

Re: Status on Mac with El Capitan

2016-01-07 Thread Stephan Witt 
Am 07.01.2016 um 14:51 schrieb Kornel Benko :
> 
> Am Donnerstag, 7. Januar 2016 um 14:30:58, schrieb Stephan Witt 
> 
>> The position of -I/opt/local/linclude in front of 
>> -I/Users/stephan/git/lyx/3rdparty/boost is the problem.
>> I wrote this in my previous mail.
> 
> This should be easy
> 
> in CMakeLists.txt:738
> substitute
>   include_directories(${TOP_SRC_DIR}/3rdparty/boost)
> with
>   include_directories(BEFORE ${TOP_SRC_DIR}/3rdparty/boost)
> or even
>   include_directories(BEFORE SYSTEM ${TOP_SRC_DIR}/3rdparty/boost)

It didn’t help.

The following (inline) patch helps to build tex2lyx:

diff --git a/src/tex2lyx/CMakeLists.txt b/src/tex2lyx/CMakeLists.txt
index 09bcc2b..f4a9841 100644
--- a/src/tex2lyx/CMakeLists.txt
+++ b/src/tex2lyx/CMakeLists.txt
@@ -24,7 +24,7 @@ file(GLOB tex2lyx_sources 
${TOP_SRC_DIR}/src/tex2lyx/${LYX_CPP_FILES})
 
 file(GLOB tex2lyx_headers ${TOP_SRC_DIR}/src/tex2lyx/${LYX_HPP_FILES})
 
-include_directories(BEFORE
+include_directories(
${TOP_SRC_DIR}/src/tex2lyx
${TOP_SRC_DIR}/src/support/minizip
${ZLIB_INCLUDE_DIR})

The next problem now is an error when compiling src/Compare.cpp:

Stephan

===
CompileC 
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.o
 src/Compare.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/stephan/git/lyx
export LANG=en_US.US-ASCII

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
 -x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack 
-fmacro-backtrace-limit=0 -Wno-trigraphs -fpascal-strings -O0 
-Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type 
-Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors 
-Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function 
-Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value 
-Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow 
-Wno-four-char-constants -Wno-conversion -Wno-constant-conversion 
-Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion 
-Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions 
-DCMAKE_INTDIR=\"Debug\" -DQT_CORE_LIB -DQT_GUI_LIB 
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DQT_WIDGETS_LIB -DQT_CONCURRENT_LIB 
-DQT_SVG_LIB -DQT_MACEXTRAS_LIB -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
 -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof 
-mmacosx-version-min=10.11 -g -Wno-sign-conversion 
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug/include 
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev -I/Users/stephan/git/lyx/src 
-I/Users/Shared/LyX/utilities/include -I/Users/stephan/git/lyx/3rdparty/boost 
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src -I/opt/local/include 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtCore.framework/Headers
 -I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/mkspecs/macx-clang 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtGui.framework/Headers
 
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Headers
 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtWidgets.framework/Headers
 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtConcurrent.framework/Headers
 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtSvg.framework/Headers
 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtMacExtras.framework/Headers
 
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/DerivedSources/x86_64
 
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/DerivedSources
 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas 
-F/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug 
-F/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib -Wall 
-Wunused-parameter -fno-strict-aliasing -Wall -Wunused-parameter 
-fno-strict-aliasing -D_DEBUG -fPIC -DBOOST_USER_CONFIG= -MMD -MT 
dependencies -MF 
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.d
 --serialize-diagnostics 
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.dia
 -c /Users/stephan/git/lyx/src/Compare.cpp -o 
/Users/stephan/git/lyx-build/cmake/2.2.0dev/src/LyX.build/Debug/LyX.build/Objects-normal/x86_64/Compare.o

/Users/stephan/git/lyx/src/Compare.cpp:425:25: error: call to 'next' is 
ambiguous
ParagraphList tmp_pars(next(ps_.begin(), startpit),
   ^~~~
In file included from /Users/stephan/git/lyx/src/Compare.cpp:13:
In file included from /Users/stephan/git/lyx/src/Compare.h:15:
In file included from /Users/stephan/git/lyx/src/Buffer.h:16:
In

Re: Status on Mac with El Capitan

2016-01-07 Thread Stephan Witt 
Am 07.01.2016 um 11:01 schrieb Kornel Benko :
> 
> Am Mittwoch, 6. Januar 2016 um 11:39:10, schrieb Jean-Marc Lasgouttes 
> 
>> Le 06/01/2016 11:09, Kornel Benko a écrit :
 It would be nice if we could converge to the same algorithm in the two
 build systems. If you disagree on what autotools do, we can discuss
 adaptations.
>>> 
>>> In cmake it is an option, which is set _before_ we know the compiler.
>> 
>> Actually it is the same in autotools, but the default value is "auto" :)
>> 
>>> I could change it for UNIX (with clang | gnu-c++) or MINGW, but I am not 
>>> confident enough to change it for MSVC.
>> 
>> It would be a very good way to din out. People can always override it if 
>> the default is not correct...
>> 
>> JMarc
> 
> The attached works for me. Cmake-gui looks good, deafault for  
> LYX_ENABLE_CXX11 is string "AUTO".
> 
> Starting with empty CMakeCache.txt the variable LYX_ENABLE_CXX11 is saved as 
> of type STRING.
> Using already used (created before the patch) CMakeCache.txt it is saved as 
> of type BOOL. Although this
> is now wrong, it still works. One only cannot select "AUTO" in the cmake-gui.
> 
>   Kornel

With the patch CXX11_FLAG_DETECTED works but is reported twice to console.

-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- 
-- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register"
-- Found CXX11Compiler: --std=c++11 -Wno-deprecated-register  
-- Using GCC version 4.2.1
-- CXX11_FLAG_DETECTED = "--std=c++11 -Wno-deprecated-register"
-- Found Qt-Version 5.4.2
-- Looking for magic_file
-- Looking for magic_file - found

On my Mac with latest El Capitan the resulting Xcode project is
not usable because of an compiler error:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2075:40:
 Constructor for 
'std::__1::__libcpp_compressed_pair_imp' must explicitly initialize the const member '__second_'

I cannot tell if this is a compiler bug but is seems so.

Alternatively I can disable CXX11 with -DLYX_ENABLE_CXX11=OFF.
Then I’m back to the linker problem because of the conflicting
versions of the system (external) and the LyX 3rdparty boost.

The error message are like this:

Undefined symbols for architecture x86_64:
  "boost::re_detail::get_mem_block()", referenced from:
  
boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**,
 boost::re_detail::saved_state**) in LayoutFile.o
  boost::re_detail::perl_matcher >, 
boost::regex_traits >::extend_stack() in 
LayoutFile.o
  
boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**,
 boost::re_detail::saved_state**) in ExternalTransforms.o
  boost::re_detail::perl_matcher >, 
boost::regex_traits >::extend_stack() in 
ExternalTransforms.o
  boost::re_detail::perl_matcher >, 
boost::regex_traits >::extend_stack() in 
Preamble.o
  
boost::re_detail::save_state_init::save_state_init(boost::re_detail::saved_state**,
 boost::re_detail::saved_state**) in Preamble.o

If I add -DLYX_EXTERNAL_BOOST=ON the build stops with this error:

In file included from /Users/stephan/git/lyx/src/insets/ExternalTemplate.cpp:14:
In file included from /Users/stephan/git/lyx/src/insets/ExternalTemplate.h:16:
/Users/stephan/git/lyx/src/insets/ExternalTransforms.h:19:10: fatal error: 
'boost/any.hpp' file not found
#include 
 ^
1 error generated.

The question is now: why does it work on the same system with auto tools?
Probably it works because of using LyX internal boost and passing the
proper include locations to the compiler calls.

ATM, cmake passes the include locations that way:

-I/Users/stephan/git/lyx-build/cmake/2.2.0dev/bin/Debug/include
-I/opt/local/include
-I/Users/stephan/git/lyx/src/support/minizip
-I/Users/stephan/git/lyx/src/tex2lyx
-I/Users/stephan/git/lyx-build/cmake/2.2.0dev
-I/Users/stephan/git/lyx/src
-I/Users/Shared/LyX/utilities/include
-I/Users/stephan/git/lyx/3rdparty/boost 
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtCore.framework/Headers
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/mkspecs/macx-clang
-I/Users/Shared/LyX/qt-5.4.2-frameworks-cocoa-x86_64/lib/QtGui.framework/Headers
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Headers

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 02:30:58PM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > > > These versions produce the error for me:
> > > > 
> > > > $ ./autogen.sh 
> > > > Using automake (GNU automake) 1.14.1
> > > > Using autoconf (GNU Autoconf) 2.69
> > > > 
> > > > 
> > > > Georg
> > > 
> > > I have the same, with the error too.
> > 
> > I have the same as Kornel and Georg.
> 
> And you don't observe this problem for 2.1.x, right? P

I do observe this problem on 2.1.x.

Scott


signature.asc
Description: PGP signature

ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

2016-01-07 Thread Guenter Milde 
Dear Kornel,

thanks for running the tests.

On 2016-01-07, Kornel Benko wrote:

> Failed tests before patch:
>   1145:MANUALS_export/doc/he/Intro_pdf5_texF
>   1146:MANUALS_export/doc/he/Intro_pdf5_systemF
>   1158:MANUALS_export/doc/he/Tutorial_pdf5_texF
>   1159:MANUALS_export/doc/he/Tutorial_pdf5_systemF

>   3221:EXAMPLES_export/examples/he/example_lyxified_pdf5_texF
>   3222:EXAMPLES_export/examples/he/example_lyxified_pdf5_systemF
>   3234:EXAMPLES_export/examples/he/example_raw_pdf5_texF
>   3235:EXAMPLES_export/examples/he/example_raw_pdf5_systemF
>   3247:EXAMPLES_export/examples/he/splash_pdf5_texF
>   3248:EXAMPLES_export/examples/he/splash_pdf5_systemF

It seems as if a recent update changed behaviour regarding LuaTeX and Hebrew 
-- at least Scott reported that he/splash_pdf5_systemF worked on his site and
I changed the filter in fb11ac511f9.

Maybe we should add a pattern 

  export/(doc|examples)/he/.*pdf5.*
  
to "unreliableTests" for now.

The following failures should dissapear after the just commited patch
d7ff8c6e/lyxgit.

>   
> 2954:INVERTED.EXAMPLES.TODO_export/examples/eu/adibide_lyx-atua_dvi3_systemF

Fixed the problem in 110f505b63

>   3111:EXAMPLES_export/examples/fr/linguistics_dvi3_systemF
>   3116:EXAMPLES_export/examples/fr/linguistics_pdf4_systemF
>   3118:EXAMPLES_export/examples/fr/linguistics_pdf5_systemF

Language nesting problem with polyglossia (may disappear after completed
translation).

I hope we will get a "failure free" test suite soon.

Günter

Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

2016-01-07 Thread Kornel Benko 
Am Donnerstag, 7. Januar 2016 um 17:22:09, schrieb Guenter Milde 

> Dear Kornel,
> 
> thanks for running the tests.
> 
> On 2016-01-07, Kornel Benko wrote:
> 
> > Failed tests before patch:
> > 1145:MANUALS_export/doc/he/Intro_pdf5_texF
> > 1146:MANUALS_export/doc/he/Intro_pdf5_systemF
> > 1158:MANUALS_export/doc/he/Tutorial_pdf5_texF
> > 1159:MANUALS_export/doc/he/Tutorial_pdf5_systemF
> 
> > 3221:EXAMPLES_export/examples/he/example_lyxified_pdf5_texF
> > 3222:EXAMPLES_export/examples/he/example_lyxified_pdf5_systemF
> > 3234:EXAMPLES_export/examples/he/example_raw_pdf5_texF
> > 3235:EXAMPLES_export/examples/he/example_raw_pdf5_systemF
> > 3247:EXAMPLES_export/examples/he/splash_pdf5_texF
> > 3248:EXAMPLES_export/examples/he/splash_pdf5_systemF
> 
> It seems as if a recent update changed behaviour regarding LuaTeX and Hebrew 
> -- at least Scott reported that he/splash_pdf5_systemF worked on his site and
> I changed the filter in fb11ac511f9.
> 
> Maybe we should add a pattern 
> 
>   export/(doc|examples)/he/.*pdf5.*
>   
> to "unreliableTests" for now.

Wait a moment. In an another (luatex) list Scott is investigating too. Looks 
like some defines
would be sufficient to compile with lualatex too.
% prior to specifying document class
\let\luatexpardir\pardir
\let\luatextextdir\textdir

\documentclass[english,hebrew]{article}
...

> The following failures should dissapear after the just commited patch
> d7ff8c6e/lyxgit.
> 
> > 
> > 2954:INVERTED.EXAMPLES.TODO_export/examples/eu/adibide_lyx-atua_dvi3_systemF
> 
> Fixed the problem in 110f505b63
> 
> > 3111:EXAMPLES_export/examples/fr/linguistics_dvi3_systemF
> > 3116:EXAMPLES_export/examples/fr/linguistics_pdf4_systemF
> > 3118:EXAMPLES_export/examples/fr/linguistics_pdf5_systemF
> 
> Language nesting problem with polyglossia (may disappear after completed
> translation).
> 
> I hope we will get a "failure free" test suite soon.
> 
> Günter

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: lyx2lyx bug: duplicating some lyx properties

2016-01-07 Thread José Matos 
On Sunday, January 03, 2016 04:32:49 AM Scott Kostyshak wrote:
> Hopefully we can make progress on unit tests in the 2.3 cycle, for both
> lyx2lyx and our C++ code and anything else. I would be happy to
> eventually learn the testing framework and try to contribute.

+1

I wholeheartedly agree with Georg regarding lyx2lyx testing improvements.
 
> > PS: Happy new year to all!
> 
> Happy new year!
> 
> Scott

Happy new year to all! :-)

-- 
José Abílio

Re: why Babel with dvi3 (LuTeX)?

2016-01-07 Thread Guenter Milde 
On 2016-01-08, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> On Thu, Jan 07, 2016 at 09:14:02PM +, Guenter Milde wrote:
>> On 2016-01-07, Scott Kostyshak wrote:

>> The patch requires updating. Here is a version, that works with
>> d7ff8c6e18752.

> I just tried to use "git apply" and I get:
> $ git reset --hard 
> HEAD is now at d7ff8c6 ctests: address some test failures.
> $ git apply /tmp/testing.mbox
> error: patch failed: development/autotests/suspiciousTests:71
> error: development/autotests/suspiciousTests: patch does not apply
> $

> Looking at the diff, the line numbers do not look correct to me. But I
> don't know the format of diff well so perhaps I made a mistake.

> Are you sure you are able to apply it cleanly on d7ff8c6? Below is your
> patch as I see it. Maybe something is wrong because it is an inline
> patch. Perhaps the mail client or the settings I use are at fault.
> Indeed, the ü does not appear correctly in the From: field. Perhaps I am
> missing the correct encoding setting for mutt.

> Can anyone else apply the patch cleanly to d7ff8c6?

Sorry, I sent the outdated patch. Could you re-try with the version below?

Günter

>From 2d0ff841a87f1aa8159ad209a29700d5a2c0e048 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=BCnter=20Milde?= 
Date: Sun, 3 Jan 2016 23:28:08 +0100
Subject: [PATCH] Use polyglossia also with DVI (LuaTeX).

Simplify the logic for language package selection and make it more consistent:

Use polyglossia with non-TeX fonts (system fonts/Unicode fonts) for all
export flavours (XeTeX, LuaTeX, DVI-LuaTeX), if the language package setting
is "auto" and there is no language not supported by Babel and no package
providing Babel.

This solves some Babel-related autotest cases and leads to some new failures
due to the polyglossia language nesting problem.
---
 development/autotests/suspiciousTests | 45 +--
 development/autotests/unreliableTests |  2 +-
 src/BufferParams.cpp  |  7 ++
 src/LaTeXFeatures.cpp |  4 ++--
 4 files changed, 16 insertions(+), 42 deletions(-)

diff --git a/development/autotests/suspiciousTests 
b/development/autotests/suspiciousTests
index fd84a94..b8c9bf2 100644
--- a/development/autotests/suspiciousTests
+++ b/development/autotests/suspiciousTests
@@ -48,8 +48,8 @@ export/doc/(es|fr)/UserGuide_pdf4_texF
 export/examples/uk/splash_(dvi3|pdf[45])_texF
 
 # missing commands (polyglossia?)
-# Explore! (works with dvi3 or language_package==babel)
-export/doc/fr/UserGuide_pdf[45]_systemF
+# Explore! (works with language_package==babel)
+export/doc/fr/UserGuide_.*_systemF
 
 # Bug in Babel-Spanish with Xe/LuaTeX and Unicode fonts:
 #
@@ -58,19 +58,11 @@ export/doc/fr/UserGuide_pdf[45]_systemF
 # Workaround: add a line to the user-preamble
 #   \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
 export/doc/es/UserGuide_.*_systemF
-#
-# Export with DVI (luatex) uses Babel instead of Polyglossia.
-# Don't use the above workaround here - these documents don't require Babel
-# problem should be solved by fixing auto-selection of language package.
-export/examples/es/ejemplo_con_lyx_dvi3_systemF
-# Galician shares some code with Babel-Spanish (including the bug).
-export/doc/gl/Tutorial_dvi3_systemF
-export/examples/gl/exemplo_lyxificado_dvi3_systemF
 
 # Missing characters (U+0361, U+1E61) in LM,
 # set different system font in the source?
 # + language nesting problem (may disappear after completed translation)
-export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
+export/doc/(de/|es/|fr/)Customization_.*_systemF
 
 # Probably language mess
 export/export/ja/wrong_auto_encoding_(dvi|pdf(|3))
@@ -84,14 +76,6 @@ export/export/ja/wrong_auto_encoding_(dvi|pdf(|3))
 # \c e -> 0229 LATIN SMALL LETTER E WITH CEDILLA
 export/doc/(|de/|es/|fr/)Math.*systemF
 
-# 1.) Unknown Japanese char in section if previous
-# paragraph ended in non-Japaneese language
-# This is the same error as in export/export/ja/wrong_auto_encoding 
(unreliableTests)
-# 2.) unknown chars üß in selected encoding in 'This is a German word: Tschüß'
-#
-# Both reasons invalid since the commit 
6b0632eea288348b912f98b79bc871830b6a3d98
-#export/doc/ja/EmbeddedObjects_(dvi|pdf|pdf3)
-
 # missing character: There is no ^^A in font [lmroman12-regular]
 # and all the line down to ^^Z and beyond...
 # XeTeX artifact? works with LuaTeX, explore:
@@ -125,22 +109,20 @@ Sublabel: lyxbugs
 # LyX bugs with a Trac number.
 
 # Language nesting and polyglossia #9633
-export/doc/(nb|sk)/Intro_pdf[45]_systemF
+export/doc/(nb|sk)/Intro.*systemF
 # language nesting (may disappear after completed translation)
 export/examples/fr/linguistics_.*_systemF
-export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
+export/doc/(de/|es/|fr/)Customization_.*_systemF
 
 # use LuaTeX-compatible language names #9910
-# Wrong language name for LuaTeX
+# Wrong language name for LuaTeX (with Babel, no error

Re: Can anyone build with mingw?

2016-01-07 Thread Stephan Witt 
Am 07.01.2016 um 19:04 schrieb Scott Kostyshak :
> 
> On Wed, Jan 06, 2016 at 06:58:37PM +0100, Peter Kümmel wrote:
>> 
>> 
>> Am 28.12.2015 um 14:48 schrieb Scott Kostyshak:
 Ah, the cmakebin variable is not set, a rest of the bot script. Replacing 
 the variable by cmake should fix it.
>> 
>> committed this.
>> 
>>> 
>>> Yes this was the problem. There seem to be several unset variables. Can
>>> we use
>>> set -u
>>> with /bin/sh or is that only for bash?
>>> For example, $ver is not set for me.
>> 
>> set -u also stops when there is a test for $1, $2, or if a variable is not
>> set by design, so it could not be used.
> 
> I'm fine without it, but I note that you can set on/off. For
> example (untested):
> 
> set -u
> 
> ...
> 
> set +u
> if [ -z $1 ]
> then
>echo "Usage: xmingw "
>exit 1
> fi
> set +u

A working (and perhaps more accurate?) solution

if [ $# -eq 0 ]
then
  echo "Usage: xmingw "
  exit 1
elif [ -z $1 ]
then
  echo "Invalid value for "
  exit 2
fi

Stephan

Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)

2016-01-07 Thread Guenter Milde 
On 2016-01-07, Scott Kostyshak wrote:
> On Thu, Jan 07, 2016 at 06:31:11PM +0100, Kornel Benko wrote:
>> Am Donnerstag, 7. Januar 2016 um 17:22:09, schrieb Guenter Milde 
>> 

>> > Maybe we should add a pattern 
>> > 
>> >   export/(doc|examples)/he/.*pdf5.*
>> >   
>> > to "unreliableTests" for now.

>> Wait a moment. In an another (luatex) list Scott is investigating too.
>> Looks like some defines would be sufficient to compile with lualatex
>> too.

>> % prior to specifying document class
>> \let\luatexpardir\pardir
>> \let\luatextextdir\textdir

>> \documentclass[english,hebrew]{article}

> Indeed. The relevant thread is here:
> http://tug.org/pipermail/luatex/2016-January/005591.html

> I don't have an opinion as for whether to change the .lyx file or to
> treat the test as unreliable. 

I don't think this can be fixed in the .lyx file, because I don't know of a
way to specify something to be printed before the \documentclass line!


Generally,

* if the example/template/documentation source can be made more robust
  without becoming "hackish" --> fix the source
  
* if the test machinery would need to be changed to "massage" a source to
  compile --> invert the test case


* if LyX could be enhanced to care for a permanent TeX limitation
  --> file a ticket at track and invert the test case (inverted:lyxbug)
  
* if a temporary TeX issue could be fixed by special-case handling in
  LyX but is rather a corner case --> invert the test case (inverted:texissues)


Specifically:

* I don't think this merits special-case code in LyX to prepend these
  lines if Hebrew is compiled with luatex.

  The above linked message says "*until the package is updated* you can
  simply alias the old name, ...". So we would add a hack for a temporary
  failure with a non-supported output format (polyglossia says
  Hebrew+LuaTeX is unsupported).

* FreeSans seems to provide the correct script-support info not to trigger
  the false-positive error http://www.lyx.org/trac/ticket/8035
  
  However, setting all of "mainfont", "sansfont", and "monofont" to FreeSans
  seems "hackish" to me.

> So whatever you guys decide is fine with me.

My suggestion depends on how you (Scott) get the Hebrew documents to compile:

* special code in the test machinery (replacements or additions to the LyX
  source or the exported .tex file), 
  
  -> remove special code and re-activate the patterns in "suspiciousTests"
  
* you have an old TeXLive version where this works

  -> move patterns to "unreliabelTests"
  
* it does not longer work after updating TeXLive 

  -> re-activate the patterns in "suspiciousTests"


In any case, I propose to replace the special code setting system fonts
in the test scripts with "non-hackish"¹ system font settings in the
sources (for manuals this requires Uwe's approval).

¹ For Hebrew, this means that if there is no working free serif font, we
  should invert the affected tests as "lyxbug" #8035 instead of using
  a sans-serif font as serif!
  
  Alternatively, we could try if the examples work with Babel (and
  produce correct output) and set "always Babel" in the sources.

Thanks,

Günter

Re: [PATCH] Use \AA and \aa for "latin letter A with ring above".

2016-01-07 Thread Georg Baum 
Guenter Milde wrote:

> On 2016-01-07, Kornel Benko wrote:
>> Am Donnerstag, 7. Januar 2016 um 11:47:16, schrieb Guenter Milde
>> 
> 
>>> Whether the new "deprecated" tag should go directly into 2.2.0 or wait
>>> a bit is up to Scott (and may depend on the result of our autotests).

Scott, what do you prefer? The keyword is not required for the fix, so it 
can also wait for 2.3

> Fine. I vote for OK for 2.2.0.

Thanks.


Georg

Re: Keywords required for the software center

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 08:07:18PM +, Richard Hughes wrote:
> On 7 January 2016 at 18:21, Scott Kostyshak  wrote:
> > I think we already do this. Here is our current lyx.desktop.in file:
> > http://git.lyx.org/?p=lyx.git;a=blob_plain;f=lib/lyx.desktop.in;hb=HEAD
> 
> You do, apologies for the noise. I've filed a Fedora bug asking why
> the upstream file isn't being used:
> https://bugzilla.redhat.com/show_bug.cgi?id=1296679

The change was just made on March 17 of 2015. It is in LyX 2.1.4 and
will be in every later version. For details, see:

http://www.lyx.org/trac/ticket/9414

Scott


signature.asc
Description: PGP signature

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Scott Kostyshak 
On Wed, Jan 06, 2016 at 02:22:35PM -0800, Pavel Sanda wrote:
> Georg Baum wrote:
> > Pavel Sanda wrote:
> > 
> > > Scott Kostyshak wrote:
> > >> (although I still don't understand why). I get another instance of the
> > >> same error though when using a build directory instead of an in-source
> > >> build.
> > > 
> > > Recipe? P
> > 
> > Starting from the top level source directory:
> > 
> > ./autogen.sh
> > mkdir buildtest
> > cd buildtest
> > ../configure
> > make distcheck
> > 
> > But since 'make distcheck' works if it is run directly in the source 
> > directory it is probably no show stopper for the beta (but we should create 
> > a bug in trac).
> 
> Still can't reproduce on the current HEAD,
> you use git clean -xdf before your recipy, right?
> Pavel

I just tried the current HEAD (ac1cd1ad) and I can still reproduce.

To use the exact commands that I run, run the following commands. Note the
possible consequences (e.g. git reset --hard and git clean -xdf will cause you
to lose any unsaved work). You just need to change the two instances of
/path/to/git/repo

---
mkdir /tmp/tmp.EI1jW3t6A1
cd /path/to/git/repo
git reset --hard
git clean -xdf
./autogen.sh
cd /tmp/tmp.EI1jW3t6A1 && /path/to/git/repo/configure --enable-build-type=pre 
--enable-monolithic-build=no
make -j4
make -j4 check
make -j4 distcheck
echo $?
---

Note that I can reproduce it with many other specifications (e.g. configure 
options).

Can you reproduce now?

Scott


signature.asc
Description: PGP signature

Re: why Babel with dvi3 (LuTeX)?

2016-01-07 Thread Scott Kostyshak 
On Mon, Jan 04, 2016 at 08:21:51PM +, Guenter Milde wrote:

> > Is the patch made with 'git am ' committed, or only applied?
> 
> Commited. However, "git apply" will also work with an inline patch if passed
> the saved message in mbox format (as does the standard "patch" command).

Sorry for not getting to this yet. Is this patch still pending? If so,
can you confirm that the patch still applies cleanly (after recent
changes to master)? Once you do that, I will run the tests before/after
the patch.

Thanks,

Scott


signature.asc
Description: PGP signature

Re: Keywords required for the software center

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 02:15:54AM -0800, Richard Hughes (semi-automated) wrote:

> So, what do I want you to do? Basically, I would like you to add some 
> keywords in the lyx.desktop file

Hi Richard,

I think we already do this. Here is our current lyx.desktop.in file:
http://git.lyx.org/?p=lyx.git;a=blob_plain;f=lib/lyx.desktop.in;hb=HEAD

The keywords line is:
Keywords=WYSIWYG;WYSIWYM;TeX;LaTeX;GUI;frontend;editor;

Best,

Scott


signature.asc
Description: PGP signature

Re: ctests update: TL update fixes a test

2016-01-07 Thread Kornel Benko 
Am Donnerstag, 7. Januar 2016 um 13:16:22, schrieb Scott Kostyshak 

> On Thu, Jan 07, 2016 at 04:58:38PM +0100, Kornel Benko wrote:
> > Am Dienstag, 5. Januar 2016 um 16:35:06, schrieb Guenter Milde 
> > 
> > > On 2016-01-05, Kornel Benko wrote:
> > > 
> > > > [-- Type: text/plain, Encoding: 7bit --]
> > > 
> > > > Am Dienstag, 5. Januar 2016 um 09:19:27, schrieb Scott Kostyshak 
> > > > 
> > > >> Just in case anyone is comparing the results of ctests, I wanted to 
> > > >> make
> > > >> sure you do not confuse a change in the tests with a change cause by 
> > > >> LyX
> > > >> or a patch.
> > > 
> > > >> Although it is not our goal (in fact we would be happy to have unit
> > > >> tests that abstract away from these issues), our tests caught a
> > > >> regression in l3kernel. I reported the issue here
> > > >> http://tug.org/pipermail/tex-live/2016-January/037586.html
> > > >> after updating to TL 2015 caused a test to go from passing to failing.
> > > >> Yesterday or today's update fixed the regression.
> > > 
> > > >> The test is:
> > > >> EXAMPLES_export/examples/colored-boxes_pdf5_texF
> > > 
> > > > Just checked. Failed.
> > > > Updated TL
> > > > Check. Passed.
> > > > That is nice.
> > > 
> > > If it works for both of you, OK.
> > > 
> > > Alternatively, we may put the test in "unreliableTests", so that
> > > someone with the faulty kernel has no false positive...
> > > 
> > > Günter
> > 
> > With the latest update(today) for achemso package
> > export/examples/achemso_(dvi3|pdf5)_texF
> > and
> > export/doc/(|de/|es/|fr/)Math_(dvi3|pdf5)_texF
> > is OK now, can be removed from suspiciousTests.
> > 
> > +1 to commit, wait for Scott.
> 
> The following are what I get after updating TeX Live just now. If it is
> consistent with changes you want to make, please go ahead:
> 
> $ ctest -R "export/examples/achemso_(dvi3|pdf5)_texF" 
> [17/17]
> Test project /home/scott/lyxbuilds/master/CMakeBuild
> Start 1962: SUSPENDED.EXAMPLES.TEXISSUES_export/examples/achemso_dvi3_texF
> 1/2 Test #1962: 
> SUSPENDED.EXAMPLES.TEXISSUES_export/examples/achemso_dvi3_texF ...***Failed   
> 19.10 sec
> Start 1969: SUSPENDED.EXAMPLES.TEXISSUES_export/examples/achemso_pdf5_texF
> 2/2 Test #1969: 
> SUSPENDED.EXAMPLES.TEXISSUES_export/examples/achemso_pdf5_texF ...***Failed   
>  7.46 sec
> 
> 0% tests passed, 2 tests failed out of 2
> 
> Label Time Summary:
> suspended:examples:texissues=  26.56 sec
> 
> Total Test time (real) =  26.85 sec
> 
> The following tests FAILED:
> 1962 - SUSPENDED.EXAMPLES.TEXISSUES_export/examples/achemso_dvi3_texF 
> (Failed)
> 1969 - SUSPENDED.EXAMPLES.TEXISSUES_export/examples/achemso_pdf5_texF 
> (Failed)
> Errors while running CTest
> $ ctest -R "export/doc/(|de/|es/|fr/)Math_(dvi3|pdf5)_texF"
> Test project /home/scott/lyxbuilds/master/CMakeBuild
> Start 465: SUSPENDED.MANUALS.TEXISSUES_export/doc/Math_dvi3_texF
> 1/8 Test #465: SUSPENDED.MANUALS.TEXISSUES_export/doc/Math_dvi3_texF 
> ..***Failed   16.87 sec
> Start 472: SUSPENDED.MANUALS.TEXISSUES_export/doc/Math_pdf5_texF
> 2/8 Test #472: SUSPENDED.MANUALS.TEXISSUES_export/doc/Math_pdf5_texF 
> ..***Failed   23.22 sec
> Start 815: SUSPENDED.MANUALS.TEXISSUES_export/doc/de/Math_dvi3_texF
> 3/8 Test #815: SUSPENDED.MANUALS.TEXISSUES_export/doc/de/Math_dvi3_texF 
> ...***Failed   18.99 sec
> Start 822: SUSPENDED.MANUALS.TEXISSUES_export/doc/de/Math_pdf5_texF
> 4/8 Test #822: SUSPENDED.MANUALS.TEXISSUES_export/doc/de/Math_pdf5_texF 
> ...***Failed   21.92 sec
> Start 995: UNRELIABLE.WRONG.OUTPUT_export/doc/es/Math_dvi3_texF
> 5/8 Test #995: UNRELIABLE.WRONG.OUTPUT_export/doc/es/Math_dvi3_texF ...   
> Passed   20.28 sec
> Start 1002: UNRELIABLE.WRONG.OUTPUT_export/doc/es/Math_pdf5_texF
> 6/8 Test #1002: UNRELIABLE.WRONG.OUTPUT_export/doc/es/Math_pdf5_texF 
> ...***Failed   21.02 sec
> Start 1190: SUSPENDED.MANUALS.TEXISSUES_export/doc/fr/Math_dvi3_texF
> 7/8 Test #1190: SUSPENDED.MANUALS.TEXISSUES_export/doc/fr/Math_dvi3_texF 
> ...***Failed   17.12 sec
> Start 1197: SUSPENDED.MANUALS.TEXISSUES_export/doc/fr/Math_pdf5_texF
> 8/8 Test #1197: SUSPENDED.MANUALS.TEXISSUES_export/doc/fr/Math_pdf5_texF 
> ...***Failed   18.19 sec
> 
> 13% tests passed, 7 tests failed out of 8
> 
> Label Time Summary:
> suspended:manuals:texissues= 116.31 sec
> unreliable:wrong:output=  41.30 sec
> 
> Total Test time (real) = 157.91 sec
> 
> The following tests FAILED:
> 465 - SUSPENDED.MANUALS.TEXISSUES_export/doc/Math_dvi3_texF (Failed)
> 472 - SUSPENDED.MANUALS.TEXISSUES_export/doc/Math_pdf5_texF (Failed)
> 815 - SUSPENDED.MANUALS.TEXISSUES_export/doc/de/Math_dvi3_texF 
> (Failed)
> 822 - SUSPENDED.MANUALS.TEXISSUES_export/doc/de/Math_pdf5_texF 
> (Failed)
> 1002 - UNRELIABLE.WRONG.OUTPUT_export/doc/es/Math_pdf5_texF (Failed)
>

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Georg Baum 
Pavel Sanda wrote:

> Scott Kostyshak wrote:
>> 
>> Can you reproduce now?
> 
> Nope. Smells like automake/autoconf versions. What is your config?

These versions produce the error for me:

$ ./autogen.sh 
Using automake (GNU automake) 1.14.1
Using autoconf (GNU Autoconf) 2.69


Georg

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Pavel Sanda 
Scott Kostyshak wrote:
> > Nope. Smells like automake/autoconf versions. What is your config?
> 
> First part is below. Do you want the whole (long) config.log file?

Sorry I just meant these two commands:
automake --version
autoconf --version
P

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Pavel Sanda 
Georg Baum wrote:
> Pavel Sanda wrote:
> 
> > Scott Kostyshak wrote:
> >> 
> >> Can you reproduce now?
> > 
> > Nope. Smells like automake/autoconf versions. What is your config?
> 
> These versions produce the error for me:
> 
> $ ./autogen.sh 
> Using automake (GNU automake) 1.14.1
> Using autoconf (GNU Autoconf) 2.69

These work for me:
automake (GNU automake) 1.11.3
autoconf (GNU Autoconf) 2.68
P

Re: [PATCH] Use \AA and \aa for "latin letter A with ring above".

2016-01-07 Thread Georg Baum 
Scott Kostyshak wrote:

> On Thu, Jan 07, 2016 at 09:46:35PM +0100, Georg Baum wrote:
>> Guenter Milde wrote:
>> 
>> > On 2016-01-07, Kornel Benko wrote:
>> >> Am Donnerstag, 7. Januar 2016 um 11:47:16, schrieb Guenter Milde
>> >> 
>> > 
>> >>> Whether the new "deprecated" tag should go directly into 2.2.0 or
>> >>> wait a bit is up to Scott (and may depend on the result of our
>> >>> autotests).
>> 
>> Scott, what do you prefer? The keyword is not required for the fix, so it
>> can also wait for 2.3
> 
> I took a look and it seems simple enough to me be fine for 2.3 so unless
> you have a reservation, I would say put it in.

You mean 2.2?


Georg

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Kornel Benko 
Am Donnerstag, 7. Januar 2016 um 22:42:03, schrieb Georg Baum 

> Pavel Sanda wrote:
> 
> > Scott Kostyshak wrote:
> >> 
> >> Can you reproduce now?
> > 
> > Nope. Smells like automake/autoconf versions. What is your config?
> 
> These versions produce the error for me:
> 
> $ ./autogen.sh 
> Using automake (GNU automake) 1.14.1
> Using autoconf (GNU Autoconf) 2.69
> 
> 
> Georg

I have the same, with the error too.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Use \AA and \aa for "latin letter A with ring above".

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 10:42:31PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > On Thu, Jan 07, 2016 at 09:46:35PM +0100, Georg Baum wrote:
> >> Guenter Milde wrote:
> >> 
> >> > On 2016-01-07, Kornel Benko wrote:
> >> >> Am Donnerstag, 7. Januar 2016 um 11:47:16, schrieb Guenter Milde
> >> >> 
> >> > 
> >> >>> Whether the new "deprecated" tag should go directly into 2.2.0 or
> >> >>> wait a bit is up to Scott (and may depend on the result of our
> >> >>> autotests).
> >> 
> >> Scott, what do you prefer? The keyword is not required for the fix, so it
> >> can also wait for 2.3
> > 
> > I took a look and it seems simple enough to me be fine for 2.3 so unless
> > you have a reservation, I would say put it in.
> 
> You mean 2.2?

Yes, sorry.

Scott


signature.asc
Description: PGP signature

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 10:59:26PM +0100, Kornel Benko wrote:
> Am Donnerstag, 7. Januar 2016 um 22:42:03, schrieb Georg Baum 
> 
> > Pavel Sanda wrote:
> > 
> > > Scott Kostyshak wrote:
> > >> 
> > >> Can you reproduce now?
> > > 
> > > Nope. Smells like automake/autoconf versions. What is your config?
> > 
> > These versions produce the error for me:
> > 
> > $ ./autogen.sh 
> > Using automake (GNU automake) 1.14.1
> > Using autoconf (GNU Autoconf) 2.69
> > 
> > 
> > Georg
> 
> I have the same, with the error too.

I have the same as Kornel and Georg.

Scott


signature.asc
Description: PGP signature

Re: #9794: inset-modify tabular commands are incorrectly disabled

2016-01-07 Thread Guillaume Munch 

Le 03/01/2016 09:46, Georg Baum a écrit :

We have a script for updating the docs, examples and templates
(development/tools/updatedocs.py), and one for updating the ui and bind
files (development/tools/updatelfuns.sh). Or did you man something else?



Is there a reason why the scripts do not have exec permissions? I
initially ran "sh updatelfuns.sh" and this failed, emptying a dozen of
files. After the second try I found that it requires bash, which would
have been chosen automatically if it had been possible to run
./updatelfuns.sh directly.

Re: why Babel with dvi3 (LuTeX)?

2016-01-07 Thread Guenter Milde 
On 2016-01-07, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> On Mon, Jan 04, 2016 at 08:21:51PM +, Guenter Milde wrote:

>> > Is the patch made with 'git am ' committed, or only applied?

>> Commited. However, "git apply" will also work with an inline patch if passed
>> the saved message in mbox format (as does the standard "patch" command).

> Sorry for not getting to this yet. Is this patch still pending? If so,
> can you confirm that the patch still applies cleanly (after recent
> changes to master)? Once you do that, I will run the tests before/after
> the patch.

The patch requires updating. Here is a version, that works with
d7ff8c6e18752.

Günter


>From 30b0e71be55a9a4b8cd5554bf00894dd305c3b8c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?G=C3=BCnter=20Milde?= 
Date: Sun, 3 Jan 2016 23:28:08 +0100
Subject: [PATCH] Use polyglossia also with DVI (LuaTeX).

Simplify the logic for language package selection and make it more consistent:

Use polyglossia with non-TeX fonts (system fonts/Unicode fonts) for all
export flavours (XeTeX, LuaTeX, DVI-LuaTeX), if the language package setting
is "auto" and there is no language not supported by Babel and no package
providing Babel.

This solves some Babel-related autotest cases and leads to some new failures
due to the polyglossia language nesting problem.
---
 development/autotests/suspiciousTests | 47 ---
 development/autotests/unreliableTests |  2 +-
 src/BufferParams.cpp  |  7 ++
 src/LaTeXFeatures.cpp |  4 +--
 4 files changed, 16 insertions(+), 44 deletions(-)

diff --git a/development/autotests/suspiciousTests 
b/development/autotests/suspiciousTests
index 6ddf611..3640faa 100644
--- a/development/autotests/suspiciousTests
+++ b/development/autotests/suspiciousTests
@@ -61,8 +61,8 @@ export/doc/(es|fr)/UserGuide_pdf4_texF
 export/examples/uk/splash_(dvi3|pdf[45])_texF
 
 # missing commands (polyglossia?)
-# Explore! (works with dvi3 or language_package==babel)
-export/doc/fr/UserGuide_pdf[45]_systemF
+# Explore! (works with language_package==babel)
+export/doc/fr/UserGuide_.*_systemF
 
 # Bug in Babel-Spanish with Xe/LuaTeX and Unicode fonts:
 #
@@ -71,21 +71,11 @@ export/doc/fr/UserGuide_pdf[45]_systemF
 # Workaround: add a line to the user-preamble
 #   \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
 export/doc/es/UserGuide_.*_systemF
-#
-# Export with DVI (luatex) uses Babel instead of Polyglossia.
-# Don't use the above workaround here - these documents don't require Babel
-# problem should be solved by fixing auto-selection of language package.
-export/examples/es/ejemplo_con_lyx_dvi3_systemF
-# Galician shares some code with Babel-Spanish (including the bug).
-export/doc/gl/Tutorial_dvi3_systemF
-export/examples/gl/exemplo_lyxificado_dvi3_systemF
-# document language is Spanish: changing to Basque solves the problem
-export/examples/eu/adibide_lyx-atua_dvi3_systemF
 
 # Missing characters (U+0361, U+1E61) in LM,
 # set different system font in the source?
 # + language nesting problem (may disappear after completed translation)
-export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
+export/doc/(de/|es/|fr/)Customization_.*_systemF
 
 # Probably language mess
 export/export/ja/wrong_auto_encoding_(dvi|pdf(|3))
@@ -99,14 +89,6 @@ export/export/ja/wrong_auto_encoding_(dvi|pdf(|3))
 # \c e -> 0229 LATIN SMALL LETTER E WITH CEDILLA
 export/doc/(|de/|es/|fr/)Math.*systemF
 
-# 1.) Unknown Japanese char in section if previous
-# paragraph ended in non-Japaneese language
-# This is the same error as in export/export/ja/wrong_auto_encoding 
(unreliableTests)
-# 2.) unknown chars üß in selected encoding in 'This is a German word: Tschüß'
-#
-# Both reasons invalid since the commit 
6b0632eea288348b912f98b79bc871830b6a3d98
-#export/doc/ja/EmbeddedObjects_(dvi|pdf|pdf3)
-
 # missing character: There is no ^^A in font [lmroman12-regular]
 # and all the line down to ^^Z and beyond...
 # XeTeX artifact? works with LuaTeX, explore:
@@ -118,9 +100,9 @@ Sublabel: lyxbugs
 # LyX bugs with a Trac number.
 
 # Language nesting and polyglossia #9633
-export/doc/(nb|sk)/Intro_pdf[45]_systemF
+export/doc/(nb|sk)/Intro.*systemF
 # missing characters + language nesting (may disappear after completed 
translation)
-export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
+export/doc/(de/|es/|fr/)Customization_.*_systemF
 #
 # Language nesting, document is OK, fails because of a bug in LyX
 # document is still worng, did only fail because of latin language
@@ -129,16 +111,14 @@ export/doc/(de/|es/|fr/)Customization_pdf[45]_systemF
 
 
 # use LuaTeX-compatible language names #9910
-# Wrong language name for LuaTeX
+# Wrong language name for LuaTeX (with Babel, no error with Polyglossia)
 # After LyX 2.1 is released, apply the patch and remove these
 # See http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg181595.html
 # ! LuaTeX error

Re: why Babel with dvi3 (LuTeX)?

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 09:14:02PM +, Guenter Milde wrote:
> On 2016-01-07, Scott Kostyshak wrote:
> 
> > [-- Type: text/plain, Encoding: quoted-printable --]
> 
> > On Mon, Jan 04, 2016 at 08:21:51PM +, Guenter Milde wrote:
> 
> >> > Is the patch made with 'git am ' committed, or only applied?
> 
> >> Commited. However, "git apply" will also work with an inline patch if 
> >> passed
> >> the saved message in mbox format (as does the standard "patch" command).
> 
> > Sorry for not getting to this yet. Is this patch still pending? If so,
> > can you confirm that the patch still applies cleanly (after recent
> > changes to master)? Once you do that, I will run the tests before/after
> > the patch.
> 
> The patch requires updating. Here is a version, that works with
> d7ff8c6e18752.

Thanks for the update. I will do before/after tests tonight and let you
know the results.

Scott


signature.asc
Description: PGP signature

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 01:24:45PM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > ---
> > mkdir /tmp/tmp.EI1jW3t6A1
> > cd /path/to/git/repo
> > git reset --hard
> > git clean -xdf
> > ./autogen.sh
> > cd /tmp/tmp.EI1jW3t6A1 && /path/to/git/repo/configure 
> > --enable-build-type=pre --enable-monolithic-build=no
> > make -j4
> > make -j4 check
> > make -j4 distcheck
> > echo $?
> > ---
> > 
> > Note that I can reproduce it with many other specifications (e.g. configure 
> > options).
> > 
> > Can you reproduce now?
> 
> Nope. Smells like automake/autoconf versions. What is your config?

First part is below. Do you want the whole (long) config.log file?

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by LyX configure 2.2.0dev, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ /home/scott/lyxbuilds/master_TEMP/repo/configure 

  ## - ##
  ## Platform. ##
  ## - ##

  hostname = cotopaxi
  uname -m = x86_64
  uname -r = 3.19.0-33-generic
  uname -s = Linux
  uname -v = #38-Ubuntu SMP Fri Nov 6 18:18:12 UTC 2015

  /usr/bin/uname -p = unknown
  /bin/uname -X = unknown

  /bin/arch  = unknown
  /usr/bin/arch -k   = unknown
  /usr/convex/getsysinfo = unknown
  /usr/bin/hostinfo  = unknown
  /bin/machine   = unknown
  /usr/bin/oslevel   = unknown
  /bin/universe  = unknown

Scott


signature.asc
Description: PGP signature

Re: [PATCH] Use \AA and \aa for "latin letter A with ring above".

2016-01-07 Thread Scott Kostyshak 
On Thu, Jan 07, 2016 at 09:46:35PM +0100, Georg Baum wrote:
> Guenter Milde wrote:
> 
> > On 2016-01-07, Kornel Benko wrote:
> >> Am Donnerstag, 7. Januar 2016 um 11:47:16, schrieb Guenter Milde
> >> 
> > 
> >>> Whether the new "deprecated" tag should go directly into 2.2.0 or wait
> >>> a bit is up to Scott (and may depend on the result of our autotests).
> 
> Scott, what do you prefer? The keyword is not required for the fix, so it 
> can also wait for 2.3

I took a look and it seems simple enough to me be fine for 2.3 so unless
you have a reservation, I would say put it in.

Scott


signature.asc
Description: PGP signature

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Pavel Sanda 
Scott Kostyshak wrote:
> ---
> mkdir /tmp/tmp.EI1jW3t6A1
> cd /path/to/git/repo
> git reset --hard
> git clean -xdf
> ./autogen.sh
> cd /tmp/tmp.EI1jW3t6A1 && /path/to/git/repo/configure --enable-build-type=pre 
> --enable-monolithic-build=no
> make -j4
> make -j4 check
> make -j4 distcheck
> echo $?
> ---
> 
> Note that I can reproduce it with many other specifications (e.g. configure 
> options).
> 
> Can you reproduce now?

Nope. Smells like automake/autoconf versions. What is your config?
P

Re: make distcheck: cannot remove '../../po/lyx.pot'

2016-01-07 Thread Pavel Sanda 
Scott Kostyshak wrote:
> > > These versions produce the error for me:
> > > 
> > > $ ./autogen.sh 
> > > Using automake (GNU automake) 1.14.1
> > > Using autoconf (GNU Autoconf) 2.69
> > > 
> > > 
> > > Georg
> > 
> > I have the same, with the error too.
> 
> I have the same as Kornel and Georg.

And you don't observe this problem for 2.1.x, right? P