[PATCH] compilation fix for libc++ in C++11 mode

[Jean-Marc Lasgouttes]

The following patch fixes compilation for me with clang and libc++ (with 
autotools I set CXX="clang++ --stdlib=libc++").


This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
to be fixed in 3.7.1 or 3.8.0.

Can someone confirm that adding the default constructor like that is 
harmless?


JMarc

>From 9c93045dd73878a889fc83314c3b1c81e748c38d Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Fri, 8 Jan 2016 09:51:32 +0100
Subject: [PATCH] Fix compilation error with clang's libc++

The bug is probably fixed for clang 3.7.1 or 3.8.0
---
 src/TocBackend.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/TocBackend.h b/src/TocBackend.h
index d5dfae4..cc5e429 100644
--- a/src/TocBackend.h
+++ b/src/TocBackend.h
@@ -127,6 +127,9 @@ private:
 class Toc : public std::vector
 {
 public:
+	// This is needed to work around a libc++ bug
+	// https://llvm.org/bugs/show_bug.cgi?id=24137
+	Toc() {}
 	typedef std::vector::const_iterator const_iterator;
 	typedef std::vector::iterator iterator;
 	const_iterator item(DocIterator const & dit) const;
-- 
2.5.0

Re: Status on Mac with El Capitan

[Jean-Marc Lasgouttes]

Le 08/01/2016 10:08, Stephan Witt a écrit :

Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :

Yes, unless somone has a different brilliant idea.


Am I right that it makes explicit what is otherwise implicit? So it is safe to 
commit?


Yes, I think so. The question is only maintainability. Guillaume 
complained that the is fragile because new code can forget to add this 
explicit lyx::.



The problem is that libc++ provides std::next even when not in C++11 mode.


Is the implementation of std::next compatible to the e.g. 
ParagraphList::iterator or not?


It should. The problem is only that we provide boost::next when not in 
C++11 mode, but clang already provides the real std::next.


The proper fix would be to check at configure time whether std::next 
exists and react on that. But it is extra work :)



This problem will go away in 2.3.


How? With your fix? Does it fix wrong LyX code or is it some work around?


Because support for c++98 will go away, together with many of our lyx:: 
wrappers.


Georg, do you have a thought on that?

JMarc

[PATCH] Improve detection of std::regex

[Jean-Marc Lasgouttes]

This following patch improves the autotools detection of std::regex. It 
fixes several issues there and makes code more readable IMO.


Georg, I'd like to have your review on this, especially since my 
previous commit e1938aa2 on the subject was a bit buggy.


Tested with gcc 4.3, gcc 5.1, gcc 4.8, clang 3.7 + libc++

There is still a potential problem that I cannot test because my system 
is too new: when clang is used with a stdlibc++ from gcc 4.8 or older, I 
suspect that we will use the bad regex.


I do not know how to handle that since in this case libstdc++ will not 
giv us any version number we can rely on. Anyway, the patch here does 
not make matters worse in this regard.


JMarc

>From 5189f5dfdbae142175f2adff191557c3126a9be4 Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Wed, 6 Jan 2016 10:33:54 +0100
Subject: [PATCH 1/2] Fix the logic of selection of std::regex

This amends commit e1938aa2, which introduced some logic
errors: regex would be enabled for gcc versions which have unusable
 header.

The new code separates better special gcc handling from special C++11
handling and should be more readable.

* set -std=c++11 in AM_CPPFLAGS instead of AM_CXXFLAGS, since the
  preprocessor uses this setting too.

* Before checking for header , set language to C++ and update
  value of AM_CPPFLAGS too.

* Separate code that checks for regex in its own macro.

* now unknown compiler which have the  header, will use std::regex in C++11 mode.
---
 config/lyxinclude.m4 | 84 
 1 file changed, 52 insertions(+), 32 deletions(-)

diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4
index 5c8ff6c..81e91ca 100644
--- a/config/lyxinclude.m4
+++ b/config/lyxinclude.m4
@@ -151,7 +151,9 @@ dnl the C++11 standard.
 AC_DEFUN([LYX_CXX_CXX11],
 [AC_CACHE_CHECK([whether the compiler implements C++11],
[lyx_cv_cxx_cxx11],
- [save_CXXFLAGS=$CXXFLAGS
+ [save_CPPFLAGS=$CPPFLAGS
+  CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+  save_CXXFLAGS=$CXXFLAGS
   CXXFLAGS="$AM_CXXFLAGS $CXXFLAGS"
   AC_LANG_PUSH(C++)
   AC_TRY_COMPILE([], [
@@ -161,8 +163,44 @@ AC_DEFUN([LYX_CXX_CXX11],
   ],
   [lyx_cv_cxx_cxx11=no], [lyx_cv_cxx_cxx11=yes ; lyx_flags="$lyx_flags c++11"])
  AC_LANG_POP(C++)
- CXXFLAGS=$save_CXXFLAGS])
-lyx_use_cxx11=$lyx_cv_cxx_cxx11
+ CXXFLAGS=$save_CXXFLAGS
+ CPPFLAGS=$save_CPPFLAGS])
+ lyx_use_cxx11=$lyx_cv_cxx_cxx11
+])
+
+dnl decide whether we want to use std::regex and set the
+dnl LYX_USE_STD_REGEX accordingly.
+AC_DEFUN([LYX_CXX_USE_REGEX],
+[lyx_std_regex=no
+ if test $lyx_use_cxx11 = yes; then
+   save_CPPFLAGS=$CPPFLAGS
+   CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
+   save_CXXFLAGS=$CXXFLAGS
+   CXXFLAGS="$AM_CXXFLAGS $CXXFLAGS"
+   AC_LANG_PUSH(C++)
+   AC_CHECK_HEADER([regex], [lyx_std_regex=yes], [lyx_std_regex=no])
+   AC_LANG_POP(C++)
+   CXXFLAGS=$save_CXXFLAGS
+   CPPFLAGS=$save_CPPFLAGS
+   if test x$GXX = xyes && test $lyx_std_regex = yes ; then
+ AC_MSG_CHECKING([for correct regex implementation])
+ if test x$CLANG = xno || test $lyx_cv_lib_stdcxx = yes; then
+   dnl  in gcc is unusable in versions less than 4.9.0
+   dnl see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
+   case $gxx_version in
+ 4.0*|4.1*|4.2*|4.3*|4.4*|4.5*|4.6*|4.7*|4.8*) lyx_std_regex=no ;;
+ *) ;;
+   esac
+ fi
+   fi
+   AC_MSG_RESULT([$lyx_std_regex])
+ fi
+
+ if test $lyx_std_regex = yes ; then
+  lyx_flags="$lyx_flags std-regex"
+  AC_DEFINE([LYX_USE_STD_REGEX], 1, [define to 1 if std::regex should be preferred to boost::regex])
+ fi
+ AM_CONDITIONAL([LYX_USE_STD_REGEX], test $lyx_std_regex = yes)
 ])
 
 
@@ -270,7 +308,6 @@ if test "x$enable_assertions" = xyes ; then
 fi
 
 # set the compiler options correctly.
-lyx_std_regex=no
 if test x$GXX = xyes; then
   dnl clang++ pretends to be g++ 4.2.1; this is not useful
   if test x$CLANG = xno; then
@@ -325,46 +362,29 @@ if test x$GXX = xyes; then
   4.3*|4.4*|4.5*|4.6*)
 dnl Note that this will define __GXX_EXPERIMENTAL_CXX0X__.
 dnl The source code relies on that.
-AM_CXXFLAGS="$AM_CXXFLAGS -std=c++0x";;
+AM_CPPFLAGS="$AM_CPPFLAGS -std=c++0x";;
   clang)
 dnl presumably all clang versions support c++11.
 	dnl the deprecated-register warning is very annoying with Qt4.x right now.
-AM_CXXFLAGS="$AM_CXXFLAGS -std=c++11 -Wno-deprecated-register";;
+AM_CPPFLAGS="$AM_CPPFLAGS -std=c++11"
+AM_CXXFLAGS="$AM_CXXFLAGS -Wno-deprecated-register";;
   *)
 AS_CASE([$host], [*cygwin*],
-[AM_CXXFLAGS="$AM_CXXFLAGS -std=gnu++11"],
-[AM_CXXFLAGS="$AM_CXXFLAGS -std=c++11"]);;
+[AM_CPPFLAGS="$AM_CPPFLAGS -std=gnu++11"],
+[AM_CPPFLAGS="$AM_CPPFLAGS -std=c++11"]);;
 esac
   fi
+fi
 
-  LYX_CXX_CXX11
-  if test $lyx_use_cxx11 = yes ; then
+LYX_CXX_CXX11
+if test $lyx_use_cxx11 = yes; then
+  if test x$GXX = 

Re: Status on Mac with El Capitan

[Stephan Witt]

> Am 07.01.2016 um 16:00 schrieb Kornel Benko :
> 
> Am Donnerstag, 7. Januar 2016 um 15:39:47, schrieb 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})
> 
> OR (maybe)
>   include_directories((BEFORE
> ${TOP_SRC_DIR}/src/tex2lyx
> ${TOP_SRC_DIR}/src/support/minizip)
>   include_directories(${ZLIB_INCLUDE_DIR})

Yes, this works too. BTW, what is "src/support/minizip“ for?
It doesn’t exist in the master checkout.
Why should "src/tex2lyx“ come before other includes?

Stephan

> 
> Cannot help on next(...)
> 
>   Kornel

Re: Status on Mac with El Capitan

[Stephan Witt]

Am 07.01.2016 um 15:39 schrieb Stephan Witt :
> ...
> 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 file included from /Users/stephan/git/lyx/src/OutputParams.h:16:
> In file included from /Users/stephan/git/lyx/src/support/shared_ptr.h:22:
> In file included from 
> /Users/stephan/git/lyx/3rdparty/boost/boost/shared_ptr.hpp:17:
> In file included from 
> /Users/stephan/git/lyx/3rdparty/boost/boost/smart_ptr/shared_ptr.hpp:23:
> In file included from 
> /Users/stephan/git/lyx/3rdparty/boost/boost/config/no_tr1/memory.hpp:21:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:604:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iterator:519:1:
>  note: candidate function [with _ForwardIter = 
> std::__1::__list_const_iterator]
> next(_ForwardIter __x,
> ^
> In file included from /Users/stephan/git/lyx/src/Compare.cpp:23:
> 

Re: Status on Mac with El Capitan

[Jean-Marc Lasgouttes]

Le 08/01/2016 09:17, Stephan Witt a écrit :

A possible solution I’ve attached as patch.
Any better solution or ok to commit?


Yes, unless somone has a different brilliant idea. The problem is that 
libc++ provides std::next even when not in C++11 mode.


This problem will go away in 2.3.

JMarc

PS: I have a fix for your compilation problem in C++11 mode (libc++ bug)

Re: Status on Mac with El Capitan

[Stephan Witt]

Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :
> 
> Le 08/01/2016 09:17, Stephan Witt a écrit :
>> A possible solution I’ve attached as patch.
>> Any better solution or ok to commit?
> 
> Yes, unless somone has a different brilliant idea.

Am I right that it makes explicit what is otherwise implicit? So it is safe to 
commit?

> The problem is that libc++ provides std::next even when not in C++11 mode.

Is the implementation of std::next compatible to the e.g. 
ParagraphList::iterator or not?

> 
> This problem will go away in 2.3.

How? With your fix? Does it fix wrong LyX code or is it some work around?

Stephan

> 
> JMarc
> 
> PS: I have a fix for your compilation problem in C++11 mode (libc++ bug)
> 

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

[Kornel Benko]

Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak 

> On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote:
> > On 2016-01-07, Scott Kostyshak wrote:
> 
> > 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!
> 
> Good point. I forget whether this is currently possible.
> 
> > 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)
> 
> Good points. Maybe we should put something about this in Development.lyx
> since the topic does come up frequently. Maybe you already did. I did
> not check.
> 
> > 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).
> 
> Indeed. From what i understand, our file as it is should compile when TL
> 2016 is released in a few months.
> 
> > * 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.

No it is not hackish IMHO. The test should show, that with a suitable font this 
file is compilable.
It is a remnant from the times we had defined fonts for texF only.
If the non-tex font is defined in the document, it will be used.

> > > 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"

In this case, that is a problem. But I don't know better.

> > * it does not longer work after updating TeXLive 
> > 
> >   -> re-activate the patterns in "suspiciousTests"
> 
> The example file only compiles on an old system and (hopefully) on a
> future system (when TL 2016 is released).
> 
> Thanks for the in-depth response and advice, Günter. I don't plan on
> spending any more time on this particular issue until 2016 is released
> and then I will check if that changes anything. In the mean time I'm
> fine with making the test a suspiciousTest or whatever else you and
> Kornel prefer.
> 
> Scott

Kornel

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

Re: [PATCH] Improve detection of std::regex

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> This following patch improves the autotools detection of std::regex. It
> fixes several issues there and makes code more readable IMO.
> 
> Georg, I'd like to have your review on this, especially since my
> previous commit e1938aa2 on the subject was a bit buggy.
> 
> Tested with gcc 4.3, gcc 5.1, gcc 4.8, clang 3.7 + libc++

Works with gcc 4.9 as well.

> There is still a potential problem that I cannot test because my system
> is too new: when clang is used with a stdlibc++ from gcc 4.8 or older, I
> suspect that we will use the bad regex.
> 
> I do not know how to handle that since in this case libstdc++ will not
> giv us any version number we can rely on. Anyway, the patch here does
> not make matters worse in this regard.

It will never be possible to detect every compiler and lib combination 
correctly (otherwise the switches to override the automatism would not be 
needed). This is a rare combination, so it is not too important IMHO.

The patch is definitely better than the old version. Please commit.


Georg

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

[Georg Baum]

Scott Kostyshak wrote:

> 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.

I don't see it with 2.1.x. This is really mysterious.


Georg

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

[Guillaume Munch]

Le 08/01/2016 08:01, Guillaume Munch a écrit :


Ok, this is what I did.




The last patch contains a minor rephrasing that I did not try to compile
before showing it to you, because it was straightforward and unrelated
to anything we had discussed (isTable is now defined as a whitelist and
not as a blacklist for future-proofness). There was a typo, and the
correct patch is attached. I should have checked the final compilation
before sending it.


Guillaume
>From 7b9cacecbcc31c428b77d5bd9a5c0f5da40877bb Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Fri, 11 Dec 2015 20:45:57 +
Subject: [PATCH 9/9] Let tabular-feature commands fall through non-table math
 insets. (#4189)

---
 src/mathed/InsetMathHull.cpp | 37 +++--
 src/mathed/InsetMathHull.h   |  2 ++
 2 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/src/mathed/InsetMathHull.cpp b/src/mathed/InsetMathHull.cpp
index 5b884b4..f6c1e00 100644
--- a/src/mathed/InsetMathHull.cpp
+++ b/src/mathed/InsetMathHull.cpp
@@ -1040,6 +1040,24 @@ void InsetMathHull::footer_write(WriteStream & os) const
 }
 
 
+bool InsetMathHull::isTable() const
+{
+	switch (type_) {
+	case hullEqnArray:
+	case hullAlign:
+	case hullAlignAt:
+	case hullXAlignAt:
+	case hullXXAlignAt:
+	case hullFlAlign:
+	case hullMultline:
+	case hullGather:
+		return true;
+	default:
+		return false;
+	}
+}
+
+
 bool InsetMathHull::rowChangeOK() const
 {
 	return
@@ -1702,6 +1720,13 @@ void InsetMathHull::doDispatch(Cursor & cur, FuncRequest & cmd)
 		break;
 	}
 
+	case LFUN_TABULAR_FEATURE:
+		if (!isTable())
+			cur.undispatched();
+		else
+			InsetMathGrid::doDispatch(cur, cmd);
+		break;
+
 	default:
 		InsetMathGrid::doDispatch(cur, cmd);
 		break;
@@ -1817,6 +1842,8 @@ bool InsetMathHull::getStatus(Cursor & cur, FuncRequest const & cmd,
 		return InsetMathGrid::getStatus(cur, cmd, status);
 
 	case LFUN_TABULAR_FEATURE: {
+		if (!isTable())
+			return false;
 		string s = cmd.getArg(0);
 		if (!rowChangeOK()
 		&& (s == "append-row"
@@ -1838,16 +1865,6 @@ bool InsetMathHull::getStatus(Cursor & cur, FuncRequest const & cmd,
 			status.setEnabled(false);
 			return true;
 		}
-		if ((type_ == hullSimple
-		  || type_ == hullEquation
-		  || type_ == hullNone) &&
-		(s == "add-hline-above" || s == "add-hline-below")) {
-			status.message(bformat(
-from_utf8(N_("Can't add horizontal grid lines in '%1$s'")),
-hullName(type_)));
-			status.setEnabled(false);
-			return true;
-		}
 		if (s == "add-vline-left" || s == "add-vline-right") {
 			status.message(bformat(
 from_utf8(N_("Can't add vertical grid lines in '%1$s'")),
diff --git a/src/mathed/InsetMathHull.h b/src/mathed/InsetMathHull.h
index 9598ad4..e02c619 100644
--- a/src/mathed/InsetMathHull.h
+++ b/src/mathed/InsetMathHull.h
@@ -236,6 +236,8 @@ private:
 	ColorCode standardColor() const;
 	/// consistency check
 	void check() const;
+	/// does it understand tabular-feature commands?
+	bool isTable() const;
 	/// can this change its number of rows?
 	bool rowChangeOK() const;
 	/// can this change its number of cols?
-- 
2.1.4

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

[Kornel Benko]

Am Freitag, 8. Januar 2016 um 21:43:17, schrieb Georg Baum 

> Scott Kostyshak wrote:
> 
> > 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.
> 
> I don't see it with 2.1.x. This is really mysterious.
> 

This forces me to do check too ...
No problems with 2.1.x.

> Georg

Kornel

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

Re: why Babel with dvi3 (LuTeX)?

[Guenter Milde]

On 2016-01-08, Scott Kostyshak wrote:
> On Fri, Jan 08, 2016 at 06:31:37AM +, Guenter Milde wrote:
>> On 2016-01-08, Scott Kostyshak wrote:

> Here is the diff:

>   $ diff ctests_d7ff8c6e/LastTestsFailed.log
>   ctests_d7ff8c6e_with_patch/LastTestsFailed.log 
>   0a1,2
>  > 218:AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_texF
>  > 
> 219:INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF

A typo in the filter pattern.

>  > 3718:UNRELIABLE.NONSTANDARD_export/templates/kluwer_dvi3_systemF

This is tagged "unreliable" because it is known to fail st at some places or
sometimes. 

Summary: There is no real regression due to the changes introduced by the
patch. All changes in test results highlighted existing problems with either
polyglossia or babel.

My suggestion is to commit the patch and do test filter adaption in a
cleanup.

There is a tailback of patches fixing other issues now because of this one
and I am running out of time.

Günter

Re: [PATCH] compilation fix for libc++ in C++11 mode

[Guillaume Munch]

Le 08/01/2016 08:59, Jean-Marc Lasgouttes a écrit :

The following patch fixes compilation for me with clang and libc++ (with
autotools I set CXX="clang++ --stdlib=libc++").

This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
to be fixed in 3.7.1 or 3.8.0.

Can someone confirm that adding the default constructor like that is
harmless?




I tried to look it up. It might work right now but I think we should
get rid of this subclassing entirely. It is just used for
forward-declaration and defining helper functions. I have a bad feeling
about starting to define custom constructors for STL containers
explicitly. The helper functions should not be there in the first place
and instead of forward-declaring we can just typedef Toc in a new header
file Toc.h. Anyway TocBackend.h has too many classes. I would say that
the attached patch is the proper solution, if you are willing to have a
look. This should be done independently of whether there is a bug in clang.


Guillaume
>From aeaf633f7449f6fa44b0d7c0aa9b1d542be276e8 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Fri, 8 Jan 2016 19:06:50 +
Subject: [PATCH] Simplify class structure in TocBackend

Deriving from std::vector to provide helper functions appears a touch
excessive. Use typedef instead and move helper functions to the base class. New
header Toc.h provided to replace forward-declarations.

Remove TocIterator which is useless.

Factor code with the recent method DocIterator::getInnerText(). Small correction
in the latter to check for emptiness.
---
 src/Buffer.cpp |  4 ++--
 src/BufferView.cpp |  4 ++--
 src/Changes.cpp|  2 +-
 src/DocIterator.cpp|  2 +-
 src/Makefile.am|  1 +
 src/Paragraph.h|  1 -
 src/Toc.h  | 42 ++
 src/TocBackend.cpp | 36 +++-
 src/TocBackend.h   | 40 
 src/frontends/qt4/TocModel.cpp |  3 ++-
 src/frontends/qt4/TocModel.h   |  4 ++--
 src/insets/InsetTOC.h  |  3 ++-
 12 files changed, 78 insertions(+), 64 deletions(-)
 create mode 100644 src/Toc.h

diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 115a542..aae1e43 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2226,8 +2226,8 @@ void Buffer::getLabelList(vector & list) const
 
 	list.clear();
 	shared_ptr toc = d->toc_backend.toc("label");
-	TocIterator toc_it = toc->begin();
-	TocIterator end = toc->end();
+	Toc::const_iterator toc_it = toc->begin();
+	Toc::const_iterator end = toc->end();
 	for (; toc_it != end; ++toc_it) {
 		if (toc_it->depth() == 0)
 			list.push_back(toc_it->str());
diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 7332ec5..b0801bf 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -2397,8 +2397,8 @@ void BufferView::gotoLabel(docstring const & label)
 
 		// find label
 		shared_ptr toc = buf->tocBackend().toc("label");
-		TocIterator toc_it = toc->begin();
-		TocIterator end = toc->end();
+		Toc::const_iterator toc_it = toc->begin();
+		Toc::const_iterator end = toc->end();
 		for (; toc_it != end; ++toc_it) {
 			if (label == toc_it->str()) {
 lyx::dispatch(toc_it->action());
diff --git a/src/Changes.cpp b/src/Changes.cpp
index 832ccac..9fa46f9 100644
--- a/src/Changes.cpp
+++ b/src/Changes.cpp
@@ -501,7 +501,7 @@ void Changes::addToToc(DocIterator const & cdit, Buffer const & buffer,
 			// ¶ U+00B6 PILCROW SIGN
 			str.push_back(0xb6);
 		docstring const & author = author_list.get(it->change.author).name();
-		Toc::iterator it = change_list->item(0, author);
+		Toc::iterator it = TocBackend::findItem(*change_list, 0, author);
 		if (it == change_list->end()) {
 			change_list->push_back(TocItem(dit, 0, author, true));
 			change_list->push_back(TocItem(dit, 1, str, output_active,
diff --git a/src/DocIterator.cpp b/src/DocIterator.cpp
index a059ad1..2ef8ddd 100644
--- a/src/DocIterator.cpp
+++ b/src/DocIterator.cpp
@@ -229,7 +229,7 @@ CursorSlice const & DocIterator::innerTextSlice() const
 DocIterator DocIterator::getInnerText() const
 {
 	DocIterator texted = *this;
-	while (!texted.inTexted()) 
+	while (texted.inMathed()) 
 		texted.pop_back();
 	return texted;
 }
diff --git a/src/Makefile.am b/src/Makefile.am
index 9446d17..098c70d 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -289,6 +289,7 @@ HEADERFILESCORE = \
 	Text.h \
 	TextClass.h \
 	TextMetrics.h \
+	Toc.h \
 	TocBackend.h \
 	Trans.h \
 	Undo.h \
diff --git a/src/Paragraph.h b/src/Paragraph.h
index d0ed94b..73de6c1 100644
--- a/src/Paragraph.h
+++ b/src/Paragraph.h
@@ -49,7 +49,6 @@ class MetricsInfo;
 class OutputParams;
 class PainterInfo;
 class ParagraphParameters;
-class Toc;
 class WordLangTuple;
 class XHTMLStream;
 class otexstream;
diff --git a/src/Toc.h b/src/Toc.h
new file mode 100644
index 000..525b708
--- /dev/null
+++ b/src/Toc.h
@@ -0,0 +1,42 @@

Re: [patch] Display the correct horizontal alignment in AMS environments

[Guillaume Munch]

Le 06/01/2016 20:51, Georg Baum a écrit :


BTW, a proper solution for 9841 is much more important than these alignment
issues IMHO. The current situation is worse than before dc016de34ea.




I agree that the current situation regarding \output_change and 
\tracking_change is bad and should be fixed. I gave what I think is the 
proper solution, taking into account the debate that was on the list. 
The patch is very simple (see the earlier message: 
http://article.gmane.org/gmane.editors.lyx.devel/159493 and: 
http://www.lyx.org/trac/ticket/9841). Now what we would need for such a 
change is if developers who took part in the discussion looked and say: 
yes, this is the proper solution. I do not see this happening right now. 
Then, what is a proper solution? You want a file format increase + 
lyx2lyx + tex2lyx changes? I am more familiar with format increase now 
so it's easier for me, although: 1) please not while I have another 
format change pending because these things do not rebase very well, and 
2) I will need help for tex2lyx. Another solution is to revert as I have 
suggested.



Guillaume

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

[Scott Kostyshak]

On Fri, Jan 08, 2016 at 11:06:04PM +0100, Georg Baum wrote:
> Guillaume Munch wrote:

> > Also, because it took me a while to
> > figure out where the bind and ui format was defined. Nothing was
> > documented. (Is there a maintainer for Development.lyx who will validate
> > the CT'd changes?)
> 
> There is no maintainer for Development.lyx. Because of that and since it is 
> not supposed to be translated you don't need CT for this document IMHO.

+1. If you are just documenting something, go ahead. If you are
proposing a rule that LyX developers should follow, then this should be
discussed on the list but once there is agreement just commit (as Georg
says, no CT needed).

Scott


signature.asc
Description: PGP signature

Re: Tentative schedule for 2.2.0 release

[Richard Heck]

On 01/08/2016 12:24 PM, Scott Kostyshak wrote:
> On Fri, Jan 08, 2016 at 03:33:01AM -0800, José Matos wrote:
>> On Wednesday, November 11, 2015 06:56:12 PM Scott Kostyshak wrote:
>>> Yes file format freeze is before RC. Feature freeze will be before beta.
>>> For discussion see:
>>> https://www.mail-archive.com/search?l=mid=20151022164521.GA4654%40cotopaxi
>>> .att.net
>>>
>>> Scott
>> Hi Scott,
>>  apologies for not answering before.
>>
>> Regarding the file format freeze I suggest it to be the release time. There 
>> is 
>> no gain from requiring the file format to be frozen after the rc stage, and 
>> if 
>> some change goes after rc that is because it was considered important enough 
>> to warrant a nod from you.
>>
>> So I am suggesting that if some important fix, that involves a file format 
>> change, is considered for inclusion after the first release candidate it 
>> should still go on. Again I reiterate that this is for something that 
>> yourself 
>> regard as important.
>>
>> Another important criteria is that lyx2lyx code will be back-ported to lyx 
>> 2.1.x (x==5 ?) just after 2.2.0 release so any rc-stage change to the file 
>> format will not affect this.
>>
>> I have fought this battle before... :-)
>>
>> In the best case this is an academic discussion and no file format change 
>> will 
>> be necessary. :-)
>> -- 
>> José Abílio
> Hi José,
>
> Thanks for bringing this topic up. I am new as a release manager and
> also relatively new to LyX development so my ears are open. I agree with
> your reasoning and will be open to a file format change after RC if it
> fixes an important bug and if other developers agree.

yes, I think that is a sensible approach.

rh

beta release

[Scott Kostyshak]

I think we should delay beta. I was hoping that Uwe would be back by now
and ready for LyX development, but apparently he has been delayed. This
is understandable after a trip and perhaps I was too hopeful to release
beta two days after he got back. I propose to wait until he is back and
active on the list until we set a new date for beta. There are some
issues with the installer and some critical Windows-specific regressions
(#9900, #9892) that I think must be addressed before a beta release.

There has also been a lot of activity on the list recently, most likely
due to the list serve being down before then. It would be nice to get
some of the important patches into master and get at least a couple of
days of us developers testing the patches so that we do not waste a beta
release and thus prolong the release process by having to do another
beta release.

What patches that you are still waiting for a review have not gotten
enough attention? I know that some of Guillaume's patches are undergoing
a review. Are there others that have been forgotten that you think
should be considered for 2.2.0?

Georg's patch still needs a final +1:
https://www.mail-archive.com/search?l=mid=n6have%24b5i%244%40ger.gmane.org
JMarc did you have any other concerns with it? Does anyone else?

Is there anything that you need me in particular to look at?

Does any one view an issue as a beta blocker?

Scott


signature.asc
Description: PGP signature

Re: Questions for Uwe?

[Scott Kostyshak]

On Mon, Jan 04, 2016 at 10:58:13AM -0500, Scott Kostyshak wrote:
> On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote:
> > On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:
> > > Scott Kostyshak wrote:
> > > 
> > > > I don't understand how installers work for 32-bit vs 64-bit. Normally
> > > > does our Windows installer contain both 32-bit and 64-bit binaries? Or
> > > > we just release 32-bit and 64-bit systems are fine with it? Same for
> > > > Mac?
> > > 
> > > So far we have never released any 64bit windows binary. This is fine, 
> > > since 
> > > 64bit windows can execute 32bit binaries, and nobody complained yet about 
> > > LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would 
> > > not 
> > > switch to 64bit at this time, since this can introduce subtle bugs 
> > > (unfortunately the 64 C++ memory model differs on linux and windows, e.g. 
> > > long is 64bit on linux but 32bit on windows, so the fact that we have 
> > > working 64bit linux builds does not guarantee us working windows 64bit 
> > > builds).
> > 
> > I see. Thanks for the explanation. I agree we should not switch now.
> > 
> > Scott
> 
> Another question for Uwe. Can you still reproduce these two tickets?
> http://www.lyx.org/trac/ticket/9892
> http://www.lyx.org/trac/ticket/9900
> That is part of the reason why I am curious about Qt 5.6.0beta1. Maybe
> it makes those issues go away.
> 
> Scott

I have gone through this thread and tried to make a summary of the questions
and discussion for Uwe. Please add more questions if you have any or edit my
misinterpretation of the question/comment.

The following letters refer to the person that asked the question.

G=Georg
R=Richard
S=Scott

S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
and 5.6.0beta1?

S2. Can you make the installers from *only* the tar ball (and not use the
git directory at all)? Note that if there is a technical reason why this is 
difficult if you ask on the list I am guessing someone can help.

S3. Richard has been committing updates to po files. Can you confirm that all
translation updates we have received have been merged? Has anyone emailed 
updates to you privately?

R4. Do we also want to try releasing an installer built with mingw?
(G response: IMO, we only need to release one installer. The mingw and MSVC
builds behave exactly the same (modulo bugs). So the question is rather whether
we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be
MSVC, otherwise it will probably be mingw.

G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also build
the prerequisite from the sources Peter added, using exactly the same
compiler as is used to build LyX.

S6. Can you still reproduce these two tickets?
http://www.lyx.org/trac/ticket/9892
http://www.lyx.org/trac/ticket/9900
If so, do you think they are beta blockers?
That is part of the reason why I am curious about Qt 5.6.0beta1 (see question
S1). Maybe it makes those issues go away somehow.

Scott


signature.asc
Description: PGP signature

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

[Guillaume Munch]

Le 08/01/2016 22:06, Georg Baum a écrit :


It cannot see anything wrong.

There is no maintainer for Development.lyx. Because of that and since it is
not supposed to be translated you don't need CT for this document IMHO.


Ok



Looks good (lyx2lyx and prefs2prefs, I did not follow the original
discussion, so don't comment on the main changes).



Thank you, waiting for Jean-Marc's opinion then.


Guillaume

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

[Guenter Milde]

On 2016-01-08, Kornel Benko wrote:
> Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak 
> 
>> On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote:

...

>> > * 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.

> No it is not hackish IMHO. The test should show, that with a suitable
> font this file is compilable. It is a remnant from the times we had
> defined fonts for texF only. If the non-tex font is defined in the
> document, it will be used.

There are two points here:

* The font replacement in the test machinery was a justified workaround
  to test export when setting both tex and non-tex fonts in the source
  was not possible.
  
  With LyX 2.2, this is no longer needed and should be replaced by a font
  setting in the source. This allows easier verification of problems "by
  hand".

* Setting both, mainfont and sansfont to the same sans-serif font to prevent
  a false positive error and get a working export instead of a test failure
  due to a reported bug is imo not the right thing.
  
  
Günter  
 

Re: Update boost in 2.1 branch?

[Richard Heck]

On 01/08/2016 05:06 AM, Jean-Marc Lasgouttes wrote:
>
> Currently we use boost 1.53 in 2.1 branch. Would it be a good move to
> update it to 1.60? I am getting loads of warnings with gcc 5.1.

Fine with me, and I see the same warnings.

Richard

Re: [PATCH] compilation fix for libc++ in C++11 mode

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> The following patch fixes compilation for me with clang and libc++ (with
> autotools I set CXX="clang++ --stdlib=libc++").
> 
> This is a workaround to https://llvm.org/bugs/show_bug.cgi?id=24137
> to be fixed in 3.7.1 or 3.8.0.
> 
> Can someone confirm that adding the default constructor like that is
> harmless?

It is to my knowledge. It might even fix a subtle problem with older MSVC:
http://stackoverflow.com/questions/3931312/value-initialization-and-non-pod-types/3931589#3931589


Georg

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

[Georg Baum]

Guillaume Munch wrote:

> 
> To be honest, I did not even know that this existed until recently
> because there was no UI for it. This requirement seems very
> abstract to me. But I have updated Development.lyx to reflect the
> new policy to be sure everybody else is going to respect it. Feel free
> to correct it (once it is pushed).

It cannot see anything wrong.

> Also, because it took me a while to
> figure out where the bind and ui format was defined. Nothing was
> documented. (Is there a maintainer for Development.lyx who will validate
> the CT'd changes?)

There is no maintainer for Development.lyx. Because of that and since it is 
not supposed to be translated you don't need CT for this document IMHO.

>> Duplicating the code in prefs2prefs and lyx2lyx is not a 100% perfect
>> solution, but an acceptable compromise IMHO since this code gets written
>> once and does not need to be maintained.
> 
> Ok, this is what I did.

Looks good (lyx2lyx and prefs2prefs, I did not follow the original 
discussion, so don't comment on the main changes).


Georg

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

[Guillaume Munch]

Le 08/01/2016 21:47, Georg Baum a écrit :

Is there a reason why the scripts do not have exec permissions?


I guess it is lazyness.





I would not spend any time in non-python scripts, but convert them to python
if problems occur.




So I can chmod +x all the scripts?


Guillaume

Re: why Babel with dvi3 (LuTeX)?

[Scott Kostyshak]

On Fri, Jan 08, 2016 at 09:47:21PM +, Guenter Milde wrote:
> On 2016-01-08, Scott Kostyshak wrote:
> > On Fri, Jan 08, 2016 at 06:31:37AM +, Guenter Milde wrote:
> >> On 2016-01-08, Scott Kostyshak wrote:
> 
> > Here is the diff:
> 
> >   $ diff ctests_d7ff8c6e/LastTestsFailed.log
> >   ctests_d7ff8c6e_with_patch/LastTestsFailed.log 
> >   0a1,2
> >  > 218:AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_texF
> >  > 
> > 219:INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF
> 
> A typo in the filter pattern.
> 
> >  > 3718:UNRELIABLE.NONSTANDARD_export/templates/kluwer_dvi3_systemF
> 
> This is tagged "unreliable" because it is known to fail st at some places or
> sometimes. 
> 
> Summary: There is no real regression due to the changes introduced by the
> patch. All changes in test results highlighted existing problems with either
> polyglossia or babel.
> 
> My suggestion is to commit the patch and do test filter adaption in a
> cleanup.

OK please commit. I think we are in a "special" situation now with the
tests because thanks to your help we are finally doing some important
restructuring and fixes. In the future, I would prefer for the test
output not to change (i.e. no planning of subsequent cleanup patches).
Everything should be done in one patch. But for now it is fine with me.

Thanks again for all of your work on the patches.

Scott


signature.asc
Description: PGP signature

Re: Status on Mac with El Capitan

[Kornel Benko]

Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt 
> > OR (maybe)
> >   include_directories((BEFORE
> > ${TOP_SRC_DIR}/src/tex2lyx
> > ${TOP_SRC_DIR}/src/support/minizip)
> >   include_directories(${ZLIB_INCLUDE_DIR})
> 
> Yes, this works too. BTW, what is "src/support/minizip“ for?
> It doesn’t exist in the master checkout.
> Why should "src/tex2lyx“ come before other includes?
> 
> Stephan

I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include".

Kornel

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

Re: Keywords required for the software center

[José Matos]

On Thursday, January 07, 2016 08:07:18 PM 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
> 
> Richard.

Probably for historical reasons, that we did not revisit before. :-)

Initially there was not any desktop file in the lyx sources and so we had to 
carry one in the srpm.

Digging a little bit more I found that the lyx.desktop was introduced to lyx 
in 2011:
http://www.lyx.org/trac/changeset/40386/lyxsvn

I will poke Rex in bugzilla about this.

Thank you for bringing this to our attention. :-)

Regards,
-- 
José Abílio

Re: Tentative schedule for 2.2.0 release

[José Matos]

On Wednesday, November 11, 2015 06:56:12 PM Scott Kostyshak wrote:
> Yes file format freeze is before RC. Feature freeze will be before beta.
> For discussion see:
> https://www.mail-archive.com/search?l=mid=20151022164521.GA4654%40cotopaxi
> .att.net
> 
> Scott

Hi Scott,
apologies for not answering before.

Regarding the file format freeze I suggest it to be the release time. There is 
no gain from requiring the file format to be frozen after the rc stage, and if 
some change goes after rc that is because it was considered important enough 
to warrant a nod from you.

So I am suggesting that if some important fix, that involves a file format 
change, is considered for inclusion after the first release candidate it 
should still go on. Again I reiterate that this is for something that yourself 
regard as important.

Another important criteria is that lyx2lyx code will be back-ported to lyx 
2.1.x (x==5 ?) just after 2.2.0 release so any rc-stage change to the file 
format will not affect this.

I have fought this battle before... :-)

In the best case this is an academic discussion and no file format change will 
be necessary. :-)
-- 
José Abílio

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

[Pavel Sanda]

Guillaume Munch wrote:
> So I can chmod +x all the scripts?

Looks like good idea. P

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

[Georg Baum]

Guillaume Munch wrote:

> 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 guess it is lazyness.

>> 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.
>>
> 
> 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.

Looks good.

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

Dunno. There was a time when the zoo of script languages was reduced and all 
non-python scripts were rewritten in python, but somehow other script 
languages keep creeping in. I'd prefer if we could stick to python in the 
future again.

I would not spend any time in non-python scripts, but convert them to python 
if problems occur.


Georg

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

[Scott Kostyshak]

On Fri, Jan 08, 2016 at 08:11:19PM +0100, Kornel Benko wrote:
> Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak 
> 
> > On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote:

> > > * 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.
> 
> No it is not hackish IMHO. The test should show, that with a suitable font 
> this file is compilable.
> It is a remnant from the times we had defined fonts for texF only.
> If the non-tex font is defined in the document, it will be used.

I agree with Kornel that it is not hackish of the tests. I think what
Günter's main underlying point (please correct me if I'm wrong) is to
make it clear that *LyX* (not the tests) should have a better framework
for encouraging system fonts by default for XeTeX and LuaTeX.

But since LyX does not do that, my opinion is that it is a great idea
for the tests to do the best job they can at testing the use of system
fonts. Note that we do not always use FreeSans---it depends on the
language.

Scott


signature.asc
Description: PGP signature

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

[Pavel Sanda]

Scott Kostyshak wrote:
> I do observe this problem on 2.1.x.

Cool, so we don't see regression in terms of lyx codebase :)
P

Update boost in 2.1 branch?

[Jean-Marc Lasgouttes]

Currently we use boost 1.53 in 2.1 branch. Would it be a good move to 
update it to 1.60? I am getting loads of warnings with gcc 5.1.


JMarc

Re: Status on Mac with El Capitan

[Kornel Benko]

Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt 
> Am 08.01.2016 um 11:53 schrieb Kornel Benko :
> > 
> > Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt 
> > 
> >>> OR (maybe)
> >>>  include_directories((BEFORE
> >>>${TOP_SRC_DIR}/src/tex2lyx
> >>>${TOP_SRC_DIR}/src/support/minizip)
> >>>  include_directories(${ZLIB_INCLUDE_DIR})
> >> 
> >> Yes, this works too. BTW, what is "src/support/minizip“ for?
> >> It doesn’t exist in the master checkout.
> >> Why should "src/tex2lyx“ come before other includes?
> >> 
> >> Stephan
> > 
> > I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.
> 
> Yes, but what’s the gain of having "src/tex2lyx“ before other includes?

Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing 
it.
I wanted to change as little as possible.

> The removal of the BEFORE keyword did the job too.

Sure.

> Stephan

Kornel

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

Re: Status on Mac with El Capitan

[Stephan Witt]

Am 08.01.2016 um 11:53 schrieb Kornel Benko :
> 
> Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt 
>>> OR (maybe)
>>>  include_directories((BEFORE
>>>${TOP_SRC_DIR}/src/tex2lyx
>>>${TOP_SRC_DIR}/src/support/minizip)
>>>  include_directories(${ZLIB_INCLUDE_DIR})
>> 
>> Yes, this works too. BTW, what is "src/support/minizip“ for?
>> It doesn’t exist in the master checkout.
>> Why should "src/tex2lyx“ come before other includes?
>> 
>> Stephan
> 
> I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“.

Yes, but what’s the gain of having "src/tex2lyx“ before other includes?

The removal of the BEFORE keyword did the job too.

Stephan

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

[Scott Kostyshak]

On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote:
> On 2016-01-07, Scott Kostyshak wrote:

> 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!

Good point. I forget whether this is currently possible.

> 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)

Good points. Maybe we should put something about this in Development.lyx
since the topic does come up frequently. Maybe you already did. I did
not check.

> 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).

Indeed. From what i understand, our file as it is should compile when TL
2016 is released in a few months.

> * 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"

The example file only compiles on an old system and (hopefully) on a
future system (when TL 2016 is released).

Thanks for the in-depth response and advice, Günter. I don't plan on
spending any more time on this particular issue until 2016 is released
and then I will check if that changes anything. In the mean time I'm
fine with making the test a suspiciousTest or whatever else you and
Kornel prefer.

Scott


signature.asc
Description: PGP signature

Re: Tentative schedule for 2.2.0 release

[Scott Kostyshak]

On Fri, Jan 08, 2016 at 03:33:01AM -0800, José Matos wrote:
> On Wednesday, November 11, 2015 06:56:12 PM Scott Kostyshak wrote:
> > Yes file format freeze is before RC. Feature freeze will be before beta.
> > For discussion see:
> > https://www.mail-archive.com/search?l=mid=20151022164521.GA4654%40cotopaxi
> > .att.net
> > 
> > Scott
> 
> Hi Scott,
>   apologies for not answering before.
> 
> Regarding the file format freeze I suggest it to be the release time. There 
> is 
> no gain from requiring the file format to be frozen after the rc stage, and 
> if 
> some change goes after rc that is because it was considered important enough 
> to warrant a nod from you.
> 
> So I am suggesting that if some important fix, that involves a file format 
> change, is considered for inclusion after the first release candidate it 
> should still go on. Again I reiterate that this is for something that 
> yourself 
> regard as important.
> 
> Another important criteria is that lyx2lyx code will be back-ported to lyx 
> 2.1.x (x==5 ?) just after 2.2.0 release so any rc-stage change to the file 
> format will not affect this.
> 
> I have fought this battle before... :-)
> 
> In the best case this is an academic discussion and no file format change 
> will 
> be necessary. :-)
> -- 
> José Abílio

Hi José,

Thanks for bringing this topic up. I am new as a release manager and
also relatively new to LyX development so my ears are open. I agree with
your reasoning and will be open to a file format change after RC if it
fixes an important bug and if other developers agree.

Scott


signature.asc
Description: PGP signature

Re: why Babel with dvi3 (LuTeX)?

[Scott Kostyshak]

On Fri, Jan 08, 2016 at 06:31:37AM +, Guenter Milde wrote:
> 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?

Here is the diff:

  $ diff ctests_d7ff8c6e/LastTestsFailed.log
  ctests_d7ff8c6e_with_patch/LastTestsFailed.log 
  0a1,2
  > 218:AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_texF
  > 
219:INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF
  > 3718:UNRELIABLE.NONSTANDARD_export/templates/kluwer_dvi3_systemF

Can you reproduce the differences when running the tests manually?

Scott


signature.asc
Description: PGP signature