Re: Fwd: 2.3.0alpha1-1
Am Freitag, 12. Mai 2017 um 19:12:18, schrieb José Abílio Matos > On Friday, 12 May 2017 18.16.28 WEST Kornel Benko wrote: > > Have you tried math-preview with standard output format PDF(lualatex)? > > I know, this has nothing to do with python2 vs. python3, but since you are > > looking into the relevant files, it may interest you. > > > > Kornel > > I tried and I have the same problem I had sometime ago with previews, the > image is not cropped. > > 1) I set the default output to pdf(luatex). > 2) Entered in math mode $E=mc^2$ and left the math inset. > 3) The preview shows the whole page. > > FWIW I am using texlive 2016. Same here. > Also I noticed that the code in the scripts has not been touched for a long > time. I noted as example that the file fig2pdftex.py has a call to mkstemp to > create a temporary file. But that function is not defined anywhere so that > means the scripts does not work... You mean missing 'import tempfile'? I don't know how python (or if) inherits imports inside an import. Many modules are importing tempfile.py. Kornel signature.asc Description: This is a digitally signed message part.
Re: Fwd: 2.3.0alpha1-1
On Friday, 12 May 2017 18.16.28 WEST Kornel Benko wrote: > Have you tried math-preview with standard output format PDF(lualatex)? > I know, this has nothing to do with python2 vs. python3, but since you are > looking into the relevant files, it may interest you. > > Kornel I tried and I have the same problem I had sometime ago with previews, the image is not cropped. 1) I set the default output to pdf(luatex). 2) Entered in math mode $E=mc^2$ and left the math inset. 3) The preview shows the whole page. FWIW I am using texlive 2016. Also I noticed that the code in the scripts has not been touched for a long time. I noted as example that the file fig2pdftex.py has a call to mkstemp to create a temporary file. But that function is not defined anywhere so that means the scripts does not work... -- José Abílio
Re: Fwd: 2.3.0alpha1-1
Am Freitag, 12. Mai 2017 um 17:34:24, schrieb José Abílio Matos > With the several patches committed this week I am able to open all the > documents in the LyX's documentation with no crash in the lyxpreview scripts > when running python 3. > > I suspect that there could be other places needing to be fixed but for now it > is working. > > Regards, Have you tried math-preview with standard output format PDF(lualatex)? I know, this has nothing to do with python2 vs. python3, but since you are looking into the relevant files, it may interest you. Kornel signature.asc Description: This is a digitally signed message part.
Re: Fwd: 2.3.0alpha1-1
With the several patches committed this week I am able to open all the documents in the LyX's documentation with no crash in the lyxpreview scripts when running python 3. I suspect that there could be other places needing to be fixed but for now it is working. Regards, -- José Abílio
Re: Fwd: 2.3.0alpha1-1
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: Fwd: 2.3.0alpha1-1
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: Fwd: 2.3.0alpha1-1
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 signature.asc Description: PGP signature
Re: Fwd: 2.3.0alpha1-1
On Tuesday, 9 May 2017 08.11.22 WEST Pavel Sanda wrote: > Jose, as mentioned in other thread, could you summarize the current python > situation in master and put it into RELEASE_NOTES? > As packager I would like to see: what versions of python are currently > supported and which version is preffered for running lyx. > > Pavel The reason why I did not answer immediately in the other thread, it is in my todo list is because honestly I do not know the full extent of our python 3 support. What I know is the following: - python 2 works; - python 3 is the unknown, every time that we find a place where it does not work we have been converting it to a version that works for both versions. As I said in the other message in some places we still call python, the only place where /usr/bin/python is python 3 is on arch linux. This means in particular that if we pass, in the autotools building process, the environment variable PYTHON=/usr/bin/python3 that will be ignored. That means that we always use the system version regardless of the fact that $PYTHON is defined or not. 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: 1) src/support/os.cpp 2) lib/configure.py The easiest is 2) since we are running we can make the call to python use the same version used to run the script itself. It is enough to use sys.executable in all the places where we use python. sys.executable gives the full path to the python executable used to run the script. Another prettier option world to only use the executable name and discard the directory since this should be in path. Another option that we discussed some time ago was to create another variable in the preferences called $$python that would be converted into the python version used through lyx. For 1) we need to decide how do we choose if we find several versions of python because at the moment we go with the system python. We just test for the existence of a python executable on PATH, if there is not any we search for python with any suffix and the last tested wins. BTW I understand that the second part of the code is a last resort. In any case the test is not correct because if a python binary is found but then we find some program called python_monty (totally unrelated to a python interpreter) that would reset the command name. A better strategy would be to return after the first successful python found. So before mention anything regarding the python 3 support we need to test it in real day usage. FWIW I am confident that we should be able to run 2.3 with python 3 exclusively and that is what I am running to find the potential problems. Any comment? Regards, -- José Abílio lyx-2.3.0-force-python3.patch.gz Description: application/gzip
Re: Fwd: 2.3.0alpha1-1
José Abílio Matos wrote: > On Monday, 8 May 2017 18.48.30 WEST Richard Heck wrote: > > That's the error there. For some reason the called version of python > > does not see that module. Note that the two versions of python are very > > different: 2.7.5 and 3.6.1. I would guess that the argparse module may > > not be installed for 2.7.5. > > > > Richard > > argparse is in the standard library for both versions. So if the python > version is well/correctly installed it should be there. > > After all argparse was introduced in python 2.7. :-) > > Now I am also a bit confused because that means that we been requiring python > 2.7 for some time and no one complained. :-D Jose, as mentioned in other thread, could you summarize the current python situation in master and put it into RELEASE_NOTES? As packager I would like to see: what versions of python are currently supported and which version is preffered for running lyx. Pavel
Re: Fwd: 2.3.0alpha1-1
On Monday, 8 May 2017 18.48.30 WEST Richard Heck wrote: > That's the error there. For some reason the called version of python > does not see that module. Note that the two versions of python are very > different: 2.7.5 and 3.6.1. I would guess that the argparse module may > not be installed for 2.7.5. > > Richard argparse is in the standard library for both versions. So if the python version is well/correctly installed it should be there. After all argparse was introduced in python 2.7. :-) Now I am also a bit confused because that means that we been requiring python 2.7 for some time and no one complained. :-D -- José Abílio
Re: Fwd: 2.3.0alpha1-1
On 05/08/2017 11:22 AM, john kennan wrote:
> Scott:
>
> log file, as requested.
>
> John
>
>
> jkmac:referee jk$ /Applications/LyX.app/Contents/MacOS/lyx -dbg info
> "/Users/jk/Box Sync/jk/jkdonorblurb.lyx"
> Setting debug level to info
> Debugging `info' (General information)
> support/filetools.cpp (1002): Running: python -tt -V 2>&1
> support/filetools.cpp (1002): Running: python -tt
> "/Applications/LyX.app/Contents/Resources/scripts/prefs2prefs.py" -p
> "/Users/jk/Library/Application Support/LyX-2.3/preferences"
> "/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/convert_lyxrc.Ul2103"
> Encoding.cpp (798): Read unicode symbol 160 '~' ' '0 1 ~' '' 0 1 0 0 1
> ...
> Encoding.cpp (798): Read unicode symbol 120831 '' ' '0 0 \mathtt{9}'
> '' 0 1 0 0 1
> Encoding.cpp (864): Reading encoding utf8
> ...
> Language.cpp (210): Reading language welsh
> support/filetools.cpp (1002): Running: python -tt
> "/Applications/LyX.app/Contents/Resources/scripts/prefs2prefs.py" -l
> "/Users/jk/Library/Application Support/LyX-2.3/bind/user.bind"
> "/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/convert_bind.yA2103"
> Buffer.cpp (477): Buffer::Buffer()
> BufferList.cpp (122): Assigning to buffer 0
> Buffer.cpp (1324): Running 'python -tt
> "/Applications/LyX.app/Contents/Resources/lyx2lyx/lyx2lyx" -t 541 -o
> "/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/lyx_tmpdir.YQwVSnRg2103/Buffer_convertLyXFormatWT2103.lyx"
> "/Users/jk/Box Sync/jk/jkdonorblurb.lyx"'
> support/filetools.cpp (1002): Running: python -tt
> "/Applications/LyX.app/Contents/Resources/lyx2lyx/lyx2lyx" -t 541 -o
> "/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/lyx_tmpdir.YQwVSnRg2103/Buffer_convertLyXFormatWT2103.lyx"
> "/Users/jk/Box Sync/jk/jkdonorblurb.lyx"
> Traceback (most recent call last):
> File "/Applications/LyX.app/Contents/Resources/lyx2lyx/lyx2lyx",
> line 22, in
> import argparse
> ImportError: No module named argparse
> Error: Conversion script failed
That's the error there. For some reason the called version of python
does not see that module. Note that the two versions of python are very
different: 2.7.5 and 3.6.1. I would guess that the argparse module may
not be installed for 2.7.5.
Richard
Fwd: 2.3.0alpha1-1
Scott:
log file, as requested.
John
jkmac:referee jk$ /Applications/LyX.app/Contents/MacOS/lyx -dbg info
"/Users/jk/Box Sync/jk/jkdonorblurb.lyx"
Setting debug level to info
Debugging `info' (General information)
support/filetools.cpp (1002): Running: python -tt -V 2>&1
support/filetools.cpp (1002): Running: python -tt
"/Applications/LyX.app/Contents/Resources/scripts/prefs2prefs.py" -p
"/Users/jk/Library/Application Support/LyX-2.3/preferences"
"/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/convert_lyxrc.Ul2103"
Encoding.cpp (798): Read unicode symbol 160 '~' ' '0 1 ~' '' 0 1 0 0 1
...
Encoding.cpp (798): Read unicode symbol 120831 '' ' '0 0 \mathtt{9}' '' 0 1
0 0 1
Encoding.cpp (864): Reading encoding utf8
...
Language.cpp (210): Reading language welsh
support/filetools.cpp (1002): Running: python -tt
"/Applications/LyX.app/Contents/Resources/scripts/prefs2prefs.py" -l
"/Users/jk/Library/Application Support/LyX-2.3/bind/user.bind"
"/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/convert_bind.yA2103"
Buffer.cpp (477): Buffer::Buffer()
BufferList.cpp (122): Assigning to buffer 0
Buffer.cpp (1324): Running 'python -tt
"/Applications/LyX.app/Contents/Resources/lyx2lyx/lyx2lyx" -t 541 -o
"/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/lyx_tmpdir.YQwVSnRg2103/Buffer_convertLyXFormatWT2103.lyx"
"/Users/jk/Box Sync/jk/jkdonorblurb.lyx"'
support/filetools.cpp (1002): Running: python -tt
"/Applications/LyX.app/Contents/Resources/lyx2lyx/lyx2lyx" -t 541 -o
"/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/lyx_tmpdir.YQwVSnRg2103/Buffer_convertLyXFormatWT2103.lyx"
"/Users/jk/Box Sync/jk/jkdonorblurb.lyx"
Traceback (most recent call last):
File "/Applications/LyX.app/Contents/Resources/lyx2lyx/lyx2lyx", line 22,
in
import argparse
ImportError: No module named argparse
Error: Conversion script failed
/Users/jk/Box Sync/jk/jkdonorblurb.lyx is from an older version of LyX and
the lyx2lyx script failed to convert it.
Buffer.cpp (495): Buffer::~Buffer()
LyX.cpp (444): Deleting tmp dir
/var/folders/s6/r89g40d97y98b56w71p_49ncgn/T/lyx_tmpdir.YQwVSnRg2103
-- Forwarded message --
From: Scott Kostyshak
Date: Mon, May 8, 2017 at 9:51 AM
Subject: Re: 2.3.0alpha1-1
To: john kennan
Cc: LyX Developers
On Sun, May 07, 2017 at 07:00:40PM -0500, john kennan wrote:
> Scott:
>
> I think I misunderstood. Running lyx2lyx with or without the python prefix
> does indeed (silently) produce output -- the new files can be read by
> 2.3alpha1-1 with no trouble.
>
> But attempting to load the older format files from within LyX still
doesn't
> work (even after installing Python3)
>
> jkmac:~ jk$ python --version
> Python 2.7.5 :: Anaconda 1.8.0 (x86_64)
> jkmac:~ jk$ python3 --version
> Python 3.6.1
>
> John
Hi John,
Please always respond to the list.
Thanks for your debugging efforts! It's useful to know that lyx2lyx
works when called directly, but for some reason not when LyX calls it.
I wonder if using Python Anaconda instead of just vanilla Python
confuses LyX. Of course it shouldn't be a problem, but debugging is all
about figuring out what it is that should work is not working.
Can you try opening the .lyx file from the command line? I don't know
how to do that on Mac. When you do that, after you get the error in the
GUI (about unable to convert), can you check the terminal and see if
there is any useful information?
Can you also do the same as the above, but this time add the option
-dbg info
to the command? For me, this would be
lyx -dbg info myfile.lyx
Can you then copy the output from the terminal to a log file, and post
it to the list? (read the log first to make sure you are not posting any
private information).
Thanks for your help in testing,
Scott
signature.asc
Description: PGP signature
