Re: #10658: LyX cannot be compiled any longer with CMake to show a console

[Kornel Benko]

Am Freitag, 12. Mai 2017 um 00:13:22, schrieb Uwe Stöhr 
> El 12.05.2017 a las 00:00, Uwe Stöhr escribió:
> 
> >> OK. I suppose, that it may be equivalent to linux.
> >> I have to set the environment PATH, so that qmake.exe from my QT is 
> >> found.
>  > > I cannot set the PATH because this would require admin privileges.
> 
> That is correct but I can set the PATH locally and already do so in the 
> current script in master:
> 
> set PATH=%QT_PATH%;%PATH%
> 
> So the path to the qmake.exe is known. nevertheless CMake wants the path 
> in the variable CMAKE_PREFIX_PATH but I cannot set this because of the 
> problem I described.
> 
> regards Uwe

Sorry, I do not understand what is not working on Windows. Maybe Peter could 
help.

Kornel

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

Re: #10658: LyX cannot be compiled any longer with CMake to show a console

[Uwe Stöhr]

El 12.05.2017 a las 00:00, Uwe Stöhr escribió:


OK. I suppose, that it may be equivalent to linux.
I have to set the environment PATH, so that qmake.exe from my QT is 
found.

> > I cannot set the PATH because this would require admin privileges.

That is correct but I can set the PATH locally and already do so in the 
current script in master:


set PATH=%QT_PATH%;%PATH%

So the path to the qmake.exe is known. nevertheless CMake wants the path 
in the variable CMAKE_PREFIX_PATH but I cannot set this because of the 
problem I described.


regards Uwe

Re: #10658: LyX cannot be compiled any longer with CMake to show a console

[Uwe Stöhr]

El 11.05.2017 a las 01:46, Kornel Benko escribió:


OK. I suppose, that it may be equivalent to linux.
I have to set the environment PATH, so that qmake.exe from my QT is found.


I cannot set the PATH because this would require admin privileges. But 
as I wrote this is not necessary, all I need is that


cmake %LYX_SOURCE% -DCMAKE_PREFIX_PATH="test"

leads to

//Used Qt version
CMAKE_PREFIX_PATH:PATH=test

in CMakeCache.txt. When I this path is the correct one, Qt is found and 
I am happy.



Have you also had the time to look for the console issue?


This variable (LYX_CONSOLE) is only valid with MSVC. So anything I do would be 
forcing you to test.


I don't understand. What should I test? As I reported as bug CMake tells 
that one should use the setting FORCE but this is incorrect. The correct 
setting is ON. I asked you if you could kindly correct this.

For further testing I need the above problem to be solved.


And you may have no time, at least it feels like that, considering how fast I 
get responses.


Ehm, yes I have not much time but try to reply as soon as possible.

thanks and regards
Uwe

How to require "textquotedbl" in Paragraph::Private::latexSpecialChar

[Guenter Milde]

Dear LyX developers,

in order to fix #10584, I need to call the function

  features.require("textquotedbl")

(to insert a some fallback definition in the preamble)  
in Paragraph::Private::latexSpecialChar.

A similar action is done in InsetQuotes.cpp in

   void InsetQuotes::validate(LaTeXFeatures & features) const
   
however, "LaTeXFeatures & features" is not defined in Paragraph.cpp.


A "stub patch" (comment at the place of required change) is provided at
http://www.lyx.org/trac/raw-attachment/ticket/10584/Paragraph.patch

Thanks,
Günter

Re: [LyX/master] make python string compliant with python 2 and 3

[José Abílio Matos]

On Thursday, 11 May 2017 15.06.42 WEST Jean-Marc Lasgouttes wrote:
> I still get:
> 
>   File
> "/home/local/lasgoutt/lyx/master/lib/scripts/lyxpreview2bitmap.py", line 166
> def_re =
> re.compile(rb"(newcommandx|globallongdef)([a-zA-Z]+)")
> 
>   ^
> SyntaxError: invalid syntax
> 
> JMarc

Oops, my mistake it should be re.compile(b" since I doubled the 
backslashes.

I see that Günter already fixed the code.

I have a new patch for other functions and as far as I can see that problem is 
not present there...

Thank you,
-- 
José Abílio

Re: [LyX/master] make python string compliant with python 2 and 3

[Jean-Marc Lasgouttes]

Le 09/05/2017 à 17:57, José Matos a écrit :

commit 6495cd135f15c3775613c79b008ad62f6726573e
Author: José Matos 
Date:   Tue May 9 16:53:32 2017 +0100

make python string compliant with python 2 and 3


I still get:

 File 
"/home/local/lasgoutt/lyx/master/lib/scripts/lyxpreview2bitmap.py", line 166
def_re = 
re.compile(rb"(newcommandx|globallongdef)([a-zA-Z]+)")


 ^
SyntaxError: invalid syntax

JMarc

Re: Migration of preferences

[Jürgen Spitzmüller]

2017-05-11 12:51 GMT+02:00 José Abílio Matos :

> I will look into this problem if we have a bug report for it and a simple
> example file.
>

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

Jürgen


> --
> José Abílio
>

Re: Fwd: 2.3.0alpha1-1

[Kornel Benko]

Am Donnerstag, 11. Mai 2017 um 11:59:28, schrieb José Abílio Matos 

> On Tuesday, 9 May 2017 12.20.13 WEST Scott Kostyshak wrote:
> > On Tue, May 09, 2017 at 10:10:12AM +0100, José Abílio Matos wrote:
> > > In order to test the python3 support I created the fedora packages that
> > > force the usage of python 3.
> > > Attached follows the patch that I have used to force the python 3. This is
> > > a brute force approach but the main idea is that there are two places
> > > where we
> > > need to make the changes to support a custom python version:
> > Thanks for looking into this, José. I will test also with your patch
> > when I have time. If you update your patch, please post the newer
> > version.
> > 
> > Scott
> 
> I would like to have a permanent solution for this.
> 
> What do others think regarding the python binary used?
>   a) Should it be passed through an environment variable, like $PYTHON (that 
> is now is only used at build and install times, but not a run time)?

I'd prefer configurable python, that is allow use of $PYTHON at runtime too.
(Test purposes)

>   b) Should we use a variable/path exposed through the preferences that sets 
> the value of $$python and such that an empty value means use the system 
> default (as we have now)?

Additional to a), but which overrides which?

> The changes are trivial for configure.py:
>   a) we replace the calls to python by the binary that runs configure.py;
> 
>   b) we replace python by $$python.
> 
> The changes to src/support/os.cpp are more work but not by much IMHO.
> 
> Regards,

or c)Add a parameter to lyx (e.g. -python=), this would override a) 
and b)

Kornel

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

Re: 2.3.0alpha1-1

[Stephan Witt]

Am 11.05.2017 um 12:59 schrieb José Abílio Matos :
> 
> On Tuesday, 9 May 2017 12.20.13 WEST Scott Kostyshak wrote:
>> On Tue, May 09, 2017 at 10:10:12AM +0100, José Abílio Matos wrote:
>>> In order to test the python3 support I created the fedora packages that
>>> force the usage of python 3.
>>> Attached follows the patch that I have used to force the python 3. This is
>>> a brute force approach but the main idea is that there are two places
>>> where we
>>> need to make the changes to support a custom python version:
>> Thanks for looking into this, José. I will test also with your patch
>> when I have time. If you update your patch, please post the newer
>> version.
>> 
>> Scott
> 
> I would like to have a permanent solution for this.
> 
> What do others think regarding the python binary used?
>  a) Should it be passed through an environment variable, like $PYTHON (that 
> is now is only used at build and install times, but not a run time)?
> 
>  b) Should we use a variable/path exposed through the preferences that sets 
> the value of $$python and such that an empty value means use the system 
> default (as we have now)?
> 
> The changes are trivial for configure.py:
>  a) we replace the calls to python by the binary that runs configure.py;
> 
>  b) we replace python by $$python.
> 
> The changes to src/support/os.cpp are more work but not by much IMHO.

The use of environment variables is difficult with modern desktops on Mac
(and on Windows too - for the average user). I think the evolution to
sandbox based environments is the motivation for these changes.

So, if possible I vote for b) if any.

In my opinion this wouldn’t help a user who has a broken python installation
but this is not LyX’s problem then.

Stephan

Re: 2.3.0alpha1-1

[José Abílio Matos]

On Tuesday, 9 May 2017 17.33.24 WEST Richard Heck wrote:
> It feels (and it just is a feeling) as if there's some kind of conflict
> that happens when we call
> the system python. Maybe because of something in the path? Could that
> lead python itself to
> look for packages in the wrong place? leading to some kind of conflict?
> 
> Richard

The other possibility would for lyx to be using another python that it finds 
in the path before the system one.

The paths were python searches the modules are in sys.path.

The following gives the whole list:

$ python -c 'import sys; print("\n".join(sys.path))'

Usually the first line is empty and it means the current directory...

FWIW I get:
$ python -c 'import sys; print("\n".join(sys.path))'

/usr/lib/python27.zip
/usr/lib64/python2.7
/usr/lib64/python2.7/plat-linux2
/usr/lib64/python2.7/lib-tk
/usr/lib64/python2.7/lib-old
/usr/lib64/python2.7/lib-dynload
/usr/lib64/python2.7/site-packages
/usr/lib64/python2.7/site-packages/gtk-2.0
/usr/lib/python2.7/site-packages

and

$ python3 -c 'import sys; print("\n".join(sys.path))'

/usr/lib64/python36.zip
/usr/lib64/python3.6
/usr/lib64/python3.6/lib-dynload
/usr/lib64/python3.6/site-packages
/usr/lib/python3.6/site-packages

-- 
José Abílio

Re: Fwd: 2.3.0alpha1-1

[José Abílio Matos]

On Tuesday, 9 May 2017 12.20.13 WEST Scott Kostyshak wrote:
> On Tue, May 09, 2017 at 10:10:12AM +0100, José Abílio Matos wrote:
> > In order to test the python3 support I created the fedora packages that
> > force the usage of python 3.
> > Attached follows the patch that I have used to force the python 3. This is
> > a brute force approach but the main idea is that there are two places
> > where we
> > need to make the changes to support a custom python version:
> Thanks for looking into this, José. I will test also with your patch
> when I have time. If you update your patch, please post the newer
> version.
> 
> Scott

I would like to have a permanent solution for this.

What do others think regarding the python binary used?
  a) Should it be passed through an environment variable, like $PYTHON (that 
is now is only used at build and install times, but not a run time)?

  b) Should we use a variable/path exposed through the preferences that sets 
the value of $$python and such that an empty value means use the system 
default (as we have now)?

The changes are trivial for configure.py:
  a) we replace the calls to python by the binary that runs configure.py;

  b) we replace python by $$python.

The changes to src/support/os.cpp are more work but not by much IMHO.

Regards,
-- 
José Abílio

Re: Migration of preferences

[José Abílio Matos]

On Tuesday, 9 May 2017 12.08.31 WEST Jürgen Spitzmüller wrote:
> We (José and Enrico) fixed a similar problem with encodings in layouts in
> lyx2lyx, so I suppose prefs2prefs can be fixed as well.
> 
> Jürgen

I agree with your point of view. :-)

OTOH the difference between lyx2lyx and prefs2prefs is that at some point we 
take care of the file encoding while I am not sure that we do it in 
prefs2prefs.

I will look into this problem if we have a bug report for it and a simple 
example file.
-- 
José Abílio

Re: 2.3.0alpha1-1: file save

[Stephan Witt]

Am 11.05.2017 um 07:46 schrieb Stephan Witt :
> 
> Am 11.05.2017 um 00:40 schrieb Guillaume MM :
>> 
>> Le 10/05/2017 à 22:57, Stephan Witt a écrit :
>>> Am 09.05.2017 um 21:19 schrieb john kennan :
 
 Start a new file
 type something
 save
 type some more
 save
 
 I get "the file ... changed on disk." with two buttons: "Reload" and 
 "Ignore"
 
 hitting Ignore leaves the file unsaved
 hitting Reload works -- I get a warning:
 
 Any changes will be lost. Are you sure you want to load the version on 
 disk of the document .../Papers/LyX/test1.lyx?
 
 with buttons for Revert and Cancel
 Hitting Revert saves the file, as desired, and the changes are not lost.
>> 
>> Dear John, thanks for the report.
> 
> +1 - thank you for testing!
> 
>> This looks like LyX incorrectly
>> recording the modification it has made itself as an external
>> modification. This means that in fact the file is already correctly
>> saved when the message shows up, and the two buttons do nothing except
>> annoy. I am looking into it.
>> 
>> Does it happen only on the second save? Does it happen on the third save
>> if you carry on? Does it not happen on the first save? If not, is it
>> because the first save is a "Save As"?
>> 
>>> 
>>> Confirmed.
>> 
>> Dear Stephan, thanks for the test. This looks specific to OSX. I would
>> ask the same questions as above.
> 
> On the first save LyX asks for a file name because it’s a new file.
> This in fact is a Save-As operation. The save succeeds normal.
> After that every change+save is accompanied by the message popup.
> NB: I’m accepting the file name proposal - so it’s the same file name
> before and after the save-as.
> 
>>> Guillaume, it’s the FileMonitor which is detecting the file save as 
>>> external modification.
>>> How can I provide further info to correct this annoying behavior?
>>> My attempt to diagnose the culprit failed - the code is too weird for me :(
>>> 
>>> I tried to stop in Buffer::Impl::refreshFileMonitor() at the first line.
>>> The debugger didn’t stop - but it stopped in 
>>> Buffer::Impl::fileExternallyModified()
>>> and the call stack claims it comes from the last line in 
>>> refreshFileMonitor() ???
>> 
>> As QFileSystemWatcher is intrinsically asynchronous, gdb does not really
>> help with debugging here. What you see on the trace is
>> QFileSystemWatcher calling the function that was passed to connect at
>> the end of refreshFileMonitor (via a qt signal that is converted into a
>> boost signal).
> 
> That makes sense. BTW, what’s the semantic of a void C++ function when
> it returns a value (2nd line after the if())? I’m surprised it’s allowed.
> 
> Now I have to go… I’ll answer the other questions later.
> 
> Stephan
> 
>> What should happen is inside Buffer::save there is a FileMonitorBlocker
>> that should block the signal. Now, since QFileSystemWatcher is
>> asynchronous, the signal is not received before the next iteration of
>> the even loop. At this point the FileMonitorBlocker has been destroyed a
>> long time ago. This is why FileMonitorBlocker unblocks the signal in an
>> asynchronous way too, using a QTimer. On Linux, a delay of 0 (meaning
>> wait until the next event loop) is enough to actually block the signal.
>> 
>> The delay is defined in Buffer::Impl::blockFileMonitor (Buffer.cpp:388)
>> currently at 10ms. Can you try to increase this value and see if that
>> helps? It will likely help, but this is not a nice solution.

I tried it with a delay of 100ms. The effect is now LyX presents the external
modification message box every 2nd or 3rd save. So it is not the solution.

>> Ideally I would like to have everything work with a delay of 0ms, to be
>> sure that everyone experiences the same. Can you help me and see if it
>> is possible to flush the file operations in FileName::copyTo and
>> FileName::moveTo and if it makes a difference ? There is QFile::flush
>> but I do not really see how to use it in this context and I cannot test
>> the situation.

I cannot see how to do it here.

The save operation in this scenario is done with one create (temp), one
rename (backup) and another rename (final name).

Are you sure the file monitor is able to follow these steps?

>> 
>>> 
>>> Frankly said: I’m lost now.
>> 
>> For this bug and the other similar bug on the bugtracker [down currently
>> again] I thought about detecting false positives by comparing the file
>> hashes before setting the flag.

Perhaps the monitor should be informed/synchronized by/with the save process?

Stephan
>> 
>> Before this drastic measure I would like to see if I can understand why
>> the signal comes too late for the blocker, and if it's just missing
>> something simple.
>> 
>> 
>> Guillaume