Re: [PATCH] Re: Update boost in 2.1 branch?

[Kornel Benko]

Am Freitag, 22. Januar 2016 um 11:27:02, schrieb Jean-Marc Lasgouttes 

> Le 21/01/2016 22:40, Richard Heck a écrit :
> > On 01/21/2016 04:07 PM, Pavel Sanda wrote:
> >> I guess it also depends how much space for error we have...
> >> Richard, do you plan to release one intermediate 2.1.x or you just waiting 
> >> for the final one?
> >
> > How far out do we realistically think 2.2.0 is? I am thinking end of
> > February, but if it gets delayed any further we might think about an
> > intermediate release.
> >
> > Really, I should have done 2.1.5 back at the end of November, but I
> > thought 2.2 was closer.
> 
> One solution would be to have a 2.1.5 together with 2.2beta with an 
> updated lyx2lyx that reads 2.2beta format. A good occasion to make 
> people exercise this code.
> 
> And then 2.1.6 would just be the usual final version.
> 
> JMarc

Even with this patch, I could not compile src/support/ForkedCalls.cpp with 
gcc-4.8.4.
...
cd /usr/BUILD/BuildLyx2.1Git/src/support && /usr/bin/c++   
-DLYX_CALLSTACK_PRINTING -DQT_CORE_LIB -I/usr/BUILD/BuildLyx2.1Git 
-I/usr/src/lyx/lyx-2.0.x-git/src -I/usr/include/enchant 
-I/usr/src/lyx/lyx-2.0.x-git/boost -I/usr/src/lyx/lyx-2.0.x-git/src/support 
-I/usr/BUILD/BuildLyx2.1Git/src/support 
-I/usr/src/lyx/lyx-2.0.x-git/src/support/mythes -isystem 
/usr/BUILD/BuildQt5/5.5/gcc_64/include -isystem 
/usr/BUILD/BuildQt5/5.5/gcc_64/include/QtCore -isystem 
/usr/BUILD/BuildQt5/5.5/gcc_64/./mkspecs/linux-g++  -Wall -Wunused-parameter 
--std=gnu++11 -fno-strict-aliasing  -Wall -Wunused-parameter --std=gnu++11 
-fno-strict-aliasing -O0 -g3 -D_DEBUG   -DBOOST_USER_CONFIG="" -fPIC 
-o CMakeFiles/support.dir/ForkedCalls.cpp.o -c 
/usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp
In file included from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.h:19:0,
 from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp:17:
/usr/src/lyx/lyx-2.0.x-git/boost/boost/signal.hpp:17:4: warning: #warning 
"Boost.Signals is no longer being maintained and is now deprecated. Please 
switch to Boost.Signals2. To disable this warning message, define 
BOOST_SIGNALS_NO_DEPRECATION_WARNING." [-Wcpp]
 #  warning  "Boost.Signals is no longer being maintained and 
is now deprecated. Please switch to Boost.Signals2. To disable this warning 
message, define BOOST_SIGNALS_NO_DEPRECATION_WARNING."
^
In file included from 
/usr/src/lyx/lyx-2.0.x-git/boost/boost/function/detail/maybe_include.hpp:23:0,
 from 
/usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function2.hpp:11,
 from 
/usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/detail/named_slot_map.hpp:17,
 from 
/usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/detail/signal_base.hpp:15,
 from 
/usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/signal_template.hpp:22,
 from 
/usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/signal0.hpp:24,
 from /usr/src/lyx/lyx-2.0.x-git/boost/boost/signal.hpp:27,
 from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.h:19,
 from /usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp:17:
/usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp: In 
instantiation of ‘static void 
boost::detail::function::void_function_obj_invoker2::invoke(boost::detail::function::function_buffer&, T0, T1) [with 
FunctionObj = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int]’:
/usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:937:38:   
required from ‘void boost::function2::assign_to(Functor) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int]’
/usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:727:7:   
required from ‘boost::function2::function2(Functor, typename 
boost::enable_if_c<(! boost::is_integral::value), int>::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int; typename 
boost::enable_if_c<(! boost::is_integral::value), int>::type = int]’
/usr/src/lyx/lyx-2.0.x-git/boost/boost/function/function_template.hpp:1073:16:  
 required from ‘boost::function::function(Functor, typename 
boost::enable_if_c<(! boost::is_integral::value), int>::type) [with 
Functor = std::tr1::_Bind, 
std::tr1::_Placeholder<2>))(int, int)>; R = void; T0 = int; T1 = int; typename 
boost::enable_if_c<(! boost::is_integral::value), int>::type = int]’
/usr/src/lyx/lyx-2.0.x-git/boost/boost/signals/slot.hpp:111:122:   required 
from ‘boost::slot::slot(const F&) [with F = std::tr1::_Bind, std::tr1::_Placeholder<2>))(int, int)>; 
SlotFunction = boost::function]’
/usr/src/lyx/lyx-2.0.x-git/src/support/ForkedCalls.cpp:562:67:   required from 
here

Re: Test results for 2.2.0dev on Mac

[Georg Baum]

Stephan Witt wrote:

> There is some change required because tex2lyx has the same problem itself.
> I’ve changed this for the lyx binary here:
> 
> http://www.lyx.org/trac/changeset/6e9bd23/lyxgit
> 
> Attached is a similar change to correct it for tex2lyx. Ok to commit?

I do not understand why this is needed, but since it works for LyX and you 
are the only one who can test it you have my +1 for tex2lyx.


Georg

Re: Test results for 2.2.0dev on Mac

[Stephan Witt]

Am 22.01.2016 um 21:01 schrieb Georg Baum :
> 
> Stephan Witt wrote:
> 
>> There is some change required because tex2lyx has the same problem itself.
>> I’ve changed this for the lyx binary here:
>> 
>> http://www.lyx.org/trac/changeset/6e9bd23/lyxgit
>> 
>> Attached is a similar change to correct it for tex2lyx. Ok to commit?
> 
> I do not understand why this is needed,

It works like that:

The binary contains references to shared system libraries with
paths on Mac. References to non-standard libraries can be
made with hard absolute paths (not nice) or they can be relative.

The Qt4-libraries are built by qmake with the first option.
Therefore I had to make them relative while creating the disk
image. The Qt5-libraries are built with the so called @rpath
based path. This works like an indirection - there can be many
RC_RPATH entries inside the binary. I they are missing the
dynamic linker fails at program startup with the Qt5 libraries.

The command line options

-Wl,-rpath,@loader_path/../Frameworks and
-Wl,-rpath,@executable_path/../Frameworks

are passed to the linker and are telling it to add two items
to the RC_RPATH list of the binary: @executable_path is relative
to the loaded executable (e.g. tex2lyx or lyx) and @loader_path
is useful for plug-ins loaded by the running executable later.

The differences can be seen with the otool utility:

$ otool -L lyx-build/*.build/src/tex2lyx/tex2lyx
lyx-build/LyX-2.1.5dev.build/src/tex2lyx/tex2lyx:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(compatibility version 45.0.0, current version 1404.32.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
7.0.0)

/Users/Shared/LyX/qt-4.8.6-frameworks-cocoa-x86_64/lib/QtCore.framework/Versions/4/QtCore
 (compatibility version 4.8.0, current version 4.8.6)

/Users/Shared/LyX/qt-4.8.6-frameworks-cocoa-x86_64/lib/QtGui.framework/Versions/4/QtGui
 (compatibility version 4.8.0, current version 4.8.6)
/Users/stephan/git/lyx-build/utilities/lib/libhunspell-1.3.0.dylib 
(compatibility version 1.0.0, current version 1.0.0)
/Users/stephan/git/lyx-build/utilities/lib/libaspell.15.dylib 
(compatibility version 17.0.0, current version 17.5.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.5)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1226.10.1)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1256.14.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
(compatibility version 1.0.0, current version 728.6.0)
lyx-build/LyX-2.2.0dev.build/src/tex2lyx/tex2lyx:
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(compatibility version 45.0.0, current version 1404.32.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
7.0.0)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.5.0, 
current version 5.5.1)
@rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility 
version 5.5.0, current version 5.5.1)
@rpath/QtSvg.framework/Versions/5/QtSvg (compatibility version 5.5.0, 
current version 5.5.1)
@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 
5.5.0, current version 5.5.1)
@rpath/QtMacExtras.framework/Versions/5/QtMacExtras (compatibility 
version 5.5.0, current version 5.5.1)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.5.0, 
current version 5.5.1)
/Users/Shared/LyX/utilities/lib/libhunspell-1.3.0.dylib (compatibility 
version 1.0.0, current version 1.0.0)
/Users/Shared/LyX/utilities/lib/libaspell.15.dylib (compatibility 
version 17.0.0, current version 17.5.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.5)
/Users/Shared/LyX/utilities/lib/libmagic.1.dylib (compatibility version 
2.0.0, current version 2.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1226.10.1)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1256.14.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
(compatibility version 1.0.0, current version 728.6.0)

> but since it works for LyX and you 
> are the only one who can test it you have my +1 for tex2lyx.

Thanks.

Stephan

Re: Test results for 2.2.0dev on Mac

[Georg Baum]

Stephan Witt wrote:

> $ lyx-build/cmake/2.2.0dev/bin/Debug/tex2lyx
> tex2lyx: Not enough arguments.
> Usage: tex2lyx [options] infile.tex [outfile.lyx]
> …
> -sysdir SYSDIR Set system directory to SYSDIR.
> Default: /Users/stephan/git/lyx/lib/
> -userdir USERDIR   Set user directory to USERDIR.
> Default: /Users/stephan/Library/Application Support/LyX/tex2lyx/LyX/

I do understand now what happens. The path is built like this on OS X:

$HOME/Library/Application Support/$org/$app/$package/

where $org is the organization name (always "LyX", set by 
QCoreApplication::setOrganizationName(), and $app is either "LyX", "tex2lyx" 
or "client" (set by QCoreApplication::setApplicationName()). If the build 
was configured with a version suffix then this suffix is added to all three 
names. The path excluding $package is returned by qt, $package is added by 
ourselves. $package is the same string for all three applications, and by 
construction equal to $app in case of LyX (see 
LyXConsoleApp::LyXConsoleApp() or GuiApplication::GuiApplication())

Therefore, if we want to comply to the OS X rules for constructing the user 
data directory path, and at the same time to use the same directory for LyX, 
tex2lyx and client, we simply have to pop off the last component of the path 
returned by qt before adding package. This is what the attached patch does.

Stephan, does it work? Note that this is not a regression (2.1 has the same 
code), so it is not really urgent. If we apply it, we need to be aware that 
the user directory would change for LyX compared to earlier releases.


Georg
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index de06c19..cc20b09 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -689,13 +689,19 @@ FileName const get_default_user_support_dir(FileName const & home_dir)
 	os::GetFolderPath win32_folder_path;
 	return FileName(addPath(win32_folder_path(os::GetFolderPath::APPDATA), PACKAGE));
 
-#elif defined (USE_MACOSX_PACKAGING) && (QT_VERSION >= 0x05)
-	(void)home_dir; // Silence warning about unused variable.
-	return FileName(addPath(fromqstr(QStandardPaths::writableLocation(QStandardPaths::DataLocation)), PACKAGE));
-
 #elif defined (USE_MACOSX_PACKAGING)
 	(void)home_dir; // Silence warning about unused variable.
-	return FileName(addPath(fromqstr(QDesktopServices::storageLocation(QDesktopServices::DataLocation)), PACKAGE));
+#if QT_VERSION >= 0x05
+	string const appPath = fromqstr(QStandardPaths::writableLocation(QStandardPaths::DataLocation));
+#else
+	string const appPath = fromqstr(QDesktopServices::writableLocation(QDesktopServices::DataLocation));
+#endif
+	// appPath is "$HOME/Library/Application Support/$org/$app", where
+	// $org is "LyX" (set by QCoreApplication::setOrganizationName())
+	// and $app is equal to PACKAGE for LyX, and "tex2lyx" PROGRAM_SUFFIX for tex2lyx etc.
+	// Since we need to share the same user directory for LyX, tex2lyx and client,
+	// we need to strip the last path component and add PACKAGE.
+	return FileName(addPath(onlyPath(appPath), PACKAGE));
 
 #elif defined (USE_HAIKU_PACKAGING)
 	return FileName(addPath(home_dir.absFileName(), string("/config/settings/") + PACKAGE));

Re: What does new module paralist do?

[Scott Kostyshak]

On Fri, Jan 22, 2016 at 08:48:37PM +0100, Georg Baum wrote:
> Georg Baum wrote:
> 
> > Thanks Uwe and Richard, I did not think of an example file. BTW, the
> > enumitem module does not have one either.
> > 
> > Richard Heck wrote:
> > 
> >> On 01/19/2016 05:28 AM, Richard Heck wrote:
> >>>
> >>> Can this be used with enumitem? I'm guessing maybe not. And if not,
> >>> then we should put an exclusion into the module.
> > 
> > I think an exclusion makes sense (see attached).
> 
> Seems I forgot the attachment. Is this OK?

+1

Scott


signature.asc
Description: PGP signature

Re: Test results for 2.2.0dev on Mac

[Kornel Benko]

Am Freitag, 22. Januar 2016 um 21:01:42, schrieb Georg Baum 

> Stephan Witt wrote:
> 
> > There is some change required because tex2lyx has the same problem itself.
> > I’ve changed this for the lyx binary here:
> > 
> > http://www.lyx.org/trac/changeset/6e9bd23/lyxgit
> > 
> > Attached is a similar change to correct it for tex2lyx. Ok to commit?
> 
> I do not understand why this is needed, but since it works for LyX and you 
> are the only one who can test it you have my +1 for tex2lyx.
> 

The same is probably needed at src/tex2lyx/CMakeLists.txt:66

> Georg

Kornel

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

Re: Test results for 2.2.0dev on Mac

[Georg Baum]

Stephan Witt wrote:

>> Am 22.01.2016 um 05:43 schrieb Scott Kostyshak :
>> 
>> Note that if this is a regression and if the tex2lyx test used to work
>> before, it would be very easy to do a 'git bisect'. It could be done
>> automatically by doing 'git bisect run' (When a ctest fails it exits
>> with error). I think Stephan would have to do it though because it is
>> only for him that the ctest is failing.
> 
> This would be an option if one can say which commit for good can be used.
> But I can try this later.

One quick test would be to try whether it works in 2.1.


Georg

Re: Test results for 2.2.0dev on Mac

[Georg Baum]

Stephan Witt wrote:

> Am 22.01.2016 um 21:01 schrieb Georg Baum
> :
>> 
>> Stephan Witt wrote:
>> 
>>> There is some change required because tex2lyx has the same problem
>>> itself. I’ve changed this for the lyx binary here:
>>> 
>>> http://www.lyx.org/trac/changeset/6e9bd23/lyxgit
>>> 
>>> Attached is a similar change to correct it for tex2lyx. Ok to commit?
>> 
>> I do not understand why this is needed,
> 
> It works like that:

Thanks for the explanation!


Georg

Re: Test results for 2.2.0dev on Mac

[Georg Baum]

Stephan Witt wrote:

> No. It’s not wrong. You’re right with the use of the _own_ userdir
> for tests. But the real life matters too. It’s the wrong userdir
> for standard orpeation. And this is Georg message, IMO.

Yes. Also, depending on the reaason for the wrong default user dir, also the 
special one passed on the command line of the tests might have been used 
incorrectly by tex2lyx.

I had a closer look, and I am now pretty sure that this is not the case: The 
user dir for the tests seems to work well, and the default user dir is not a 
regression (see my other mail). Since we do not know whether the failing 
tests are a regression, I am not sure anymore whether they should be 
considered a beta blocker or not.

In the log of the failing tests one can see some strange things. For 
example, the CJK tests contain the line

sepackage{CJKutf8}

in the preamble. somehow the first two letters of \usepackage have been 
swallowed. Also, \setlength{\parindent}{3mm} in test-insets.tex is 
completely swallowed and not parsed.

Stephan, can you reproduce one of the failing tests when running tex2lyx 
manually? If yes, the quickest way to find the cause of the failing tests 
would be to run it in the debugger and to step through the preamble parsing 
code. Something is really fishy there.


Georg

Re: [PATCH] Re: Update boost in 2.1 branch?

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> This is in C++11 mode, right? By default (c++98) it should just work
> IMO. I do not think that we have firm plans of making lyx 2.1 compile in
> C++11 mode.

C++11 does not matter for 2.1 IMHO. Compilers will support C++98 much longer 
than 2.1 will be relevant, and even if that means to enable it by special 
command line options users can pass them to configure.

> I guess the TR1 support is finally biting us back. We could let the code
> in, but remove the #define LYX_USE_TR1 in conifg.h.

I would rather not touch it for gcc. Can we remove it just for clang?


Georg

Regression in fr.po

[Guillaume Munch]

Dear list,


The log at the top of fr.po in master ends as follows:


# --
# 3 avril 2014 : mise à jour pour 2.1.0
# --
# 23 mars 2015 : synchronisation avec les modifications de fr.po pour 2.1
#et traduction des nouveaux messages
#Traduction de « commit » par « validation »
#Unification de la dénomination de « FiXme »
#FiXme et TODO non traduits
# --
# 20 avril 2015 : retour à la typo Fixme au lieu de FiXme suite à un échange
# avec Jûrgen Spitzmûller
# --
# 29 décembre 2015 : mise à jour en vue de 2.2.0
# --
# 02 janvier 2016 : résolution de conflits de raccourcis
#   revue du vocabulaire du module Boîtes graphiques
# --


The same log in 2.1.x ends as follows:


# --
# 18 janvier 2015 : mise à jour pour 2.1.3
# --
# 24 février 2015 : suite traduction du manuel des légendes multilingues,
#   modification de quelques traductions
#   résolution de quelque conflits de raccourcis non 
détectés

# --
# 23 mars 2015 : correction de quelques traductions suite synchro fr.po 
pour 2.2

# --
# 19 mai 2015 : traduction des messages du module PDF forms
# --
# 18 juin 2015 : revue de la traduction des menus de formulaires PDF
# --
# 15 septembre 2015 : correction de raccourcis clavier problématiques
#(bogues #9745 & #9761) - Guillaume Munch
# --


In particular, the corrections from 15 Sept. 2015 are lost between
stable and master ("Search" and "Replace" share the same accelerator R
again in every dialog). At the time of my patch, I was told to commit to
stable because it would automatically be merged into master at string
freeze.

Were the instructions given to me the correct ones? How come we have
lost those fixes? Is it just a local problem or does that indicate that
there may be other regressions with other translations? What do we do to
repair this?

In particular during the discussion at the time it appeared that the
translation process was not properly documented, maybe people do not
yet agree on the process.


Sincerely,
Guillaume

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

[Guillaume Munch]

Le 21/01/2016 20:07, Uwe Stöhr a écrit :

Am 21.01.2016 um 07:06 schrieb Guillaume Munch:


The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one.


I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied. Could you give me a recipe?

Besides this, my bug report
http://www.lyx.org/trac/ticket/1497
is about the alignment within LyX and this is for me not changed with
your patch. Therefore I don't think that you fixed bug #1497 too.



Ok. Can you please tell me what issue you are referring to precisely in
#1497 then?

At first the bug is about wrong alignment in the "multline" environment.
But this has been fixed some time ago by Georg (the first line is
aligned to the left, the last line to the right).

Then you wrote "The wrong alignment of multiline equations inside LyX is
still in LyX 2.1.3", and with "multiline" I understood the other
multi-line math environments because to me multline is fixed.

In particular the above recipe is meant for align, aligned, etc.


Guillaume

Re: What does new module paralist do?

[Georg Baum]

Georg Baum wrote:

> Thanks Uwe and Richard, I did not think of an example file. BTW, the
> enumitem module does not have one either.
> 
> Richard Heck wrote:
> 
>> On 01/19/2016 05:28 AM, Richard Heck wrote:
>>>
>>> Can this be used with enumitem? I'm guessing maybe not. And if not,
>>> then we should put an exclusion into the module.
> 
> I think an exclusion makes sense (see attached).

Seems I forgot the attachment. Is this OK?


Georgdiff --git a/lib/layouts/paralist.module b/lib/layouts/paralist.module
index 2e42cbb..3083440 100644
--- a/lib/layouts/paralist.module
+++ b/lib/layouts/paralist.module
@@ -11,6 +11,8 @@
 
 Format 59
 
+ExcludesModule enumitem
+
 AddToPreamble
 	\usepackage{paralist}
 EndPreamble

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

[Guillaume Munch]

Le 21/01/2016 20:07, Uwe Stöhr a écrit :

Am 21.01.2016 um 07:06 schrieb Guillaume Munch:


The alignment is set correctly on opening. Wrong alignment appears when
modifying columns. To see the bug, try to see how the behaviour changes
when adding or deleting columns repeatedly after the first one.


I tried this but cannot see a problem in LyX 2.1.4 compared to LyX 2.2
with your patches applied. Could you give me a recipe?

Besides this, my bug report
http://www.lyx.org/trac/ticket/1497
is about the alignment within LyX and this is for me not changed with
your patch. Therefore I don't think that you fixed bug #1497 too.



Can you please tell me what issue you are referring to precisely in
#1497 then?

At first the bug is about wrong alignment in the "multline" environment.
But this has been fixed some time ago by Georg (the first line is
aligned to the left, the last line to the right).

Then you wrote "The wrong alignment of multiline equations inside LyX is
still in LyX 2.1.3", and with "multiline" I understood the other
multi-line math environments because to me multline is fixed.

In particular the above recipe is meant for align, aligned, etc.


Guillaume

Re: [PATCH] Re: Update boost in 2.1 branch?

[Jean-Marc Lasgouttes]

Le 21/01/2016 22:40, Richard Heck a écrit :

On 01/21/2016 04:07 PM, Pavel Sanda wrote:

I guess it also depends how much space for error we have...
Richard, do you plan to release one intermediate 2.1.x or you just waiting for 
the final one?


How far out do we realistically think 2.2.0 is? I am thinking end of
February, but if it gets delayed any further we might think about an
intermediate release.

Really, I should have done 2.1.5 back at the end of November, but I
thought 2.2 was closer.


One solution would be to have a 2.1.5 together with 2.2beta with an 
updated lyx2lyx that reads 2.2beta format. A good occasion to make 
people exercise this code.


And then 2.1.6 would just be the usual final version.

JMarc

Re: Test results for 2.2.0dev on Mac

[Stephan Witt]

Am 21.01.2016 um 22:24 schrieb Georg Baum :
> 
> Stephan Witt wrote:
> 
>> $ lyx-build/cmake/2.2.0dev/bin/Debug/tex2lyx
>> tex2lyx: Not enough arguments.
>> Usage: tex2lyx [options] infile.tex [outfile.lyx]
>> …
>> -sysdir SYSDIR Set system directory to SYSDIR.
>> Default: /Users/stephan/git/lyx/lib/
>> -userdir USERDIR   Set user directory to USERDIR.
>> Default: /Users/stephan/Library/Application Support/LyX/tex2lyx/LyX/
> 
> Ah, now we are getting somewhere. The systemdir is fine, the userdir is 
> wrong. It should be
> 
> /Users/stephan/Library/Application Support/LyX/
> 
> if you compiled without version suffix and
> 
> /Users/stephan/Library/Application Support/LyX2.2/
> 
> if you compiled with version suffix.

Yes. That’s true. It should be "/Users/stephan/Library/Application 
Support/LyX-2.2“.

>> Long answer:
>> 
>> 1) The first hurdle is the wrong linker command for the check binaries on
>> Mac.
>> 
>> $ (cd lyx-build/LyX-2.2.0dev.build;make alltests)
>> PASS: tests/test_convert
>> FAIL: tests/test_filetools
>> PASS: tests/test_lstrings
>> PASS: tests/test_trivstring
> 
> This needs to be fixed but it is not urgent, since these test programs are 
> not needed for the tex2lyx tests.

There is some change required because tex2lyx has the same problem itself.
I’ve changed this for the lyx binary here:

http://www.lyx.org/trac/changeset/6e9bd23/lyxgit

Attached is a similar change to correct it for tex2lyx. Ok to commit?

Stephan



INSTALL_MACOSX-rpath.patch
Description: Binary data

Finding Qt on Windows with CMake GUI

[Peter Kümmel]

Just for the record:

When configuring LyX on Windows with cmake-gui,
CMAKE_PREFIX_PATH  must point to a Qt installation like
"C:/Qt/Qt5.5.1/5.5/msvc2010".

Peter

Re: Test results for 2.2.0dev on Mac

[Stephan Witt]

Am 22.01.2016 um 12:16 schrieb Kornel Benko :
> 
> Am Donnerstag, 21. Januar 2016 um 22:24:58, schrieb Georg Baum 
> 
>> Stephan Witt wrote:
>> 
>>> $ lyx-build/cmake/2.2.0dev/bin/Debug/tex2lyx
>>> tex2lyx: Not enough arguments.
>>> Usage: tex2lyx [options] infile.tex [outfile.lyx]
>>> …
>>> -sysdir SYSDIR Set system directory to SYSDIR.
>>> Default: /Users/stephan/git/lyx/lib/
>>> -userdir USERDIR   Set user directory to USERDIR.
>>> Default: /Users/stephan/Library/Application Support/LyX/tex2lyx/LyX/
>> 
>> Ah, now we are getting somewhere. The systemdir is fine, the userdir is 
>> wrong. It should be
>> 
>> /Users/stephan/Library/Application Support/LyX/
> 
> Wrong. For tests we use _own_ userdir "/Testing.lyx"
> We do not want to modify anything outside the build directory.

No. It’s not wrong. You’re right with the use of the _own_ userdir
for tests. But the real life matters too. It’s the wrong userdir
for standard orpeation. And this is Georg message, IMO.
 
> 
>> if you compiled without version suffix and
>> 
>> /Users/stephan/Library/Application Support/LyX2.2/
>> 
>> if you compiled with version suffix.
>> 
>>> With autotools build I get:
>>> $ lyx-build/LyX-2.2.0dev.build/src/tex2lyx/tex2lyx
>>> lyx-build/cmake/2.2.0dev/src/tex2lyx/test/test-modules.tex tex2lyx: User
>>> directory does not exist. …
>>> -sysdir SYSDIR Set system directory to SYSDIR.
>>> Default: /Users/stephan/git/lyx/lib/
>>> -userdir USERDIR   Set user directory to USERDIR.
>>> Default: /Users/stephan/Library/Application
>>> Support/LyX/tex2lyx-2.2/LyX-2.2/
>> 
>> This is wrong as well. This looks as if you compiled with version suffix 
>> "-2.2", so I guess the correct path would be
> 
> Not important to tests.

See above.

Stephan

Re: Test results for 2.2.0dev on Mac

[Kornel Benko]

Am Donnerstag, 21. Januar 2016 um 22:24:58, schrieb Georg Baum 

> Stephan Witt wrote:
> 
> > $ lyx-build/cmake/2.2.0dev/bin/Debug/tex2lyx
> > tex2lyx: Not enough arguments.
> > Usage: tex2lyx [options] infile.tex [outfile.lyx]
> > …
> > -sysdir SYSDIR Set system directory to SYSDIR.
> > Default: /Users/stephan/git/lyx/lib/
> > -userdir USERDIR   Set user directory to USERDIR.
> > Default: /Users/stephan/Library/Application Support/LyX/tex2lyx/LyX/
> 
> Ah, now we are getting somewhere. The systemdir is fine, the userdir is 
> wrong. It should be
> 
> /Users/stephan/Library/Application Support/LyX/

Wrong. For tests we use _own_ userdir "/Testing.lyx"
We do not want to modify anything outside the build directory.

> if you compiled without version suffix and
> 
> /Users/stephan/Library/Application Support/LyX2.2/
> 
> if you compiled with version suffix.
> 
> > With autotools build I get:
> > $ lyx-build/LyX-2.2.0dev.build/src/tex2lyx/tex2lyx
> > lyx-build/cmake/2.2.0dev/src/tex2lyx/test/test-modules.tex tex2lyx: User
> > directory does not exist. …
> > -sysdir SYSDIR Set system directory to SYSDIR.
> > Default: /Users/stephan/git/lyx/lib/
> > -userdir USERDIR   Set user directory to USERDIR.
> > Default: /Users/stephan/Library/Application
> > Support/LyX/tex2lyx-2.2/LyX-2.2/
> 
> This is wrong as well. This looks as if you compiled with version suffix 
> "-2.2", so I guess the correct path would be

Not important to tests.

> /Users/stephan/Library/Application Support/LyX-2.2/
> 
> Does LyX itself tell the correct userdir for both cases? I am now pretty 
> sure that support::Package or some related code is broken on OS X, at least 
> for tex2lyx, which means that this is not only a minor test issue, but a 
> beta blocker IMHO. I'll have a closer look at the weekend, still too much 
> other stuff on my desk.
> 
> > Long answer:
> > 
> > 1) The first hurdle is the wrong linker command for the check binaries on
> > Mac.
> > 
> > $ (cd lyx-build/LyX-2.2.0dev.build;make alltests)
> > PASS: tests/test_convert
> > FAIL: tests/test_filetools
> > PASS: tests/test_lstrings
> > PASS: tests/test_trivstring
> 
> This needs to be fixed but it is not urgent, since these test programs are 
> not needed for the tex2lyx tests.
> 
> 
> Georg

Kornel

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

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 21/01/2016 05:19, Enrico Forestieri a écrit :

On Wed, Jan 20, 2016 at 02:18:40AM +0100, Enrico Forestieri wrote:

On Sun, Jan 17, 2016 at 03:03:20AM +, Guillaume Munch wrote:

Le 16/01/2016 22:26, Enrico Forestieri a écrit :

On Sat, Jan 16, 2016 at 06:29:32PM +, Guillaume Munch wrote:


Le 16/01/2016 17:06, Enrico Forestieri a écrit :

On Fri, Jan 15, 2016 at 07:45:35PM +, Guillaume Munch wrote:


However, this reveals new ways of creating an "after" cursor
position:

* A visually-after cursor position appears with
Ctrl+Shift+Arrows (LFUN_*_SELECT_WORD of something like this).
It remains a right position after deselection, for instance by
doing copy and immediately paste.


I could not reproduce this one.


I can reproduce it systematically.

1. New file 2. Type something in an itemize environment 3. Enter
three times, get a separator 4. Place the cursor at the beginning
of the document 5. Ctrl+Shift+Right until the after position is
reached

optionally:

6. Do copy+paste, to get the same cursor position but with the
selection removed.


This only occurs when the separator is the last character in the
document. In this case you don't need Ctrl+Shift+Right but simply
use → to get there.


I cannot reproduce your description. My recipe works as well if there is
some paragraph after. (Also you can probably deduce from the context
that I would have noticed.)


Sorry, but it seems that I was simply using Shift+Right, even if I was
talking about Ctrl+Shift+Right... Yes, I can reproduce it and it also
happens with Left. I am attaching an updated patch taking also this into
account. I verified that it is still possible to get to that position
when randomly multiple clicking but did not discover a way to
sistematically trigger it. I fear that this may take some time to fix.
However, with this patch it should not be so easy to get after a separator.


Please, find attached an updated patch that moves the check for
separators on mouse clicks to a centralized place (also accounting
for shift-clicks and other modifiers).




Thank you for the patch, I started testing it but I would be more 
comfortable in testing it in the long term. I do not know enough about 
the architecture of mouse events to be personally confident about it.


For this patch and for the one at Wed, Jan 20, 2016 at 02:18, I also 
noticed that it skips the position right before the separator: it jumps 
from the beginning of the last word to the beginning of the first 
paragraph. It would be desirable to stop after the last word


For this patch I noticed that clicking in the right margin after a 
separator jumps to an unexpected location if the separator is in a 
collapsible inset (either at the start or the end of the inset).


Maybe we can go with the improvements you already made for beta, and 
commit this particular patch to master after release.



Guillaume

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 19/01/2016 19:00, Enrico Forestieri a écrit :

On Tue, Jan 19, 2016 at 05:27:47PM -0500, Guillaume Munch wrote:

Le 19/01/2016 16:44, Enrico Forestieri a écrit :

On Mon, Jan 18, 2016 at 10:37:23PM -0500, Guillaume Munch wrote:


Enrico: the width of the line of the plain separator changed, as you can
see, which I guess was not intended.


For the new symbol I used the width of 'n' instead of 'm'. As both kind
share the same base width, I tried to compensate choosing the width of
the plain separator as 8 times the width of 'n', while it previously
was 5 times the width of 'm'. I didn't care to measure the widths as I
deemed it not so important. Note also that this is font dependent.
You are welcome to suggest something different than 8 if you find it
is too large or too narrow with respect to the previous width.



I do not mind so much about the width itself. However what my screenshot
showed is that the line is shorter than the actual width of the spearator.
As you can see the paragraph mark is further on the right, which maybe is
confusing, and I thought was not intended.

If this is really intended, tell me and I will review your patch. Otherwise
I will be waiting for a corrected patch.


Sorry, I misunderstood. I had updated the width in metrics() but forgot to
do it in draw(). Updated patch attached.




Thanks, I tested the patch and it works well. The new method 
GuiPainter::path method seems safe because it is very similar to other 
ones in GuiPainter. The other changes look ok, as for the symbol choice 
Richard seemed positive about it. Please commit it, you have my +1.



Guillaume

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

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 02:47:35PM +0100, Jean-Marc Lasgouttes wrote:
> Le 12/01/2016 03:51, Scott Kostyshak a écrit :

> >It would be nice to know what happens with 1.15. Ubuntu 15.10 has 1.15
> >so I will try to do a fresh install and check it out. Not sure when
> >though.
> 
> I just tried it and it worked without problem. Actually, I suspect that
> there is some timing problem that creates wrong dependencies between files.

I just tried 1.15 with Ubuntu 15.10 and I do get the same error. The
mystery remains.

Scott


signature.asc
Description: PGP signature

Re: Test results for 2.2.0dev on Mac

[Kornel Benko]

Am Freitag, 22. Januar 2016 um 13:34:41, schrieb Stephan Witt 
> >> Ah, now we are getting somewhere. The systemdir is fine, the userdir is 
> >> wrong. It should be
> >> 
> >> /Users/stephan/Library/Application Support/LyX/
> > 
> > Wrong. For tests we use _own_ userdir "/Testing.lyx"
> > We do not want to modify anything outside the build directory.
> 
> No. It’s not wrong. You’re right with the use of the _own_ userdir
> for tests. But the real life matters too. It’s the wrong userdir
> for standard orpeation. And this is Georg message, IMO.

I see. 
Kornel

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

Re: [PATCH] Re: Update boost in 2.1 branch?

[Jean-Marc Lasgouttes]

Le 22/01/2016 16:15, Kornel Benko a écrit :

Am Freitag, 22. Januar 2016 um 11:27:02, schrieb Jean-Marc Lasgouttes 


Le 21/01/2016 22:40, Richard Heck a écrit :

On 01/21/2016 04:07 PM, Pavel Sanda wrote:

I guess it also depends how much space for error we have...
Richard, do you plan to release one intermediate 2.1.x or you just waiting for 
the final one?


How far out do we realistically think 2.2.0 is? I am thinking end of
February, but if it gets delayed any further we might think about an
intermediate release.

Really, I should have done 2.1.5 back at the end of November, but I
thought 2.2 was closer.


One solution would be to have a 2.1.5 together with 2.2beta with an
updated lyx2lyx that reads 2.2beta format. A good occasion to make
people exercise this code.

And then 2.1.6 would just be the usual final version.

JMarc


Even with this patch, I could not compile src/support/ForkedCalls.cpp with 
gcc-4.8.4.


This is in C++11 mode, right? By default (c++98) it should just work 
IMO. I do not think that we have firm plans of making lyx 2.1 compile in 
C++11 mode.


I guess the TR1 support is finally biting us back. We could let the code 
in, but remove the #define LYX_USE_TR1 in conifg.h.


JMarc

Re: [PATCH] Re: Update boost in 2.1 branch?

[Kornel Benko]

Am Freitag, 22. Januar 2016 um 17:01:11, schrieb Jean-Marc Lasgouttes 

> Le 22/01/2016 16:15, Kornel Benko a écrit :
> > Am Freitag, 22. Januar 2016 um 11:27:02, schrieb Jean-Marc Lasgouttes 
> > 
> >> Le 21/01/2016 22:40, Richard Heck a écrit :
> >>> On 01/21/2016 04:07 PM, Pavel Sanda wrote:
>  I guess it also depends how much space for error we have...
>  Richard, do you plan to release one intermediate 2.1.x or you just 
>  waiting for the final one?
> >>>
> >>> How far out do we realistically think 2.2.0 is? I am thinking end of
> >>> February, but if it gets delayed any further we might think about an
> >>> intermediate release.
> >>>
> >>> Really, I should have done 2.1.5 back at the end of November, but I
> >>> thought 2.2 was closer.
> >>
> >> One solution would be to have a 2.1.5 together with 2.2beta with an
> >> updated lyx2lyx that reads 2.2beta format. A good occasion to make
> >> people exercise this code.
> >>
> >> And then 2.1.6 would just be the usual final version.
> >>
> >> JMarc
> >
> > Even with this patch, I could not compile src/support/ForkedCalls.cpp with 
> > gcc-4.8.4.
> 
> This is in C++11 mode, right?

Yes, it is set by checking if the compiler is able to use this mode.

> By default (c++98) it should just work 
> IMO. I do not think that we have firm plans of making lyx 2.1 compile in 
> C++11 mode.

Should we disable it?

> I guess the TR1 support is finally biting us back. We could let the code 
> in, but remove the #define LYX_USE_TR1 in conifg.h.
This setting depends ATM on gnu-cxx version >= 4.4

I tried, and now it compiles.
So what is the preferred solution?
A.) Disable c++11 mode
B.) Not set  LYX_USE_TR1

> JMarc

Kornel


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