Re: lyx-2.3.0alpha1-1 crash
On Sun, Jun 11, 2017 at 09:16:07PM +0200, Guillaume MM wrote: > Le 10/06/2017 à 00:34, Scott Kostyshak a écrit : > > On Thu, Jun 01, 2017 at 01:43:11PM -0400, PhilipPirrip wrote: > > > On 05/28/2017 08:20 AM, Guillaume MM wrote: > > > > Here is a patch, reviews are welcome. > > > > > > Can't say much about the patch, but want to confirm that LyX is not > > > crashing > > > any more. > > > > > > Also pinging others to review the code, I think this is a pretty nasty bug > > > that definitely needs more testing. > > > > +1 can anyone review the patch? > > > > It is now committed at db581113. Good, thanks. Scott
Re: lyx-2.3.0alpha1-1 crash
Le 10/06/2017 à 00:34, Scott Kostyshak a écrit : On Thu, Jun 01, 2017 at 01:43:11PM -0400, PhilipPirrip wrote: On 05/28/2017 08:20 AM, Guillaume MM wrote: Here is a patch, reviews are welcome. Can't say much about the patch, but want to confirm that LyX is not crashing any more. Also pinging others to review the code, I think this is a pretty nasty bug that definitely needs more testing. +1 can anyone review the patch? It is now committed at db581113.
Re: lyx-2.3.0alpha1-1 crash
On Thu, Jun 01, 2017 at 01:43:11PM -0400, PhilipPirrip wrote: > On 05/28/2017 08:20 AM, Guillaume MM wrote: > > Here is a patch, reviews are welcome. > > Can't say much about the patch, but want to confirm that LyX is not crashing > any more. > > Also pinging others to review the code, I think this is a pretty nasty bug > that definitely needs more testing. +1 can anyone review the patch? Scott signature.asc Description: PGP signature
Re: lyx-2.3.0alpha1-1 crash
On 05/28/2017 08:20 AM, Guillaume MM wrote: Here is a patch, reviews are welcome. Can't say much about the patch, but want to confirm that LyX is not crashing any more. Also pinging others to review the code, I think this is a pretty nasty bug that definitely needs more testing.
Re: lyx-2.3.0alpha1-1 crash
Le 26/05/2017 à 23:04, PhilipPirrip a écrit :
I think I caught this one too. I was working on a document with a few
float figures exported from inkscape as pdf, LyX 2.3.0alpha1 crashed
after updating (saving as pdf) one of the figures.
I was running J. Matos' version from
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/
Will try to reproduce.
Here is a patch, reviews are welcome.
Guillaume
>From a3b7ae3c752327768952115b5990de455bd6cc48 Mon Sep 17 00:00:00 2001
From: Guillaume MM
Date: Sun, 28 May 2017 13:25:53 +0200
Subject: [PATCH] Properly track the lifetime of signals2::slots
Starting at 61b2bd5e, boost::bind was progressively replaced with
std::bind. They are not interchangeable though. boost::bind implements
the tracking of boost::signals{,2}::trackable objects. Now that
std::bind has completely replaced boost::bind, tracking never occurred.
This commit replaces boost::signals2::trackable with the new preferred
boost::signals2 methods: scoped_connections or slot::track_foreign. The
support::Trackable class introduced is less safe but easier for transitioning
old code.
Fixes the crash at
https://www.mail-archive.com/lyx-users@lists.lyx.org/msg105230.html and possibly
other crashes.
---
src/Converter.cpp | 22 +
src/LaTeX.h| 5 ++--
src/Server.cpp | 11 +
src/Server.h | 9 ---
src/frontends/qt4/GuiView.cpp | 3 ++-
src/frontends/qt4/GuiWorkArea.cpp | 7 +++---
src/graphics/GraphicsCacheItem.cpp | 25 +---
src/graphics/GraphicsCacheItem.h | 6 ++---
src/graphics/GraphicsConverter.cpp | 26 -
src/graphics/GraphicsConverter.h | 8 ---
src/graphics/GraphicsLoader.cpp| 22 +
src/graphics/GraphicsLoader.h | 10
src/graphics/PreviewImage.cpp | 12 --
src/graphics/PreviewLoader.cpp | 21 ++---
src/graphics/PreviewLoader.h | 9 +++
src/insets/InsetExternal.cpp | 3 +--
src/insets/InsetExternal.h | 4 +---
src/insets/RenderPreview.cpp | 23 ++
src/insets/RenderPreview.h | 17 +++---
src/support/FileMonitor.cpp| 3 +--
src/support/FileMonitor.h | 8 +++
src/support/ForkedCalls.cpp| 19 ---
src/support/ForkedCalls.h | 20 +---
src/support/Makefile.am| 1 +
src/support/Timeout.h | 4 ++--
src/support/signals.h | 48 ++
26 files changed, 194 insertions(+), 152 deletions(-)
create mode 100644 src/support/signals.h
diff --git a/src/Converter.cpp b/src/Converter.cpp
index 104ad0a..6e10b18 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -693,20 +693,6 @@ bool Converters::scanLog(Buffer const & buffer, string const & /*command*/,
}
-namespace {
-
-class ShowMessage
- : public boost::signals2::trackable {
-public:
- ShowMessage(Buffer const & b) : buffer_(b) {}
- void operator()(docstring const & msg) const { buffer_.message(msg); }
-private:
- Buffer const & buffer_;
-};
-
-}
-
-
bool Converters::runLaTeX(Buffer const & buffer, string const & command,
OutputParams const & runparams, ErrorList & errorList)
{
@@ -719,8 +705,12 @@ bool Converters::runLaTeX(Buffer const & buffer, string const & command,
buffer.filePath(), buffer.layoutPos(),
buffer.lastPreviewError());
TeXErrors terr;
- ShowMessage show(buffer);
- latex.message.connect(show);
+ // The connection closes itself at the end of the scope when latex is
+ // destroyed. One cannot close (and destroy) buffer while the converter is
+ // running.
+ latex.message.connect([&buffer](docstring const & msg){
+ buffer.message(msg);
+ });
int const result = latex.run(terr);
if (result & LaTeX::ERRORS)
diff --git a/src/LaTeX.h b/src/LaTeX.h
index f5d66a5..44920c3 100644
--- a/src/LaTeX.h
+++ b/src/LaTeX.h
@@ -18,8 +18,7 @@
#include "support/docstring.h"
#include "support/FileName.h"
-
-#include
+#include "support/signals.h"
#include
#include
@@ -148,7 +147,7 @@ public:
};
/// This signal emits an informative message
- boost::signals2::signal message;
+ signals2::signal message;
/**
diff --git a/src/Server.cpp b/src/Server.cpp
index b89e834..98e1d66 100644
--- a/src/Server.cpp
+++ b/src/Server.cpp
@@ -55,8 +55,7 @@
#include "support/lassert.h"
#include "support/lstrings.h"
#include "support/os.h"
-
-#include "support/bind.h"
+#include "support/signals.h"
#include
@@ -859,8 +858,12 @@ int LyXComm::startPipe(string const & file, bool write)
}
if (!write) {
- theApp()->registerSocketCallback(fd,
- bind(&LyXComm::read_ready, this));
+ // Make sure not to call read_ready after destruction.
+ weak_ptr tracker = tracker_.p();
+ theApp()->registerSocketCallback(fd, [=](){
+if (!tracker.expired())
+ read_ready();
+ });
Re: lyx-2.3.0alpha1-1 crash
Le 27/05/2017 à 00:56, Guillaume MM a écrit :
Thread 1 "lyx" received signal SIGSEGV, Segmentation fault.
0x768612ef in QFileInfo::absoluteFilePath() const ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#0 0x768612ef in QFileInfo::absoluteFilePath() const ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1 0x00d3a681 in lyx::support::FileName::removeFile (
this=this@entry=0x2fd0d68) at ../../../src/support/FileName.cpp:612
#2 0x00cfbcbe in lyx::graphics::Converter::Impl::converted (
this=0x2fd0d10, retval=0) at
../../src/graphics/GraphicsConverter.cpp:205
#3 0x00cfc28f in std::_Mem_fn_base(lyx::graphics::Converter::Impl::*)(int, int), true>::operator()int, void>(lyx::graphics::Converter::Impl*, int&&, int&&) const
(__object=, this=)
at /usr/include/c++/5/functional:600
This is boost::signals2 calling a member function of a destroyed object.
Starting at 61b2bd5e, boost::bind was progressively replaced with
std::bind. They are not interchangeable though. boost::bind implements
the tracking of boost::signals{,2}::trackable objects. Now that
std::bind has completely replaced boost::bind, tracking never occurs.
With the attached patch it does not crash. (Only meant as a demo.)
The issue is sensitive to timing which is why the new FileMonitor
exacerbated the issue and why people who have tried to debug might have
noticed that it is harder to trigger with valgrind. But it is possible
that the issue has already occurred with other forms.
Fixing is easy but I prefer to review the complete code tree for the
problem.
Guillaume
diff --git a/src/support/bind.h b/src/support/bind.h
index 5a734ff..60f1304 100644
--- a/src/support/bind.h
+++ b/src/support/bind.h
@@ -13,13 +13,14 @@
#define LYX_BIND_H
#include "support/functional.h"
+#include "boost/bind.hpp"
namespace lyx
{
- using std::placeholders::_1;
- using std::placeholders::_2;
- using std::bind;
- using std::ref;
+ using boost::placeholders::_1;
+ using boost::placeholders::_2;
+ using boost::bind;
+ using boost::ref;
}
Re: lyx-2.3.0alpha1-1 crash
Le 26/05/2017 à 23:29, Guillaume MM a écrit :
Le 26/05/2017 à 23:15, PhilipPirrip a écrit :
On 05/26/2017 05:04 PM, PhilipPirrip wrote:
I think I caught this one too. I was working on a document with a few
float figures exported from inkscape as pdf, LyX 2.3.0alpha1 crashed
after updating (saving as pdf) one of the figures.
I was running J. Matos' version from
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/
Will try to reproduce.
This is how I crashed LyX now:
I had my 3000 word document open, four figure floats in it: Fig1.pdf
to Fig4.pdf.
"/bin/cp Fig4.pdf Fig3.pdf" was enough to crash it.
Thanks, I'll have a look.
Here is a trace.
Thread 1 "lyx" received signal SIGSEGV, Segmentation fault.
0x768612ef in QFileInfo::absoluteFilePath() const ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#0 0x768612ef in QFileInfo::absoluteFilePath() const ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1 0x00d3a681 in lyx::support::FileName::removeFile (
this=this@entry=0x2fd0d68) at ../../../src/support/FileName.cpp:612
#2 0x00cfbcbe in lyx::graphics::Converter::Impl::converted (
this=0x2fd0d10, retval=0) at
../../src/graphics/GraphicsConverter.cpp:205
#3 0x00cfc28f in std::_Mem_fn_base(lyx::graphics::Converter::Impl::*)(int, int), true>::operator()int, void>(lyx::graphics::Converter::Impl*, int&&, int&&) const
(__object=, this=)
at /usr/include/c++/5/functional:600
#4 std::_Bind(lyx::graphics::Converter::Impl::*)(int, int)>
(lyx::graphics::Converter::Impl*, std::_Placeholder<1>,
std::_Placeholder<2>)>::__call2ul>(std::tuple&&, std::_Index_tuple<0ul, 1ul, 2ul>)
(__args=, this=)
at /usr/include/c++/5/functional:1074
#5 std::_Bind(lyx::graphics::Converter::Impl::*)(int, int)>
(lyx::graphics::Converter::Impl*, std::_Placeholder<1>,
std::_Placeholder<2>)>::operator()(int&&, int&&)
(this=)
at /usr/include/c++/5/functional:1133
#6
boost::detail::function::void_function_obj_invoker2(lyx::graphics::Converter::Impl::*)(int, int)>
(lyx::graphics::Converter::Impl*, std::_Placeholder<1>,
std::_Placeholder<2>)>, void, int,
int>::invoke(boost::detail::function::function_buffer&, int, int)
(function_obj_ptr=...,
a0=, a1=)
at ../../3rdparty/boost/boost/function/function_template.hpp:159
#7 0x00d535ed in boost::function2::operator() (
a1=, a0=, this=)
at ../../../3rdparty/boost/boost/function/function_template.hpp:771
#8
boost::signals2::detail::call_with_tuple_args::m_invoke(int, int)>, 0u, 1u, int&, int&>(boost::function&,
boost::signals2::detail::unsigned_meta_array<0u, 1u>, std::tupleint&> const&, boost::enable_ifint)>::result_type>, void>::type*) const (
args=std::tuple containing = {...}, func=..., this=)
at
../../../3rdparty/boost/boost/signals2/detail/variadic_slot_invoker.hpp:105
[...]
#18 lyx::support::ForkedProcess::emitSignal (this=this@entry=0x2db1bf0)
at ../../../src/support/ForkedCalls.cpp:116
#19 0x00d4f28e in
lyx::support::ForkedCallsController::handleCompletedProcesses () at
../../../src/support/ForkedCalls.cpp:662
#20 0x00a72ba9 in
lyx::frontend::GuiApplication::handleRegularEvents (
this=)
at ../../../../src/frontends/qt4/GuiApplication.cpp:2680
Re: lyx-2.3.0alpha1-1 crash
Le 26/05/2017 à 23:15, PhilipPirrip a écrit : On 05/26/2017 05:04 PM, PhilipPirrip wrote: I think I caught this one too. I was working on a document with a few float figures exported from inkscape as pdf, LyX 2.3.0alpha1 crashed after updating (saving as pdf) one of the figures. I was running J. Matos' version from https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/ Will try to reproduce. This is how I crashed LyX now: I had my 3000 word document open, four figure floats in it: Fig1.pdf to Fig4.pdf. "/bin/cp Fig4.pdf Fig3.pdf" was enough to crash it. Thanks, I'll have a look. Guillaume
Re: lyx-2.3.0alpha1-1 crash
On 05/26/2017 05:04 PM, PhilipPirrip wrote: I think I caught this one too. I was working on a document with a few float figures exported from inkscape as pdf, LyX 2.3.0alpha1 crashed after updating (saving as pdf) one of the figures. I was running J. Matos' version from https://copr.fedorainfracloud.org/coprs/jamatos/lyx-next/ Will try to reproduce. This is how I crashed LyX now: I had my 3000 word document open, four figure floats in it: Fig1.pdf to Fig4.pdf. "/bin/cp Fig4.pdf Fig3.pdf" was enough to crash it. lyx: SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help->Introduction' and send us a bug report, if necessary. Thanks! Bye. Error: LyX crashed! SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please read the bug-reporting instructions in 'Help->Introduction' and send us a bug report, if necessary. Thanks! Bye. ( 1) lyx-devel: lyx-devel(+0x5d5298) [0x55a4cb8fa298] ( 2) lyx-devel: lyx-devel(+0x639f9e) [0x55a4cb95ef9e] ( 3) lyx-devel: lyx-devel(+0x5d4560) [0x55a4cb8f9560] ( 4) lyx-devel: lyx-devel(+0x28b02b) [0x55a4cb5b002b] ( 5) /lib64/libc.so.6: /lib64/libc.so.6(+0x35990) [0x7f12b5379990] ( 6) /lib64/libQt5Core.so.5: QFileInfo::absoluteFilePath() const ( 7) lyx-devel: lyx-devel(+0x81760e) [0x55a4cbb3c60e] ( 8) lyx-devel: lyx-devel(+0x7f0848) [0x55a4cbb15848] ( 9) lyx-devel: lyx-devel(+0x82c5aa) [0x55a4cbb515aa] ( 10) lyx-devel: lyx-devel(+0x8288fa) [0x55a4cbb4d8fa] ( 11) /lib64/libQt5Core.so.5: QMetaObject::activate(QObject*, int, int, void**) ( 12) /lib64/libQt5Core.so.5: QTimer::timerEvent(QTimerEvent*) ( 13) /lib64/libQt5Core.so.5: QObject::event(QEvent*) ( 14) /lib64/libQt5Widgets.so.5: QApplicationPrivate::notify_helper(QObject*, QEvent*) ( 15) /lib64/libQt5Widgets.so.5: QApplication::notify(QObject*, QEvent*) ( 16) lyx-devel: lyx-devel(+0x5e647c) [0x55a4cb90b47c] ( 17) /lib64/libQt5Core.so.5: QCoreApplication::notifyInternal2(QObject*, QEvent*) ( 18) /lib64/libQt5Core.so.5: QTimerInfoList::activateTimers() ( 19) /lib64/libQt5Core.so.5: /lib64/libQt5Core.so.5(+0x294279) [0x7f12b668c279] ( 20) /lib64/libglib-2.0.so.0: /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x162) [0x7f12b7a8be52] ( 21) /lib64/libglib-2.0.so.0: /lib64/libglib-2.0.so.0(+0x4a1d0) [0x7f12b7a8c1d0] ( 22) /lib64/libglib-2.0.so.0: /lib64/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f12b7a8c27c] ( 23) /lib64/libQt5Core.so.5: QEventDispatcherGlib::processEvents(QFlags) ( 24) /lib64/libQt5Core.so.5: QEventLoop::exec(QFlags) ( 25) /lib64/libQt5Core.so.5: QCoreApplication::exec() ( 26) lyx-devel: lyx-devel(+0x293fbd) [0x55a4cb5b8fbd] ( 27) lyx-devel: lyx-devel(+0x124dd6) [0x55a4cb449dd6] ( 28) /lib64/libc.so.6: /lib64/libc.so.6(__libc_start_main+0xf1) [0x7f12b5364401] ( 29) lyx-devel: lyx-devel(+0x12ddca) [0x55a4cb452dca] Aborted (core dumped)
Re: LyX 2.3.0alpha1-1
On Wed, May 03, 2017 at 07:32:13AM +0200, Kornel Benko wrote: > Am Dienstag, 2. Mai 2017 um 19:19:44, schrieb Scott Kostyshak > > > On Tue, May 02, 2017 at 08:24:40AM +0200, Kornel Benko wrote: > > > Am Montag, 1. Mai 2017 um 20:25:44, schrieb Scott Kostyshak > > > > > > > > > Kornel, which commits should I cherry-pick from master to > > > > 2.3.0-alpha1-x? i.e. which commits do I need for Uwe to build from the > > > > tar ball? > > > > > > I committed it now under 0935f94 > > > > OK. And 0f798d6 is needed also right? > > No, it is not needed. Only if one wants to add numbers different to '2.3' > version. > (But it does not harm either) OK > > Anything (in addition to 0935f94 > > and 0f798d6) after db8069c2 that I need to cherry-pick for the Windows > > build? > > Not that I were aware of. Thanks for checking. I cherry-picked 0935f94 to 5c7df3cc. I made the tar balls and sent them to Stephan and Uwe. If everything goes well, we will make the official release of alpha1-1 soon. Scott signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
Am Dienstag, 2. Mai 2017 um 19:19:44, schrieb Scott Kostyshak > On Tue, May 02, 2017 at 08:24:40AM +0200, Kornel Benko wrote: > > Am Montag, 1. Mai 2017 um 20:25:44, schrieb Scott Kostyshak > > > > > > Kornel, which commits should I cherry-pick from master to > > > 2.3.0-alpha1-x? i.e. which commits do I need for Uwe to build from the > > > tar ball? > > > > I committed it now under 0935f94 > > OK. And 0f798d6 is needed also right? No, it is not needed. Only if one wants to add numbers different to '2.3' version. (But it does not harm either) > Anything (in addition to 0935f94 > and 0f798d6) after db8069c2 that I need to cherry-pick for the Windows > build? Not that I were aware of. > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
On Tue, May 02, 2017 at 08:24:40AM +0200, Kornel Benko wrote: > Am Montag, 1. Mai 2017 um 20:25:44, schrieb Scott Kostyshak > > Kornel, which commits should I cherry-pick from master to > > 2.3.0-alpha1-x? i.e. which commits do I need for Uwe to build from the > > tar ball? > > I committed it now under 0935f94 OK. And 0f798d6 is needed also right? Anything (in addition to 0935f94 and 0f798d6) after db8069c2 that I need to cherry-pick for the Windows build? Scott signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
Am Montag, 1. Mai 2017 um 20:25:44, schrieb Scott Kostyshak > On Mon, May 01, 2017 at 09:54:47PM +0200, Uwe Stöhr wrote: > > El 01.05.2017 a las 18:53, Uwe Stöhr escribió: > > > > > Wohoo, I finally found the problem: > > > > Here is the installer: > > > > http://ftp.lyx.de/LyXWinInstaller/LyX2.3alpha1/ > > > > Please check the signature. > > > > The only change I had to make in the tarball files is the attached one. As > > this does not change anything in the LyX functionaltity it is in fact the > > alpha 1. > > Unfortunately I don't think we can do this (I wish we could. It would > certainly make my life easier). We must build the Windows binary > directly from the tar ball. See, for example: > > https://www.mail-archive.com/search?l=mid&q=n9ipuj%24qjn%241%40ger.gmane.org > > I'm sorry for the inconvenience. I really do understand that it feels > like a waste of time. I hope to avoid this situation in the future (by > sending you a private tar ball a week before planned release). > > Kornel, which commits should I cherry-pick from master to > 2.3.0-alpha1-x? i.e. which commits do I need for Uwe to build from the > tar ball? I committed it now under 0935f94 > A big thanks to Uwe and Kornel for figuring out the solution. > > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
On Mon, May 01, 2017 at 09:54:47PM +0200, Uwe Stöhr wrote: > El 01.05.2017 a las 18:53, Uwe Stöhr escribió: > > > Wohoo, I finally found the problem: > > Here is the installer: > > http://ftp.lyx.de/LyXWinInstaller/LyX2.3alpha1/ > > Please check the signature. > > The only change I had to make in the tarball files is the attached one. As > this does not change anything in the LyX functionaltity it is in fact the > alpha 1. Unfortunately I don't think we can do this (I wish we could. It would certainly make my life easier). We must build the Windows binary directly from the tar ball. See, for example: https://www.mail-archive.com/search?l=mid&q=n9ipuj%24qjn%241%40ger.gmane.org I'm sorry for the inconvenience. I really do understand that it feels like a waste of time. I hope to avoid this situation in the future (by sending you a private tar ball a week before planned release). Kornel, which commits should I cherry-pick from master to 2.3.0-alpha1-x? i.e. which commits do I need for Uwe to build from the tar ball? A big thanks to Uwe and Kornel for figuring out the solution. Scott signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
El 01.05.2017 a las 19:33, Kornel Benko escribió:
if (WIN32)
set(suffixing ${LYX_PACKAGE_SUFFIX})
else()
set(suffixing ${LYX_PROGRAM_SUFFIX})
endif()
if(suffixing)
set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
else()
set(PACKAGE ${PACKAGE_BASE})
endif()
This works for me. Please put it in.
thanks and regards
Uwe
Re: LyX 2.3.0alpha1-1
El 01.05.2017 a las 18:53, Uwe Stöhr escribió:
Wohoo, I finally found the problem:
Here is the installer:
http://ftp.lyx.de/LyXWinInstaller/LyX2.3alpha1/
Please check the signature.
The only change I had to make in the tarball files is the attached one.
As this does not change anything in the LyX functionaltity it is in fact
the alpha 1.
regards Uwe
diff --git
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\CMakeLists-24021a4.000.txt"
"b/D:\\LyXGit\\Master\\CMakeLists.txt"
index 77607e3e43..38005ddf6f 100644
---
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\CMakeLists-24021a4.000.txt"
+++ "b/D:\\LyXGit\\Master\\CMakeLists.txt"
@@ -462,7 +462,7 @@ endif()
#relative_system_support_dir()
# in src/support/Package.cpp
#
-if(LYX_PROGRAM_SUFFIX)
+if(LYX_PACKAGE_SUFFIX)
set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
else()
set(PACKAGE ${PACKAGE_BASE})
Re: LyX 2.3.0alpha1-1
Am Montag, 1. Mai 2017 um 18:53:21, schrieb Uwe Stöhr
> El 01.05.2017 a las 17:57, Uwe Stöhr escribió:
>
> Wohoo, I finally found the problem:
> - the file config.h is created by CMake
> - in its line number 33 there is:
>#define PACKAGE "LyX"
> - if I change it manyually to
>#define PACKAGE "LyX2.3"
>
> I get what I need.
>
> the bug is in CmakeLists.txt line 465 ff:
>
> if(LYX_PROGRAM_SUFFIX)
> set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
> else()
> set(PACKAGE ${PACKAGE_BASE})
> endif()
>
> It must be (as it is in the 2.2.x branch)
>
> if(LYX_PACKAGE_SUFFIX)
> set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
> else()
> set(PACKAGE ${PACKAGE_BASE})
> endif()
>
> regards Uwe
Ah. Yes, my bad. Did not consider that LYX_PROGRAM_SUFFIX is not set on windows.
The idea was that _only_ the versioned program (e.g. "lyx2.3") should use
"~/.lyx2.3" as default user directory.
So, maybe the following would work
if (WIN32)
set(suffixing ${LYX_PACKAGE_SUFFIX})
else()
set(suffixing ${LYX_PROGRAM_SUFFIX})
endif()
if(suffixing)
set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
else()
set(PACKAGE ${PACKAGE_BASE})
endif()
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
El 01.05.2017 a las 17:57, Uwe Stöhr escribió:
Wohoo, I finally found the problem:
- the file config.h is created by CMake
- in its line number 33 there is:
#define PACKAGE "LyX"
- if I change it manyually to
#define PACKAGE "LyX2.3"
I get what I need.
the bug is in CmakeLists.txt line 465 ff:
if(LYX_PROGRAM_SUFFIX)
set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
else()
set(PACKAGE ${PACKAGE_BASE})
endif()
It must be (as it is in the 2.2.x branch)
if(LYX_PACKAGE_SUFFIX)
set(PACKAGE ${PACKAGE_BASE}${LYX_INSTALL_SUFFIX})
else()
set(PACKAGE ${PACKAGE_BASE})
endif()
regards Uwe
Re: LyX 2.3.0alpha1-1
Am Montag, 1. Mai 2017 um 17:48:55, schrieb Uwe Stöhr > El 01.05.2017 a las 12:52, Kornel Benko escribió: > > > It is available here. > > Not here: I took latest master, deleted the CMake cache and set up > everything from scratch. As you can see in the attached screenshot there > is no LYX_PROGRAM_SUFFIX available in the GUI. Ah, yes. The program suffix is only valid for gcc-related compilations. (E.g. not microsoft) (See CMakeLists.txt:146) > Moreover, as you can see in the screenshot, I get now many warnings > since your latest commit > http://www.lyx.org/trac/changeset/d74c43e7a307d381e71251d5e376f8629e5aa3d9/lyxgit > > I use CMake 3.8.0. > > Could you please have a look? Ignore please for now. > thanks and regards > Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
Am Montag, 1. Mai 2017 um 17:57:05, schrieb Uwe Stöhr > El 01.05.2017 a las 17:48, Uwe Stöhr escribió: > > > Moreover, as you can see in the screenshot, I get now many warnings > > since your latest commit > > http://www.lyx.org/trac/changeset/d74c43e7a307d381e71251d5e376f8629e5aa3d9/lyxgit > > > > Ah, it seems that i can ignore them, right? Yes. > Another issue: I can now specify LYX_SUFFIX_VALUE as "2.3" but after > reconfiguring CMake this is changed to ".2.3" (note the dot). is this > correct? Yes. > thanks and regards > Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
El 01.05.2017 a las 17:48, Uwe Stöhr escribió: Moreover, as you can see in the screenshot, I get now many warnings since your latest commit http://www.lyx.org/trac/changeset/d74c43e7a307d381e71251d5e376f8629e5aa3d9/lyxgit Ah, it seems that i can ignore them, right? Another issue: I can now specify LYX_SUFFIX_VALUE as "2.3" but after reconfiguring CMake this is changed to ".2.3" (note the dot). is this correct? thanks and regards Uwe
Re: LyX 2.3.0alpha1-1
Am Montag, 1. Mai 2017 um 12:39:30, schrieb Uwe Stöhr > El 01.05.2017 a las 07:08, Kornel Benko escribió: > > >> But I don't, or the version suffix for the appdata folder is set at > >> another place, but where? > > > > Have you set > > -DLYX_PROGRAM_SUFFIX=ON > > No because this setting is not available in the CMake GUI. It is available here. > I set it now via the build script but the problem remains. Please check on CMakeCache.txt #egrep _SUFFIX CMakeCache.txt LYX_PACKAGE_SUFFIX:BOOL=ON LYX_PROGRAM_SUFFIX:BOOL=ON LYX_SUFFIX_VALUE:STRING= (PACKAGE is not important) > regards Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
El 01.05.2017 a las 07:08, Kornel Benko escribió: But I don't, or the version suffix for the appdata folder is set at another place, but where? Have you set -DLYX_PROGRAM_SUFFIX=ON No because this setting is not available in the CMake GUI. I set it now via the build script but the problem remains. regards Uwe
Re: LyX 2.3.0alpha1-1
Am Montag, 1. Mai 2017 um 00:17:37, schrieb Uwe Stöhr > El 30.04.2017 a las 16:11, Kornel Benko escribió: > > >> I thing we should use > >> Qt5 as default for LyX 2.3. One can still override it with Qt 4 if one > >> likes. > > > > The same reasoning applies to to QT5. > > No, because Qt 4 support is running out. I therefore it makes sense to > switch to a system for which we get bug and security issue fixes. And > this is Qt 5. > > >> Do I need to specify the version suffix in CMake? If so where and where > >> is this set in LyX 2.2.x? > > > > -DLYX_PROGRAM_SUFFIX=ON# enable use of suffix > > -DLYX_SUFFIX_VALUE=xy # defaults to 2.3 if not set, > > But I don't get is apparently. The suffix value is empty. > > > Ah, yes, my mistake. Still, using the default (e.g."") you shoud get "2.3" > > But I don't, or the version suffix for the appdata folder is set at > another place, but where? Have you set -DLYX_PROGRAM_SUFFIX=ON ? See CMakeLists.txt:345 > regards Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
On Mon, May 01, 2017 at 12:22:08AM +0200, Uwe Stöhr wrote: > El 30.04.2017 a las 18:54, Scott Kostyshak escribió: > > > I think it is still reasonable to use Qt 4 by default. Many > > distributions still have old Qt 5 libraries, and we recommend only 5.6. > > Well, a few weeks ago you even wanted to use the latest Qt 5 version. I > argued to use the current long-term support version of Qt 5 which is 5.6. The above is true. I'm glad we decided as a group to go with 5.6. > want to switch the default to Qt 5 because the support for Qt 4 will most > probably run out during the life cycle of LyX 2.3. Good argument. I'll start a discussion on lyx-devel. Scott signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
El 30.04.2017 a las 18:54, Scott Kostyshak escribió: I think it is still reasonable to use Qt 4 by default. Many distributions still have old Qt 5 libraries, and we recommend only 5.6. Well, a few weeks ago you even wanted to use the latest Qt 5 version. I argued to use the current long-term support version of Qt 5 which is 5.6. I want to switch the default to Qt 5 because the support for Qt 4 will most probably run out during the life cycle of LyX 2.3. regards Uwe
Re: LyX 2.3.0alpha1-1
El 30.04.2017 a las 16:11, Kornel Benko escribió: I thing we should use Qt5 as default for LyX 2.3. One can still override it with Qt 4 if one likes. The same reasoning applies to to QT5. No, because Qt 4 support is running out. I therefore it makes sense to switch to a system for which we get bug and security issue fixes. And this is Qt 5. Do I need to specify the version suffix in CMake? If so where and where is this set in LyX 2.2.x? -DLYX_PROGRAM_SUFFIX=ON# enable use of suffix -DLYX_SUFFIX_VALUE=xy # defaults to 2.3 if not set, But I don't get is apparently. The suffix value is empty. Ah, yes, my mistake. Still, using the default (e.g."") you shoud get "2.3" But I don't, or the version suffix for the appdata folder is set at another place, but where? regards Uwe
Re: LyX 2.3.0alpha1-1
On Sun, Apr 30, 2017 at 05:27:20PM +0200, Kornel Benko wrote: > Am Sonntag, 30. April 2017 um 10:56:32, schrieb Scott Kostyshak > > > On Sun, Apr 30, 2017 at 04:11:31PM +0200, Kornel Benko wrote: > > > > > > Attached is a patch for CMake. Does it make sense? > > > > > > Sure. > > > > I suggest either of you commit any patch that you both agree on to > > master. Then let me know which commits I should cherry-pick from the > > 2.3.0-alpha1-x branch. > > To be clear, until we make QT5 default on automake too, I do not agree. Agreed. So in this case our Windows build script needs to specify the use of Qt 5 in the CMake command. I think it is still reasonable to use Qt 4 by default. Many distributions still have old Qt 5 libraries, and we recommend only 5.6. Uwe is that OK? If you disagree, please start a new thread on lyx-devel so we can discuss as a group. Scott signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
Am Sonntag, 30. April 2017 um 10:56:32, schrieb Scott Kostyshak > On Sun, Apr 30, 2017 at 04:11:31PM +0200, Kornel Benko wrote: > > > > Attached is a patch for CMake. Does it make sense? > > > > Sure. > > I suggest either of you commit any patch that you both agree on to > master. Then let me know which commits I should cherry-pick from the > 2.3.0-alpha1-x branch. To be clear, until we make QT5 default on automake too, I do not agree. > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
On Sun, Apr 30, 2017 at 04:11:31PM +0200, Kornel Benko wrote: > > Attached is a patch for CMake. Does it make sense? > > Sure. I suggest either of you commit any patch that you both agree on to master. Then let me know which commits I should cherry-pick from the 2.3.0-alpha1-x branch. Scott signature.asc Description: PGP signature
Re: LyX 2.3.0alpha1-1
Am Sonntag, 30. April 2017 um 15:38:30, schrieb Uwe Stöhr > El 30.04.2017 a las 10:24, Kornel Benko escribió: > > > Am Sonntag, 30. April 2017 um 09:37:37, schrieb Kornel Benko > > > >>> I found now the problem: configuring CMake the fist time will set > >>> PYTHON_EXECUTABLE and LYX_PYTHON_EXECUTABLE to the python library found > >>> in the specified GNUWIN32_DIR: > >>> D:/LyXGit/Master/lyx-windows-deps-msvc2015/Python/python.exe > >>> > > > > So you have there a python executable? > > Yes, this is the Python delivered with the installer. > > However, I found now out that Python is not to blame here. I cannot > explain why but deleting the build folder again and starting from > scratch (one again) solved the problem. > So it seems to be quite random because it suddenly appears also when > compiling master or the 2.2.x branch also if I don't call the CMake GUI. > > Attached is a patch for CMake. Does it make sense? Sure. > I thing we should use > Qt5 as default for LyX 2.3. One can still override it with Qt 4 if one > likes. The same reasoning applies to to QT5. > I am a step further but not yet ready because there is one issue: > The installed LyX creates its appdata folder without a version suffix. > For LyX 2.2.x the appdata folder is > C:\Users\\AppData\Roaming\LyX2.2 > For LyX 2.1.x the appdata folder is > C:\Users\\AppData\Roaming\LyX2.1 > etc. > But for LyX 2.3.x it is currently only > C:\Users\\AppData\Roaming\LyX > > Do I need to specify the version suffix in CMake? If so where and where > is this set in LyX 2.2.x? -DLYX_PROGRAM_SUFFIX=ON# enable use of suffix -DLYX_SUFFIX_VALUE=xy # defaults to 2.3 if not set, > If I specify "2.3" for LYX-SUFFIX-VALUE I get this error: > CMake Error at development/cmake/modules/LyXMacros.cmake:270 (message): >Invalid string for lyx suffix (.2.3) > Call Stack (most recent call first): >CMakeLists.txt:133 (LYX_STRING) > Ah, yes, my mistake. Still, using the default (e.g."") you shoud get "2.3" > thanks and regards > Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
El 30.04.2017 a las 10:24, Kornel Benko escribió: Am Sonntag, 30. April 2017 um 09:37:37, schrieb Kornel Benko I found now the problem: configuring CMake the fist time will set PYTHON_EXECUTABLE and LYX_PYTHON_EXECUTABLE to the python library found in the specified GNUWIN32_DIR: D:/LyXGit/Master/lyx-windows-deps-msvc2015/Python/python.exe So you have there a python executable? Yes, this is the Python delivered with the installer. However, I found now out that Python is not to blame here. I cannot explain why but deleting the build folder again and starting from scratch (one again) solved the problem. So it seems to be quite random because it suddenly appears also when compiling master or the 2.2.x branch also if I don't call the CMake GUI. Attached is a patch for CMake. Does it make sense? I thing we should use Qt5 as default for LyX 2.3. One can still override it with Qt 4 if one likes. I am a step further but not yet ready because there is one issue: The installed LyX creates its appdata folder without a version suffix. For LyX 2.2.x the appdata folder is C:\Users\\AppData\Roaming\LyX2.2 For LyX 2.1.x the appdata folder is C:\Users\\AppData\Roaming\LyX2.1 etc. But for LyX 2.3.x it is currently only C:\Users\\AppData\Roaming\LyX Do I need to specify the version suffix in CMake? If so where and where is this set in LyX 2.2.x? If I specify "2.3" for LYX-SUFFIX-VALUE I get this error: CMake Error at development/cmake/modules/LyXMacros.cmake:270 (message): Invalid string for lyx suffix (.2.3) Call Stack (most recent call first): CMakeLists.txt:133 (LYX_STRING) thanks and regards Uwe diff --git "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\CMakeLists-4a42a71.000.txt" "b/D:\\LyXGit\\Master\\CMakeLists.txt" index da0776eb2f..07195938d0 100644 --- "a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\CMakeLists-4a42a71.000.txt" +++ "b/D:\\LyXGit\\Master\\CMakeLists.txt" @@ -2,7 +2,7 @@ # Licence details can be found in the file COPYING. # # Copyright (c) 2006-2011 Peter Kümmel, -# Copyright (c) 2008-2011 Kornel Benko, +# Copyright (c) 2008-2017 Kornel Benko, cmake_minimum_required(VERSION 2.6.4) @@ -141,7 +141,7 @@ LYX_OPTION(ENABLE_URLTESTS "Enable for URL tests" OFF ALL) LYX_OPTION(ENABLE_EXPORT_TESTS "Enable for export tests" OFF ALL) LYX_OPTION(ENABLE_KEYTESTS "Enable for keytests" OFF ALL) LYX_OPTION(ASAN "Use address sanitizer" OFF ALL) -LYX_COMBO(USE_QT"Use Qt version as frontend" QT4 QT5) +LYX_COMBO(USE_QT"Use Qt version as frontend" QT5 QT4) #LYX_OPTION(3RDPARTY_BUILD "Build 3rdparty libs" OFF ALL) LYX_OPTION(EXTERNAL_Z "OFF := Build 3rdparty lib zlib" ON ALL) LYX_OPTION(EXTERNAL_ICONV "OFF := Build 3rdparty lib iconvlib" ON ALL) @@ -996,7 +996,7 @@ if(LYX_ASAN) message(STATUS "Address sanitizer enabled. Usage:") message(STATUS "wget https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py";) message(STATUS "chmod +x ./asan_symbolize.py") -message(STATUS "./bin/lyx2.2 2>&1 | ./asan_symbolize.py | c++filt ") +message(STATUS "./bin/lyx2.3 2>&1 | ./asan_symbolize.py | c++filt ") message(STATUS) endif()
Re: LyX 2.3.0alpha1-1
Am Sonntag, 30. April 2017 um 09:37:37, schrieb Kornel Benko > > I found now the problem: configuring CMake the fist time will set > > PYTHON_EXECUTABLE and LYX_PYTHON_EXECUTABLE to the python library found > > in the specified GNUWIN32_DIR: > > D:/LyXGit/Master/lyx-windows-deps-msvc2015/Python/python.exe > > So you have there a python executable? > > Kornel, is there anything that could be done here? I mean if CMake > > cannot find the python.exe that is installed, then LYX_PYTHON_EXECUTABLE > > should be kept empty so that one get an error during the configuration > > of CMake and then knows that one has to specify the path to the python > > executable. How should cmake decide that this executable is wrong? Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
Am Sonntag, 30. April 2017 um 04:23:07, schrieb Uwe Stöhr
> El 30.04.2017 a las 03:48, Uwe Stöhr escribió:
>
> > Fixing this in the Cmake Gui leads me to this error which I cannot
> > overcome:
> >
> > C:\Program Files
> > (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(133,5):
> > error
> > MSB3073: Der Befehl "setlocal\r
>
> I found now the problem: configuring CMake the fist time will set
> PYTHON_EXECUTABLE and LYX_PYTHON_EXECUTABLE to the python library found
> in the specified GNUWIN32_DIR:
> D:/LyXGit/Master/lyx-windows-deps-msvc2015/Python/python.exe
>
> But one needs the path to the Python installation, so in my case setting
> LYX_PYTHON_EXECUTABLE to C:/Python27/python.exe fixed the problem.
>
> Kornel, is there anything that could be done here? I mean if CMake
> cannot find the python.exe that is installed, then LYX_PYTHON_EXECUTABLE
> should be kept empty so that one get an error during the configuration
> of CMake and then knows that one has to specify the path to the python
> executable.
You could try with setting the path at CMakeLists.txt:729
list(APPEND CMAKE_PROGRAM_PATH "C:/Python27" "${GNUWIN32_DIR}/Python" )
The original line is from commit 03e7e5cfb
Peter Kümmel: improve configuration with cmake-gui
> thanks and regards
> Uwe
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: LyX 2.3.0alpha1-1
El 30.04.2017 a las 03:48, Uwe Stöhr escribió: Fixing this in the Cmake Gui leads me to this error which I cannot overcome: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(133,5): error MSB3073: Der Befehl "setlocal\r I found now the problem: configuring CMake the fist time will set PYTHON_EXECUTABLE and LYX_PYTHON_EXECUTABLE to the python library found in the specified GNUWIN32_DIR: D:/LyXGit/Master/lyx-windows-deps-msvc2015/Python/python.exe But one needs the path to the Python installation, so in my case setting LYX_PYTHON_EXECUTABLE to C:/Python27/python.exe fixed the problem. Kornel, is there anything that could be done here? I mean if CMake cannot find the python.exe that is installed, then LYX_PYTHON_EXECUTABLE should be kept empty so that one get an error during the configuration of CMake and then knows that one has to specify the path to the python executable. thanks and regards Uwe
