Re: Fix lyxpak to be Python 3 compatible

[José Matos]

On Wed, 2023-12-06 at 14:21 -0500, Scott Kostyshak wrote:
> Thanks for the quick fix!
> 
> It's in master at 9143878e.
> 
> Next time, it might be easier if you make the patch with
> 
>   git format-patch HEAD^
> 
> This way you can add a commit message.
> 
> Scott

Thank you for the hint. I will use it. :-)
-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Fix lyxpak to be Python 3 compatible

[Scott Kostyshak]

On Wed, Dec 06, 2023 at 04:16:10PM +, José Matos wrote:
> Based on the error reported on the lyx-users here follows a fix for
> issue reported.
> 
> I took the change and I changed some minor annoyances:
> * test comparison with None;
> * fixed a region where the indentation was different from all the
> others (2 spaces instead of 4);
> * replaced xrange with range.
> 
> Could someone, please, commit this?

Thanks for the quick fix!

It's in master at 9143878e.

Next time, it might be easier if you make the patch with

  git format-patch HEAD^

This way you can add a commit message.

Scott


signature.asc
Description: PGP signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Fix lyxpak to be Python 3 compatible

[José Matos]

Based on the error reported on the lyx-users here follows a fix for
issue reported.

I took the change and I changed some minor annoyances:
* test comparison with None;
* fixed a region where the indentation was different from all the
others (2 spaces instead of 4);
* replaced xrange with range.

Could someone, please, commit this?

Regards,
-- 
José Abílio
diff --git a/lib/scripts/lyxpak.py b/lib/scripts/lyxpak.py
index affef65644..6cdea5c53f 100755
--- a/lib/scripts/lyxpak.py
+++ b/lib/scripts/lyxpak.py
@@ -233,7 +233,7 @@ def find_lyx2lyx(progloc, path):
 if "PATHEXT" in os.environ:
 extlist = extlist + os.environ["PATHEXT"].split(os.pathsep)
 lyx_exe, full_path = find_exe(["lyxc", "lyx"], extlist, path)
-if lyx_exe == None:
+if lyx_exe is None:
 error('Cannot find the LyX executable in the path.')
 try:
 cmd_stdout = subprocess.check_output([lyx_exe, '-version'], stderr=subprocess.STDOUT)
@@ -265,9 +265,9 @@ def main(args):
 ourprog = args[0]
 
 try:
-  (options, argv) = getopt(args[1:], "htzl:o:")
+(options, argv) = getopt(args[1:], "htzl:o:")
 except:
-  error(usage(ourprog))
+error(usage(ourprog))
 
 # we expect the filename to be left
 if len(argv) != 1:
@@ -278,19 +278,19 @@ def main(args):
 lyx2lyx = None
 
 for (opt, param) in options:
-  if opt == "-h":
-print(usage(ourprog))
-sys.exit(0)
-  elif opt == "-t":
-makezip = False
-  elif opt == "-z":
-makezip = True
-  elif opt == "-l":
-lyx2lyx = param
-  elif opt == "-o":
-outdir = param
-if not os.path.isdir(unicode(outdir, 'utf-8')):
-  error('Error: "%s" is not a directory.' % outdir)
+if opt == "-h":
+print(usage(ourprog))
+sys.exit(0)
+elif opt == "-t":
+makezip = False
+elif opt == "-z":
+makezip = True
+elif opt == "-l":
+lyx2lyx = param
+elif opt == "-o":
+outdir = param
+if not os.path.isdir(unicode(outdir, 'utf-8')):
+error('Error: "%s" is not a directory.' % outdir)
 
 lyxfile = argv[0]
 if not running_on_windows:
@@ -320,7 +320,7 @@ def main(args):
 
 path = os.environ["PATH"].split(os.pathsep)
 
-if lyx2lyx == None:
+if lyx2lyx is None:
 lyx2lyx = find_lyx2lyx(ourprog, path)
 
 # Initialize the list with the specified LyX file and recursively
@@ -390,7 +390,7 @@ if __name__ == "__main__":
 argc = c_int(0)
 argv_unicode = CommandLineToArgvW(GetCommandLineW(), byref(argc))
 # unicode_argv[0] is the Python interpreter, so skip that.
-argv = [argv_unicode[i].encode('utf-8') for i in xrange(1, argc.value)]
+argv = [argv_unicode[i].encode('utf-8') for i in range(1, argc.value)]
 # Also skip option arguments to the Python interpreter.
 while len(argv) > 0:
 if not argv[0].startswith("-"):
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: postats.py broken with Python 3

[Richard Kimberly Heck]

On 9/18/20 1:32 PM, José Abílio Matos wrote:
>
> On Friday, September 18, 2020 4:59:47 PM WEST Richard Kimberly Heck wrote:
>
> > The version of postats.py in master has been updated to work with
>
> > (indeed, require) Python 3. Is there any reason not to backport it?
>
> >
>
> > Riki
>
>
> No. :-)
>
>
> In this case this is a development tool, and those traditionally can
> have different requirements from the user oriented tools that we create.
>
>
> After the last update to the 2.3.x series is released, that will
> happen after 2.4.0 release, I will strip all the python 2 (only)
> remnants from the python scripts. :-)
>
OK, backported then.

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: postats.py broken with Python 3

[José Abílio Matos]

On Friday, September 18, 2020 4:59:47 PM WEST Richard Kimberly Heck wrote:
> The version of postats.py in master has been updated to work with
> (indeed, require) Python 3. Is there any reason not to backport it?
> 
> Riki

No. :-)

In this case this is a development tool, and those traditionally can have 
different requirements from the user oriented tools that we create.

After the last update to the 2.3.x series is released, that will happen after 
2.4.0 release, I will strip all the python 2 (only) remnants from the python 
scripts. :-)
-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: postats.py broken with Python 3

[Jürgen Spitzmüller]

Am Freitag, den 18.09.2020, 11:59 -0400 schrieb Richard Kimberly Heck:
> The version of postats.py in master has been updated to work with
> (indeed, require) Python 3. Is there any reason not to backport it?

Since you're the one who needs to use it (and the only real user) I
think this is completely up to you.

Jürgen


signature.asc
Description: This is a digitally signed message part
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: postats.py broken with Python 3

[Richard Kimberly Heck]

The version of postats.py in master has been updated to work with
(indeed, require) Python 3. Is there any reason not to backport it?

Riki


On 9/18/20 11:32 AM, Richard Kimberly Heck wrote:
> ../lyx-stable/po/ [⚡ 2.3.x] > /usr/bin/python3 ./postats.py "2.3.5.2"
> ar.po bg.po cs.po de.po el.po en.po es.po eu.po fi.po fr.po he.po hu.po
> ia.po id.po it.po ja.po nb.po nl.po nn.po pl.po pt_BR.po pt_PT.po ru.po
> sk.po sv.po tr.po uk.po zh_CN.po zh_TW.po >i18n.inc
> Traceback (most recent call last):
>   File "./postats.py", line 144, in 
>     )?>""" % (sys.argv[1], branch_tag, ",".join([run_msgfmt(po) for po
> in sys.argv[2:] if po not in ommitted])))
>   File "./postats.py", line 144, in 
>     )?>""" % (sys.argv[1], branch_tag, ",".join([run_msgfmt(po) for po
> in sys.argv[2:] if po not in ommitted])))
>   File "./postats.py", line 103, in run_msgfmt
>     header = read_pofile(pofile)
>   File "./postats.py", line 72, in read_pofile
>     for line in open(pofile):
>   File "/usr/lib64/python3.7/encodings/ascii.py", line 26, in decode
>     return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position
> 872: ordinal not in range(128)
>
> ../lyx-stable/po/ [⚡ 2.3.x] > /usr/bin/python2 ./postats.py "2.3.5.2"
> ar.po bg.po cs.po de.po el.po en.po es.po eu.po fi.po fr.po he.po hu.po
> ia.po id.po it.po ja.po nb.po nl.po nn.po pl.po pt_BR.po pt_PT.po ru.po
> sk.po sv.po tr.po uk.po zh_CN.po zh_TW.po >i18n.inc
>
> Success!
>
> Riki
>
>

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

postats.py broken with Python 3

[Richard Kimberly Heck]

../lyx-stable/po/ [⚡ 2.3.x] > /usr/bin/python3 ./postats.py "2.3.5.2"
ar.po bg.po cs.po de.po el.po en.po es.po eu.po fi.po fr.po he.po hu.po
ia.po id.po it.po ja.po nb.po nl.po nn.po pl.po pt_BR.po pt_PT.po ru.po
sk.po sv.po tr.po uk.po zh_CN.po zh_TW.po >i18n.inc
Traceback (most recent call last):
  File "./postats.py", line 144, in 
    )?>""" % (sys.argv[1], branch_tag, ",".join([run_msgfmt(po) for po
in sys.argv[2:] if po not in ommitted])))
  File "./postats.py", line 144, in 
    )?>""" % (sys.argv[1], branch_tag, ",".join([run_msgfmt(po) for po
in sys.argv[2:] if po not in ommitted])))
  File "./postats.py", line 103, in run_msgfmt
    header = read_pofile(pofile)
  File "./postats.py", line 72, in read_pofile
    for line in open(pofile):
  File "/usr/lib64/python3.7/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position
872: ordinal not in range(128)

../lyx-stable/po/ [⚡ 2.3.x] > /usr/bin/python2 ./postats.py "2.3.5.2"
ar.po bg.po cs.po de.po el.po en.po es.po eu.po fi.po fr.po he.po hu.po
ia.po id.po it.po ja.po nb.po nl.po nn.po pl.po pt_BR.po pt_PT.po ru.po
sk.po sv.po tr.po uk.po zh_CN.po zh_TW.po >i18n.inc

Success!

Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [PATCH] Port gnuplot2pdf.py to Python 3

[Scott Kostyshak]

On Wed, Sep 04, 2019 at 12:24:40PM -, Guenter Milde wrote:
> On 2019-08-30, Scott Kostyshak wrote:
> 
> > [-- Type: text/plain, Encoding: quoted-printable --]
> 
> > The current script fails for me. The attached patch seems to work, but I
> > only got it to work by experimenting. Can any Pythonista take a close
> > look? With the wait() command it seems to hang, so I substituted
> > communicate() as mentioned here:
> 
> >   https://docs.python.org/3/library/subprocess.html 
> 
> The patch looks fine to me.

Thanks for taking a look. Committed to master at db65b1a3.

Scott


signature.asc
Description: PGP signature

Re: [PATCH] Port gnuplot2pdf.py to Python 3

[Guenter Milde]

On 2019-08-30, Scott Kostyshak wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> The current script fails for me. The attached patch seems to work, but I
> only got it to work by experimenting. Can any Pythonista take a close
> look? With the wait() command it seems to hang, so I substituted
> communicate() as mentioned here:

>   https://docs.python.org/3/library/subprocess.html 

The patch looks fine to me.

Thanks,

Günter

[PATCH] Port gnuplot2pdf.py to Python 3

[Scott Kostyshak]

The current script fails for me. The attached patch seems to work, but I
only got it to work by experimenting. Can any Pythonista take a close
look? With the wait() command it seems to hang, so I substituted
communicate() as mentioned here:

  https://docs.python.org/3/library/subprocess.html 

Thanks,

Scott
From c7c3aca52ea05d9c176a07d0149a77ca456e95d4 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Thu, 29 Aug 2019 20:48:34 -0400
Subject: [PATCH] Port gnuplot2pdf.py to Python 3

Instead of wait(), use communicate(), as mentioned here:

  https://docs.python.org/3/library/subprocess.html
---
 lib/scripts/gnuplot2pdf.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/scripts/gnuplot2pdf.py b/lib/scripts/gnuplot2pdf.py
index fb036b2df5..e7246a3dea 100755
--- a/lib/scripts/gnuplot2pdf.py
+++ b/lib/scripts/gnuplot2pdf.py
@@ -11,7 +11,7 @@ if (len(argv) != 3):
 
 with open(argv[1], 'rb') as fsrc:
 subproc = Popen("gnuplot", shell=True, stdin=PIPE)
-subproc.stdin.write("set terminal pdf\nset output '%s'\n" % argv[2])
+subproc.stdin.write(b"set terminal pdf\nset output '%s'\n" % argv[2].encode())
 shutil.copyfileobj(fsrc, subproc.stdin)
-subproc.stdin.write("exit\n")
-subproc.wait()
+subproc.stdin.write(b"exit\n")
+subproc.communicate()
-- 
2.20.1



signature.asc
Description: PGP signature

Re: [LyX/2.3.x] Fix encoding issues with configuration under Python 3.

[Stephan Witt]

Am 22.08.2019 um 17:01 schrieb Jürgen Spitzmüller :
> 
> Am Donnerstag, den 22.08.2019, 16:55 +0200 schrieb Stephan Witt:
>> The status entry is missing.
>> 
>> I don’t know where to add it…
> 
> I'll do when I push the fix proposed at
> https://www.lyx.org/trac/ticket/11642#comment:13

Wouldn’t it be a good idea to record the python version in configure.log?

Stephan

Re: [LyX/2.3.x] Fix encoding issues with configuration under Python 3.

[Jürgen Spitzmüller]

Am Donnerstag, den 22.08.2019, 16:55 +0200 schrieb Stephan Witt:
> The status entry is missing.
> 
> I don’t know where to add it…

I'll do when I push the fix proposed at
https://www.lyx.org/trac/ticket/11642#comment:13

Jürgen


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

Re: [LyX/2.3.x] Fix encoding issues with configuration under Python 3.

[Stephan Witt]

Am 21.08.2019 um 23:10 schrieb Günter Milde :
> 
> commit d30da478d4f8ca861ee36ff77f6cc10c6f7bfd2b
> Author: Günter Milde 
> Date:   Wed Aug 21 23:20:27 2019 +0200
> 
>Fix encoding issues with configuration under Python 3.
> 
>Backported from [b9cc642/lyxgit].
> ---
> lib/configure.py |  262 --
> 1 files changed, 134 insertions(+), 128 deletions(-)

The status entry is missing.

I don’t know where to add it…

Stephan

Re: configure.py crashing with Python 3 [was: LyX v 2.3.x - severe Problems]

[Richard Kimberly Heck]

On 8/20/19 1:56 PM, Matthias Görlach wrote:
> Hi Riki,
>
> thank you for this analysis/hint - this was perfect for a "work around":
>
> 0) install python v 2.7.16 (well, will have to deal with things which
> require python 3.X)
> 1) deleted the LyX-2.3 directory (folder) from ~/Library/Application
> Support
> 2) mkdir of an empty Lyx-2.3 dir
> 3) cd into it
> 4) run python -tt
> /Applications/LyX.app/Contents/Resources/configure.py
> --with-version-suffix=-2.3
> --binary-dir=/Applications/LyX.app/Contents/MacOS/
> ==> 5) last lines of terminal output:
> ...
> +checking for package natbib [natbib]... yes
> +Inspection done.
> +Read the file doc/LaTeXConfig.lyx for more information.
>
>
> 6) low & behold: starting LyX 2.3 works fine - no error messages
> anymore (and my templates work again)
>
> Of course it will be better to eventually have LyX 2.3 working with
> the more recent python.

Thanks for confirming that this solves the problem. But yes, LyX is
supposed to work with Python 3, and obviously it does not at the moment.

We'll certainly want to test whatever changes we eventually make to
configure.py. I have created a bug report for this here:

https://www.lyx.org/trac/ticket/11642

If you add yourself (you may have to create an account) in the cc list,
you'll be notified as there are updates. It will be possible to test
this, simply by downloading the new configure.py script and running it
the same way.

Riki

Re: configure.py crashing with Python 3 [was: LyX v 2.3.x - severe Problems]

[Matthias Görlach]

Hi Riki,

thank you for this analysis/hint - this was perfect for a "work around":

0) install python v 2.7.16 (well, will have to deal with things which 
require python 3.X)

1) deleted the LyX-2.3 directory (folder) from ~/Library/Application Support
2) mkdir of an empty Lyx-2.3 dir
3) cd into it
4) run python -tt /Applications/LyX.app/Contents/Resources/configure.py 
--with-version-suffix=-2.3 
--binary-dir=/Applications/LyX.app/Contents/MacOS/

==> 5) last lines of terminal output:
...
+checking for package natbib [natbib]... yes
+Inspection done.
+Read the file doc/LaTeXConfig.lyx for more information.


6) low & behold: starting LyX 2.3 works fine - no error messages anymore 
(and my templates work again)


Of course it will be better to eventually have LyX 2.3 working with the 
more recent python.


Let me know if I should test this at some point.

Best

Matthias

On 19.08.19 22:42, Richard Kimberly Heck wrote:

On 8/19/19 4:16 PM, Matthias Görlach wrote:

Hi,

see below

On 19.08.19 22:02, Richard Kimberly Heck wrote:

On 8/19/19 2:41 PM, Matthias Görlach wrote:

To check another thing: there is an automatic upgrade in configure run.
Perhaps it copies some problematic contents from your 2.2 installation.
To circumvent this you may try these commands (no sudo please):
$ mkdir /tmp/LyX
$ cd /tmp/LyX
$ python -tt /Applications/LyX.app/Contents/Resources/configure.py 
--binary-dir=/Applications/LyX.app/Contents/MacOS/

My result (and config.log attached here)
ls -ltr
total 1088
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 ui
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 templates
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 scripts
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 layouts
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 kbd
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 images
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 examples
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 doc
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 clipart
-rw-r--r--  1 mago  staff  99 Aug 19 20:30 chklatex.ltx
-rw-r--r--  1 mago  staff 664 Aug 19 20:30 chklatex.log
drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 bind
-rw-r--r--  1 mago  staff   19973 Aug 19 20:30 lyxrc.defaults
-rw-r--r--  1 mago  staff   36766 Aug 19 20:30 clsFiles.lst
-rw-r--r--  1 mago  staff  365181 Aug 19 20:30 styFiles.lst
-rw-r--r--  1 mago  staff   26300 Aug 19 20:30 bstFiles.lst
-rw-r--r--  1 mago  staff    4449 Aug 19 20:30 bibFiles.lst
-rw-r--r--  1 mago  staff 293 Aug 19 20:30 lyxmodules.lst
-rw-r--r--  1 mago  staff   37133 Aug 19 20:30 configure.log
-rw-r--r--  1 mago  staff  26 Aug 19 20:30 chkmodules.tex
-rw-r--r--  1 mago  staff   15685 Aug 19 20:30 cbxFiles.lst
-rw-r--r--  1 mago  staff   17136 Aug 19 20:30 bbxFiles.lst


The configure script looks to be crashing when it tries to process 
the first module file. The fact that chklatex.ltx and chkmodules.txt 
have not been removed indicate that, as does the suspiciously small 
size of your chkmodules.tex.


Can you run the command Stephan gave you from the terminal again, 
but this time copy and paste the end of the output? I'm wondering 
whether Python itself is issuing some kind of error message.



+checking list of modules...
/Applications/LyX.app/Contents/Resources/layouts/algorithm2e.module
Traceback (most recent call last):
  File "/Applications/LyX.app/Contents/Resources/configure.py", line 
1892, in 

    checkModulesConfig()
  File "/Applications/LyX.app/Contents/Resources/configure.py", line 
1511, in checkModulesConfig
    retval = processModuleFile(file, filename.encode('ascii'), 
bool_docbook)
  File "/Applications/LyX.app/Contents/Resources/configure.py", line 
1607, in processModuleFile

    % (modname, filename, desc, pkgs, req, excl, catgy))
TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'


Yes, well, there's the crash.

This particular line is from 576b94138. Jürgen?


Can you also check the python version you are using? Run python 
--version.



Python 3.3.7


Mostly, the point is that it's Python 3, though maybe the problem is 
specific to this version. As I said, though, I'm seeing a crash here 
with 3.7.4 that looks similar:


Traceback (most recent call last):
  File "/usr/local/share/lyx/configure.py", line 1896, in 
    ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1379, in checkLatexConfig
    retval = processLayoutFile(file, bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1327, in 
processLayoutFile

    % (classname, opt, desc, avai, prereq))
TypeError: %b requires a bytes-like object, or an object that 
implements __bytes__, not 'str'


Mine comes from the same commit.

Riki




--
Matthias Görlach
Ebertstr. 4
07743 Jena

*49-0171 1988809

configure.py crashing with Python 3 [was: LyX v 2.3.x - severe Problems]

[Richard Kimberly Heck]

On 8/19/19 4:16 PM, Matthias Görlach wrote:
> Hi,
>
> see below
>
> On 19.08.19 22:02, Richard Kimberly Heck wrote:
>> On 8/19/19 2:41 PM, Matthias Görlach wrote:
>>>  
>>>> To check another thing: there is an automatic upgrade in configure run.
>>>> Perhaps it copies some problematic contents from your 2.2 installation.
>>>> To circumvent this you may try these commands (no sudo please):
>>>> $ mkdir /tmp/LyX
>>>> $ cd /tmp/LyX
>>>> $ python -tt /Applications/LyX.app/Contents/Resources/configure.py 
>>>> --binary-dir=/Applications/LyX.app/Contents/MacOS/
>>> My result (and config.log attached here)
>>> ls -ltr
>>> total 1088
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 ui
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 templates
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 scripts
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 layouts
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 kbd
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 images
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 examples
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 doc
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 clipart
>>> -rw-r--r--  1 mago  staff  99 Aug 19 20:30 chklatex.ltx
>>> -rw-r--r--  1 mago  staff 664 Aug 19 20:30 chklatex.log
>>> drwxr-xr-x  2 mago  staff  68 Aug 19 20:30 bind
>>> -rw-r--r--  1 mago  staff   19973 Aug 19 20:30 lyxrc.defaults
>>> -rw-r--r--  1 mago  staff   36766 Aug 19 20:30 clsFiles.lst
>>> -rw-r--r--  1 mago  staff  365181 Aug 19 20:30 styFiles.lst
>>> -rw-r--r--  1 mago  staff   26300 Aug 19 20:30 bstFiles.lst
>>> -rw-r--r--  1 mago  staff    4449 Aug 19 20:30 bibFiles.lst
>>> -rw-r--r--  1 mago  staff 293 Aug 19 20:30 lyxmodules.lst
>>> -rw-r--r--  1 mago  staff   37133 Aug 19 20:30 configure.log
>>> -rw-r--r--  1 mago  staff  26 Aug 19 20:30 chkmodules.tex
>>> -rw-r--r--  1 mago  staff   15685 Aug 19 20:30 cbxFiles.lst
>>> -rw-r--r--  1 mago  staff   17136 Aug 19 20:30 bbxFiles.lst
>>
>> The configure script looks to be crashing when it tries to process
>> the first module file. The fact that chklatex.ltx and chkmodules.txt
>> have not been removed indicate that, as does the suspiciously small
>> size of your chkmodules.tex.
>>
>> Can you run the command Stephan gave you from the terminal again, but
>> this time copy and paste the end of the output? I'm wondering whether
>> Python itself is issuing some kind of error message.
>>
> +checking list of modules...
> /Applications/LyX.app/Contents/Resources/layouts/algorithm2e.module
> Traceback (most recent call last):
>   File "/Applications/LyX.app/Contents/Resources/configure.py", line
> 1892, in 
>     checkModulesConfig()
>   File "/Applications/LyX.app/Contents/Resources/configure.py", line
> 1511, in checkModulesConfig
>     retval = processModuleFile(file, filename.encode('ascii'),
> bool_docbook)
>   File "/Applications/LyX.app/Contents/Resources/configure.py", line
> 1607, in processModuleFile
>     % (modname, filename, desc, pkgs, req, excl, catgy))
> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'

Yes, well, there's the crash.

This particular line is from 576b94138. Jürgen?


>> Can you also check the python version you are using? Run python
>> --version.
>>
> Python 3.3.7

Mostly, the point is that it's Python 3, though maybe the problem is
specific to this version. As I said, though, I'm seeing a crash here
with 3.7.4 that looks similar:

Traceback (most recent call last):
  File "/usr/local/share/lyx/configure.py", line 1896, in 
    ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1379, in checkLatexConfig
    retval = processLayoutFile(file, bool_docbook)
  File "/usr/local/share/lyx/configure.py", line 1327, in processLayoutFile
    % (classname, opt, desc, avai, prereq))
TypeError: %b requires a bytes-like object, or an object that implements
__bytes__, not 'str'

Mine comes from the same commit.

Riki

Re: [LyX/master] Make po statistics script work with Python 3.

[Jürgen Spitzmüller]

Am Dienstag, den 16.07.2019, 11:58 + schrieb Guenter Milde:
> Should be fixed in 6b88e4bf3b

Confirmed. Thanks.

> 
> 2 questions:
> 
> * Is the generation of *.gmo files as side-effect of running
> postats.py
>   intended/required or an oversight?

Don't know.

>   
> * Is it OK to emit utf8 encoded author names or is xmlcharrefreplace
> required?

utf8 is OK for the purpose of make i18n.inc at least.

Jürgen


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

Re: [LyX/master] Make po statistics script work with Python 3.

[Guenter Milde]

On 2019-07-15, Jürgen Spitzmüller wrote:

> [-- Type: text/plain, Encoding: quoted-printable --]

> Am Montag, den 15.07.2019, 18:00 +0200 schrieb Günter Milde:
>> commit d3f6ec003d3e9f972abd3eeff19cd06e4a865104
>> Author: Günter Milde 
>> Date:   Mon Jul 15 18:07:22 2019 +0200

>> Make po statistics script work with Python 3.

> Alas, this does not work; make_i18n.inc produces an invalid files (all
> numbers are 0, and the translatior names are embraced by b'...').

I see:

a) postats.py processes not the standard output but the error output of
   `msgfmt`, so this needed to be redirected.
   
b) encodings issues in Python are a pain and later Python 3 versions do no
   longer autoconvert :-(
   
Should be fixed in 6b88e4bf3b

2 questions:

* Is the generation of *.gmo files as side-effect of running postats.py
  intended/required or an oversight?
  
* Is it OK to emit utf8 encoded author names or is xmlcharrefreplace required?

Günter

Re: [LyX/master] Make po statistics script work with Python 3.

[Jürgen Spitzmüller]

Am Montag, den 15.07.2019, 18:00 +0200 schrieb Günter Milde:
> commit d3f6ec003d3e9f972abd3eeff19cd06e4a865104
> Author: Günter Milde 
> Date:   Mon Jul 15 18:07:22 2019 +0200
> 
> Make po statistics script work with Python 3.

Alas, this does not work; make_i18n.inc produces an invalid files (all
numbers are 0, and the translatior names are embraced by b'...').

Jürgen


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

Re: convertDefault.py is broken under python 3

[José Abílio Matos]

On Wednesday, 5 June 2019 10.53.55 WEST Jean-Marc Lasgouttes wrote:
> Indeed. This has been fixed by Uwe already, BTW.
> 
> JMarc

You are right. Only yesterday while reviewing I finally noticed that the 
restriction was not there anymore. :-)

I saw that because I was looking into the output of "git annotate" (who am I 
kidding, it was really "git blame") ;-) just to found out (as usual) that I am 
the one to blame. :-D

-- 
José Abílio

Re: convertDefault.py is broken under python 3

[Jean-Marc Lasgouttes]

Le 03/06/2019 à 18:45, José Abílio Matos a écrit :

On Monday, 11 February 2019 00.25.41 WEST Uwe Stöhr wrote:

Besides this I don't understand why we limit the depth for image
conversions to 8 bit:
sopts = "-depth 8"


Unless there is a strong reason to limit the conversions to 8 bit I agree with
Uwe.


Indeed. This has been fixed by Uwe already, BTW.

JMarc

Re: InstantPreview fails with Python 3

[José Abílio Matos]

On Monday, 11 February 2019 00.57.16 WEST Uwe Stöhr wrote:
> InstantPreview fails with Python 3.7.2 and I cannot figure out why. In
> the console I see:
> 
> - graphics\PreviewLoader.cpp (781):
> PreviewLoader::finishedInProgress(1): processing failed for python -tt
> $$s/scripts/lyxpreview2bitmap.py --png
> "C:/Users/User/AppData/Local/Temp/lyx_tmpdir.PlMVrEJL4248/lyx_tmpbuf0/lyxpre
> viewZb4248.tex" --dpi 115 --fg 00 --bg faf0e6 --bibtex="bibtex"
> 
> I tried to run the lyxpreview2bitmap.py manually in a console and then
> get the error that it cannot find gswin32c or gswin64c. But the path to
> it is correctly set in the LyX preferences.
> 
> I also could not find out how to tell the script a path to gswin32c.
> Therefore I could not investigate further.
> José, could you maybe have a look and tell me at least how to specify
> the path to gswin32c when executing the script in a console?
> 
> thanks and regards
> Uwe

Hi Uwe,
do you still have this problem?

Best regards,
-- 
José Abílio

Re: convertDefault.py is broken under python 3

[José Abílio Matos]

On Monday, 11 February 2019 00.25.41 WEST Uwe Stöhr wrote:
> Besides this I don't understand why we limit the depth for image
> conversions to 8 bit:
> sopts = "-depth 8"

Unless there is a strong reason to limit the conversions to 8 bit I agree with 
Uwe.

Regards,
-- 
José Abílio

Re: convertDefault.py is broken under python 3

[José Abílio Matos]

On Thursday, 21 March 2019 01.37.56 WEST Uwe Stöhr wrote:
> Am 18.03.2019 um 02:31 schrieb Scott Kostyshak:
> > Bump. Did we get this figured out?
> 
> Well, the -depth8 restriction for ImageMagick can definitely go and i
> now just did this. Nevertheless convertDefault.py is broken under python
> 3.7.x
> 
> regards Uwe

Hi,
what is the error you get?

I tried to run this using simple files and failed to reproduce it works for 
me.

There was a bug when the output format was ppm that I have fixed meanwhile (I 
found it be accident, because who wants to convert from png to ppm (?) as I 
was testing).

Best regards,
-- 
José Abílio

Re: convertDefault.py is broken under python 3

[José Abílio Matos]

On Monday, 11 February 2019 00.25.41 WET Uwe Stöhr wrote:
> Attached is the diff to get it at least to work.
> José, could you please have a look?

I am sorry for not replying before. It is in my todo list as soon as I have 
some free time (from tasks that are urgent and important).

I will take a look into probably at the begin of next week.

Best regards,
-- 
José Abílio

Re: convertDefault.py is broken under python 3

[Uwe Stöhr]

Am 18.03.2019 um 02:31 schrieb Scott Kostyshak:


Bump. Did we get this figured out?


Well, the -depth8 restriction for ImageMagick can definitely go and i
now just did this. Nevertheless convertDefault.py is broken under python
3.7.x

regards Uwe

Re: convertDefault.py is broken under python 3

[Guenter Milde]

On 2019-03-18, Scott Kostyshak wrote:
> On Mon, Feb 11, 2019 at 01:25:41AM +0100, Uwe Stöhr wrote:
>> Today I tried LyX 2.3.2 with Python 3.7.2 and found that all image
>> conversions failed. I investigated and I found out that this commit
>> introduced the problem:
>> 5b160e82

>> Line 38 fails since there is no .decode() for strings.
>> Also line 35 fails but strangely not line 29.

>> Attached is the diff to get it at least to work.
>> José, could you please have a look?

This was fixed on  Feb 28 in 9abd46b4d5056d11e4b.

>> Besides this I don't understand why we limit the depth for image
>> conversions to 8 bit:
>> sopts = "-depth 8"

>> I cannot see a reason for this limitation. So if there is no longer one,
>> sopts should be kept empty in line 22.

Don't know about this.

Günter

Re: convertDefault.py is broken under python 3

[Scott Kostyshak]

On Mon, Feb 11, 2019 at 01:25:41AM +0100, Uwe Stöhr wrote:
> Today I tried LyX 2.3.2 with Python 3.7.2 and found that all image
> conversions failed. I investigated and I found out that this commit
> introduced the problem:
> 5b160e82
> 
> Line 38 fails since there is no .decode() for strings.
> Also line 35 fails but strangely not line 29.
> 
> Attached is the diff to get it at least to work.
> José, could you please have a look?
> 
> Besides this I don't understand why we limit the depth for image
> conversions to 8 bit:
> sopts = "-depth 8"
> 
> I cannot see a reason for this limitation. So if there is no longer one,
> sopts should be kept empty in line 22.
> 
> thanks and regards
> Uwe

Bump. Did we get this figured out?

Scott


signature.asc
Description: PGP signature

InstantPreview fails with Python 3

[Uwe Stöhr]

InstantPreview fails with Python 3.7.2 and I cannot figure out why. In
the console I see:

- graphics\PreviewLoader.cpp (781):
PreviewLoader::finishedInProgress(1): processing failed for python -tt
$$s/scripts/lyxpreview2bitmap.py --png
"C:/Users/User/AppData/Local/Temp/lyx_tmpdir.PlMVrEJL4248/lyx_tmpbuf0/lyxpreviewZb4248.tex"
--dpi 115 --fg 00 --bg faf0e6 --bibtex="bibtex"

I tried to run the lyxpreview2bitmap.py manually in a console and then
get the error that it cannot find gswin32c or gswin64c. But the path to
it is correctly set in the LyX preferences.

I also could not find out how to tell the script a path to gswin32c.
Therefore I could not investigate further.
José, could you maybe have a look and tell me at least how to specify
the path to gswin32c when executing the script in a console?

thanks and regards
Uwe

convertDefault.py is broken under python 3

[Uwe Stöhr]

Today I tried LyX 2.3.2 with Python 3.7.2 and found that all image
conversions failed. I investigated and I found out that this commit
introduced the problem:
5b160e82

Line 38 fails since there is no .decode() for strings.
Also line 35 fails but strangely not line 29.

Attached is the diff to get it at least to work.
José, could you please have a look?

Besides this I don't understand why we limit the depth for image
conversions to 8 bit:
sopts = "-depth 8"

I cannot see a reason for this limitation. So if there is no longer one,
sopts should be kept empty in line 22.

thanks and regards
Uwe
diff --git 
"a/C:\\Users\\USti\\AppData\\Local\\Temp\\TortoiseGit\\convertDefault-4162ed1.000.py"
 "b/D:\\LyXGit\\Master\\lib\\scripts\\convertDefault.py"
index 8678965013..3a2cd645aa 100644
--- 
"a/C:\\Users\\USti\\AppData\\Local\\Temp\\TortoiseGit\\convertDefault-4162ed1.000.py"
+++ "b/D:\\LyXGit\\Master\\lib\\scripts\\convertDefault.py"
@@ -32,10 +32,10 @@ if fout.close() != None:
 # caution: windows has a convert.exe for converting file systems
 command = 'convert'
 fout = os.popen('convert -version 2>&1')
-output = fout.readline()
+#output = fout.readline()
 fout.close()
 if not PY2:
-output = output.decode()
+output = output
 
 version = re_version.match(output)
 
@@ -59,7 +59,7 @@ else:
 # IM >= 5.5.8 separates options for source and target files
 # See http://www.imagemagick.org/Usage/basics/#why
 if im or gm:
-sopts = "-depth 8"
+sopts = ""
 topts = ""
 elif sys.platform == 'darwin':
 command = 'lyxconvert'

Comparison python 2 vs python 3 (in lyx 2.4)

[José Abílio Matos]

While working on https://www.lyx.org/trac/ticket/11200

Riki has improved the lyx2lyx code in terms of performance.

Today I compared the time necessary to convert the big and slow lyx file, used 
in the trac report, using both python 2 and python 3. The difference in this 
case is a ~ 41% improvement when using python 3.6 when compared with python 
2.7.

This is interesting and not unexpected (I am aware of the issues of the double 
negative in English). Since we use unicode strings (as for us the encoding 
matters) we are seeing the benefits of almost 10 years of development after 
the release of python 2.7.

The initial releases of python 3 where slower than python 2.7 but release 
after release the performance has improved.

Nice work to all the involved in this effort. Without further thought I would 
like to thank to Georg, Enrico, Riki, Jürgen and others that I am forgetting 
now.

This is just a data point but impressive nevertheless. :-)

There is room for improvement, if necessary some of the workhorses of 
conversions like parser_tools.py can be converted to C for performance. But 
before doing that we need to have numbers from profiling. :-)

Regards,
-- 
José Abílio

Re: Python 3 as the default for 2.4

[Kornel Benko]

Am Samstag, 31. März 2018 00:25:00 CEST schrieb José Abílio Matos 
<jama...@lyx.org>:
> On Friday, 30 March 2018 20.21.53 WEST Kornel Benko wrote:
> > And we should distinguish usage of python at configure and build time,
> > from
> > the use at lyx-run-time.
> > 
> > Kornel
> 
> That is where I respectfully disagree. :-)
> 
> What you are suggesting is equivalent to release a lyx version with the
> documentation file format that is smaller than the current file format.
> Although it does work we never do that, before the release we always update
> the documentation to the file format of the released version.

Hm, yes, sort of. But in contrast to a provided new lyx with new doc-version, 
we do not provide a new python package together with lyx.

> The reason why I say this is similar to a blog that I read yesterday:
> "Is Python interpreted or compiled? Yes."
> https://nedbatchelder.com/blog/201803/is_python_interpreted_or_compiled_yes.
> html
> 
> When we install the python file we create the pyc files, and those files are
> specific to a given python version. If the code is read with another
> version we need to regenerate those files again.

I was not aware of this. If a package is created by cmake, then the installed 
does not contain any .pyc file. Why do we create .pyc in automake? I never 
suffered under execution times of python in lyx.

> With python 3 those files place in a directory called __pycache__. BTW one
> of the changes of python 3.7 (that is now at version beta) is to have
> reproducible builds for pyc files:
> https://docs.python.org/dev/whatsnew/3.7.html#hash-based-pycs
> 
> BTW the extreme case where the same python version is required for both
> build and runtime would be if one python module was linked with lyx c++
> code (say a common library that allows to read and interface directly with
> lyx data structures).

True. We do not require it, and so our python sources should be OK with 
respect to 2.7 and 3.3 version.

> The reason why I am being cautious is to have everyone understanding the
> implications of the move that I am proposing.
> 
> Thank you Kornel for this thoughtful email exchange. :-)

Thank you too.

Kornel



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

Re: Python 3 as the default for 2.4

[José Abílio Matos]

On Friday, 30 March 2018 20.21.53 WEST Kornel Benko wrote:
> And we should distinguish usage of python at configure and build time, from
> the use at lyx-run-time.
> 
> Kornel

That is where I respectfully disagree. :-)

What you are suggesting is equivalent to release a lyx version with the 
documentation file 
format that is smaller than the current file format. Although it does work we 
never do that, 
before the release we always update the documentation to the file format of the 
released 
version.

The reason why I say this is similar to a blog that I read yesterday:
"Is Python interpreted or compiled? Yes."
https://nedbatchelder.com/blog/201803/is_python_interpreted_or_compiled_yes.html

When we install the python file we create the pyc files, and those files are 
specific to a given 
python version. If the code is read with another version we need to regenerate 
those files again.

With python 3 those files place in a directory called __pycache__. BTW one of 
the changes of 
python 3.7 (that is now at version beta) is to have reproducible builds for pyc 
files:
https://docs.python.org/dev/whatsnew/3.7.html#hash-based-pycs

BTW the extreme case where the same python version is required for both build 
and runtime 
would be if one python module was linked with lyx c++ code (say a common 
library that allows 
to read and interface directly with lyx data structures).

The reason why I am being cautious is to have everyone understanding the 
implications of the 
move that I am proposing.

Thank you Kornel for this thoughtful email exchange. :-)
-- 
José Abílio

Re: Python 3 as the default for 2.4

[Kornel Benko]

Am Freitag, 30. März 2018 21:19:43 CEST schrieb Kornel Benko :
> Am Freitag, 30. März 2018 20:07:38 CEST schrieb José Abílio Matos
> 
> :
> > On Friday, 30 March 2018 19.59.13 WEST Kornel Benko wrote:
> > > No, I think you are wrong.
> > > CmakeLists.txt:760
> > > starts with
> > > 
> > > find_package(PythonInterp 3.3 QUIET)
> > > 
> > > If python3 is found, it is used as ${LYX_PYTHON_EXECUTABLE} from then
> > > on.
> > 
> > I was referring to src/support/os.cpp function python:
> > string const python(bool reset)
> > {
> > 
> > // Check whether the first python in PATH is the right one.
> > static string command = python23("python -tt");
> > // FIXME THREAD
> > if (reset) {
> > 
> > command = python23("python -tt");
> > 
> > }
> > 
> > ...
> > 
> > This function always tests for python...
> > 
> > I admit that I can be wrong though. :-)
> 
> But that has nothing to do with cmake. My 2 cents.
> 

And we should distinguish usage of python at configure and build time, from the 
use at lyx-run-time.

Kornel



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

Re: Python 3 as the default for 2.4

[Kornel Benko]

Am Freitag, 30. März 2018 20:07:38 CEST schrieb José Abílio Matos 
:
> On Friday, 30 March 2018 19.59.13 WEST Kornel Benko wrote:
> > No, I think you are wrong.
> > CmakeLists.txt:760
> > starts with
> > 
> > find_package(PythonInterp 3.3 QUIET)
> > 
> > If python3 is found, it is used as ${LYX_PYTHON_EXECUTABLE} from then on.
> 
> I was referring to src/support/os.cpp function python:
> string const python(bool reset)
> {
> // Check whether the first python in PATH is the right one.
> static string command = python23("python -tt");
> // FIXME THREAD
> if (reset) {
> command = python23("python -tt");
> }
> ...
> 
> This function always tests for python...
> 
> I admit that I can be wrong though. :-)

But that has nothing to do with cmake. My 2 cents.

Kornel



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

Re: Python 3 as the default for 2.4

[José Abílio Matos]

On Friday, 30 March 2018 19.59.13 WEST Kornel Benko wrote:
> No, I think you are wrong.
> CmakeLists.txt:760
> starts with
> find_package(PythonInterp 3.3 QUIET)
> If python3 is found, it is used as ${LYX_PYTHON_EXECUTABLE} from then on.

I was referring to src/support/os.cpp function python:
string const python(bool reset)
{
// Check whether the first python in PATH is the right one.
static string command = python23("python -tt");
// FIXME THREAD
if (reset) {
command = python23("python -tt");
}
...

This function always tests for python...

I admit that I can be wrong though. :-)
-- 
José Abílio

Re: Python 3 as the default for 2.4

[Kornel Benko]

Am Freitag, 30. März 2018 19:38:28 CEST schrieb José Abílio Matos 
<jama...@lyx.org>:
> On Tuesday, 27 March 2018 10.29.31 WEST Kornel Benko wrote:
> > On cmake build the default is already python3.
> 
> True but then, if I read the code correctly, lyx will pick the language
> called python that only on Arch (linux) is python 3, for all other cases
> (in linux and other OSs) python refers to python 2.

No, I think you are wrong.
CmakeLists.txt:760
starts with
find_package(PythonInterp 3.3 QUIET)
If python3 is found, it is used as ${LYX_PYTHON_EXECUTABLE} from then on.

> The issue was that we could assume that python was always available, it
> is by default on most (all) linux distribution as it is on Mac OS, for
> Windows the installer bundles it so it always worked. :-)

Kornel


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

Re: Python 3 as the default for 2.4

[José Abílio Matos]

On Tuesday, 27 March 2018 10.29.31 WEST Kornel Benko wrote:
> On cmake build the default is already python3.

True but then, if I read the code correctly, lyx will pick the language called 
python that only on Arch (linux) is python 3, for all other cases (in linux 
and other OSs) python refers to python 2.

The issue was that we could assume that python was always available, it 
is by default on most (all) linux distribution as it is on Mac OS, for 
Windows the installer bundles it so it always worked. :-)

-- 
José Abílio

Re: Python 3 as the default for 2.4

[José Abílio Matos]

On Tuesday, 27 March 2018 10.45.10 WEST Jean-Marc Lasgouttes wrote:
> I am OK with that. Even Ubuntu 14.04 has python 3.4.
> 
> JMarc

FWIW the reasons are the following:

 * we require version 3.3 because we use the u"" prefix in several places, that 
was not 
supported in previous versions of python 3;

 * python 3.4 does not have (on purpose) any syntactic difference from python 
3.3, the 
development cycle was used to improve the tools for the conversion, and 
interoperability, 
between python 2 and python 3.
There is one new library that is interesting to use in our code `enum`.
https://docs.python.org/3/whatsnew/3.4.html

 * one of the features that introduced in python 3.5 that was not available in 
previous python 3 
version is the interpolation operator for bytes, as opposed to strings where it 
always worked: 
e.g. b"%d" % 5 would not work for python 3.0-3.4.
https://docs.python.org/3.5/whatsnew/3.5.html

Because of the last point I am not sure if actually now we only support python 
3.5+. During the 
2.3 development cycle I have used python exclusively but then I was using 
python 3.6 so I 
would not catch any problem with the previous versions.

So what I will do now is to force the use of python3, we can adapt cmake and 
autotools later if 
we decide to also support python 2.7.

The issue here is if we remove the support for python 2 in lyx 2.4 or the next 
stable release 
(2.5?). In my humble opinion we can remove it now since all the platforms that 
we care have 
python 3 available for a long time and in 1.5 years python 2 will cease to be 
supported even in 
terms of security releases.
-- 
José Abílio

Re: Python 3 as the default for 2.4

[Jean-Marc Lasgouttes]

Le 26/03/2018 à 23:31, José Abílio Matos a écrit :

Hi,

I intend to apply a patch that makes python3 the default for lyx 2.4.

The core of the change is to move all calls to python to use the python3 
name. That should work everywhere.


Eventually we should even ignore python 2 and go python 3, only, for 
2.4. In the time frame of 2.4 python 2.7 will be reach the the EOL stage 
with no more updates not even security.


I propose to use as the minimum version python 3.4 (that was initially 
released almost 4 years ago):


I am OK with that. Even Ubuntu 14.04 has python 3.4.

JMarc

Re: Python 3 as the default for 2.4

[Kornel Benko]

Am Montag, 26. März 2018 22:31:24 CEST schrieb José Abílio Matos 
<jama...@lyx.org>:
> Hi,
>   I intend to apply a patch that makes python3 the default for lyx 2.4.
> The core of the change is to move all calls to python to use the python3
> name. That should work everywhere.

On cmake build the default is already python3.

> Eventually we should even ignore python 2 and go python 3, only, for 2.4. In
> the time frame of 2.4 python 2.7 will be reach the the EOL stage with no
> more updates not even security.
> 
> I propose to use as the minimum version python 3.4 (that was initially
> released almost 4 years ago):
> https://www.python.org/dev/peps/pep-0429/
> 
> What do others think?

Cmake build tries with version 3.3 first. 3.4 is OK IMHO.

Kornel



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

Python 3 as the default for 2.4

[José Abílio Matos]

Hi,
I intend to apply a patch that makes python3 the default for lyx 2.4.
The core of the change is to move all calls to python to use the python3 name. 
That should work everywhere.

Eventually we should even ignore python 2 and go python 3, only, for 2.4. In 
the 
time frame of 2.4 python 2.7 will be reach the the EOL stage with no more 
updates not even security.

I propose to use as the minimum version python 3.4 (that was initially released 
almost 4 years ago): 
https://www.python.org/dev/peps/pep-0429/

What do others think?
-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[Enrico Forestieri]

On Mon, Apr 10, 2017 at 03:07:34PM +0200, Jean-Marc Lasgouttes wrote:

> Le 10/04/2017 à 12:27, José Abílio Matos a écrit :
> > Since this fixes a bug I think that it should be committed.
> > For the final version I intend to uniform all the changes that have been 
> > done
> > to support python 2 and 3 to make the code more maintainable.
> 
> OK, I did that.

Thanks. Short on time lately.

-- 
Enrico

Re: [patch] Re: LyX master still not ready for Python 3

[Jean-Marc Lasgouttes]

Le 10/04/2017 à 12:27, José Abílio Matos a écrit :

Since this fixes a bug I think that it should be committed.
For the final version I intend to uniform all the changes that have been done
to support python 2 and 3 to make the code more maintainable.


OK, I did that.

JMarc

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Monday, 10 April 2017 11.02.21 WEST Jean-Marc Lasgouttes wrote:
> As I wrote, it fixes my problem. Do you want me to apply it, or are
> there reasons to hold it?
> 
> JMarc

Since this fixes a bug I think that it should be committed.
For the final version I intend to uniform all the changes that have been done 
to support python 2 and 3 to make the code more maintainable.
-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[Jean-Marc Lasgouttes]

Le 05/04/2017 à 22:08, Enrico Forestieri a écrit :

Most probably you have some non-ascii characters in a \DeclareLaTeXClass
line in some of your layout files. Now those files are explicitly read as
utf-8 encoded. If this is so, the attached patch should help.

Another consequence of the recent changes is that if someone has old
layouts containing latin1 characters then configure will now misteriously
fail.


As I wrote, it fixes my problem. Do you want me to apply it, or are 
there reasons to hold it?


JMarc

Re: [patch] Re: LyX master still not ready for Python 3

[Jean-Marc Lasgouttes]

Le 05/04/2017 à 22:08, Enrico Forestieri a écrit :

Most probably you have some non-ascii characters in a \DeclareLaTeXClass
line in some of your layout files. Now those files are explicitly read as
utf-8 encoded.


I do have UTF-8 encoded layouts.


If this is so, the attached patch should help.


It does, thanks.

JMarc

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 5 April 2017 21.08.09 WEST Enrico Forestieri wrote:
> Most probably you have some non-ascii characters in a \DeclareLaTeXClass
> line in some of your layout files. Now those files are explicitly read as
> utf-8 encoded. If this is so, the attached patch should help.

It should be something like that since I do not get any error when running 
with python 2.7.13.

A conditional change based on what Enrico showed (open for python 2 and 
io.open) will make the code work for python 2 but the same problem then 
remains for python 3...

What needs to be done is to see if all the operations done on those files can 
be done as bytes (binary files) and not as strings (text files). For some of 
those cases the change should be easy.
-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 5 April 2017 21.48.21 WEST Uwe Stöhr wrote:
> El 05.04.2017 a las 22:08, Enrico Forestieri escribió:
> > Most probably you have some non-ascii characters in a \DeclareLaTeXClass
> > line in some of your layout files. Now those files are explicitly read as
> > utf-8 encoded. If this is so, the attached patch should help.
> 
> Yes. This is necessary. Moreover all open() commands must replaced by
> io.open() to assure that we use the right encoding.

In the cases were we need to care. And with python3 the distinction is more 
present since the default strings have an encoding associated (they are 
unicode) while for python2 that is not true.
 
> However, I am not very familiar with Python. I only acted because after
> José's commits I could no longer even start LyX.

Actually my commits were unrelated to the problems you described. :-)

> > Another consequence of the recent changes is that if someone has old
> > layouts containing latin1 characters then configure will now misteriously
> > fail.
> 
> I thought layout2layout takes care of this. If not, then this is
> necessary to add this feature for LyX 2.3.

I agree. I would expect for our files to have the same encoding after lyx 1.6 
(utf-8).

> regards Uwe


-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 5 April 2017 09.38.24 WEST Kornel Benko wrote:
> ATM cmake(lyx) checks for python >= 2.7.

I stand corrected then. :-)

Thank you Kornel.

-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[Uwe Stöhr]

El 05.04.2017 a las 22:08, Enrico Forestieri escribió:


Most probably you have some non-ascii characters in a \DeclareLaTeXClass
line in some of your layout files. Now those files are explicitly read as
utf-8 encoded. If this is so, the attached patch should help.


Yes. This is necessary. Moreover all open() commands must replaced by 
io.open() to assure that we use the right encoding.


However, I am not very familiar with Python. I only acted because after 
José's commits I could no longer even start LyX.



Another consequence of the recent changes is that if someone has old
layouts containing latin1 characters then configure will now misteriously
fail.


I thought layout2layout takes care of this. If not, then this is 
necessary to add this feature for LyX 2.3.


regards Uwe

Re: [patch] Re: LyX master still not ready for Python 3

[Enrico Forestieri]

On Wed, Apr 05, 2017 at 02:01:36PM +0200, Jean-Marc Lasgouttes wrote:
> 
> I am not sure what the status is, but with latest version I get the
> following from configure.py:
> 
> Traceback (most recent call last):
>   File "/home/local/lasgoutt/lyx/master/lib/configure.py", line 1825, in
> 
> ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
>   File "/home/local/lasgoutt/lyx/master/lib/configure.py", line 1379, in
> checkLatexConfig
> cl.write(line + '\n')
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position
> 82: ordinal not in range(128)
> support/Systemcall.cpp (295): Systemcall: 'python -tt
> "/home/local/lasgoutt/lyx/master/lib/configure.py"
> --with-version-suffix=-master
> --binary-dir="/home/local/lasgoutt/lyx/devbuild/src/"' finished with exit
> code 1
> 
> This is with my oldish python 2.7.3.

Most probably you have some non-ascii characters in a \DeclareLaTeXClass
line in some of your layout files. Now those files are explicitly read as
utf-8 encoded. If this is so, the attached patch should help.

Another consequence of the recent changes is that if someone has old
layouts containing latin1 characters then configure will now misteriously
fail.

-- 
Enrico
diff --git a/lib/configure.py b/lib/configure.py
index be47cea..bdd825f 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1374,7 +1374,7 @@ def checkLatexConfig(check_config, bool_docbook):
 if nodeclaration:
 continue
 testclasses.sort()
-cl = open('chklayouts.tex', 'w')
+cl = io.open('chklayouts.tex', 'w', encoding=enco)
 for line in testclasses:
 cl.write(line + '\n')
 cl.close()

Re: [patch] Re: LyX master still not ready for Python 3

[Jean-Marc Lasgouttes]

Le 04/04/2017 à 21:01, José Abílio Matos a écrit :

On Sunday, 2 April 2017 13.40.05 WEST Uwe Stöhr wrote:

- the file was opened without the correct encoding. Since nothing was
give, utf8 was used. That failed because on Windows it is in cp1252. In
my patch I use io.open which works with Python 2.6 and 2.7. I think we
don't need to support also older Python versions.

regards Uwe


I had arrived to some of your conclusion. I had committed some code that I
have only a few seconds later realized that was already in your patch. My bad.
:-)



I am not sure what the status is, but with latest version I get the 
following from configure.py:


Traceback (most recent call last):
  File "/home/local/lasgoutt/lyx/master/lib/configure.py", line 1825, 
in 

ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook)
  File "/home/local/lasgoutt/lyx/master/lib/configure.py", line 1379, 
in checkLatexConfig

cl.write(line + '\n')
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in 
position 82: ordinal not in range(128)
support/Systemcall.cpp (295): Systemcall: 'python -tt 
"/home/local/lasgoutt/lyx/master/lib/configure.py" 
--with-version-suffix=-master 
--binary-dir="/home/local/lasgoutt/lyx/devbuild/src/"' finished with 
exit code 1


This is with my oldish python 2.7.3.

JMarc

Re: [patch] Re: LyX master still not ready for Python 3

[Kornel Benko]

Am Dienstag, 4. April 2017 um 23:14:22, schrieb José Abílio Matos 

> On Tuesday, 4 April 2017 21.43.58 WEST Uwe Stöhr wrote:
> > Hi José,
> > 
> > many thanks for having a look.
> > 
> > Why CMake 2.6? That was released 9 years (sic!) ago. Using it is a
> > potential security issue. i am wondering if people still use this.
> > 
> > In my opinion we should rely on CMake 2.8, released 7 years ago
> > 
> > I also think we should only need to support Python 2.7 for the same
> > reason. Python 2.6 was also released 9 years ago, Python 2.7 was
> > released 7 years ago. This is already a lot of time.
> 
> I am sorry what I meant is that cmake checks for python >= 2.6.

ATM cmake(lyx) checks for python >= 2.7.

> Or at least that in development/LyXPackaging.cmake we can find the following 
> lines:
> 
> # We depend on python scripting
> set(CPACK_DEBIAN_PACKAGE_DEPENDS "python (>= 2.6)")

This is valid for cpack routines only. Used for installations through the 
debian package manager.

> Regards,

Kornel

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

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Tuesday, 4 April 2017 21.43.58 WEST Uwe Stöhr wrote:
> Hi José,
> 
> many thanks for having a look.
> 
> Why CMake 2.6? That was released 9 years (sic!) ago. Using it is a
> potential security issue. i am wondering if people still use this.
> 
> In my opinion we should rely on CMake 2.8, released 7 years ago
> 
> I also think we should only need to support Python 2.7 for the same
> reason. Python 2.6 was also released 9 years ago, Python 2.7 was
> released 7 years ago. This is already a lot of time.

I am sorry what I meant is that cmake checks for python >= 2.6.

Or at least that in development/LyXPackaging.cmake we can find the following 
lines:

# We depend on python scripting
set(CPACK_DEBIAN_PACKAGE_DEPENDS "python (>= 2.6)")

Regards,
-- 
José Abílio

Re: [patch] Re: LyX master still not ready for Python 3

[Uwe Stöhr]

El 04.04.2017 a las 21:01, José Abílio Matos escribió:


Regarding the support for older versions of python 2 we already test both
using the autotools ( >= 2.7.0 ) and cmake (>= 2.6).


Hi José,

many thanks for having a look.

Why CMake 2.6? That was released 9 years (sic!) ago. Using it is a 
potential security issue. i am wondering if people still use this.


In my opinion we should rely on CMake 2.8, released 7 years ago

I also think we should only need to support Python 2.7 for the same 
reason. Python 2.6 was also released 9 years ago, Python 2.7 was 
released 7 years ago. This is already a lot of time.



I think that we should use an uniform requirement.


Yes, but I vote for CMake 2.8 and python 2.7.


So, please, commit your patch.


done.

regards Uwe

Re: [patch] Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Sunday, 2 April 2017 13.40.05 WEST Uwe Stöhr wrote:
> - the file was opened without the correct encoding. Since nothing was
> give, utf8 was used. That failed because on Windows it is in cp1252. In
> my patch I use io.open which works with Python 2.6 and 2.7. I think we
> don't need to support also older Python versions.
> 
> regards Uwe

I had arrived to some of your conclusion. I had committed some code that I 
have only a few seconds later realized that was already in your patch. My bad. 
:-)

Regarding the support for older versions of python 2 we already test both 
using the autotools ( >= 2.7.0 ) and cmake (>= 2.6).

So that that is not a problem.

I think that we should use an uniform requirement.

python 2.6 can probably work, and python 2.7 works surely.

So, please, commit your patch.

Regards,
-- 
José Abílio

[patch] Re: LyX master still not ready for Python 3

[Uwe Stöhr]

Am 02.04.2017 um 14:07 schrieb Uwe Stöhr:


I don't know enough about Python and cannot provide a patch.


Well, the attached patch fixes the problem for me. It works with Python 
2 and 3.


There were 2 problems:

- the explicit encoding made the string a byte-like object in which we 
cannot use .replace()


- the file was opened without the correct encoding. Since nothing was 
give, utf8 was used. That failed because on Windows it is in cp1252. In 
my patch I use io.open which works with Python 2.6 and 2.7. I think we 
don't need to support also older Python versions.


regards Uwe
diff --git 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-ccfbfda.001.py"
 "b/D:\\LyXGit\\Master\\lib\\configure.py"
index aae6a85990..be47cea7a0 100644
--- 
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\configure-ccfbfda.001.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -9,7 +9,7 @@
 # Full author contact details are available in file CREDITS.
 
 from __future__ import print_function
-import glob, logging, os, re, shutil, subprocess, sys, stat
+import glob, logging, os, re, shutil, subprocess, sys, stat, io
 
 # set up logging
 logging.basicConfig(level = logging.DEBUG,
@@ -200,12 +200,12 @@ def checkTeXPaths():
 if sys.version_info[0] < 3:
 inpname = shortPath(unicode(tmpfname, encoding)).replace('\\', 
'/')
 else:
-inpname = shortPath(str(tmpfname, encoding)).replace('\\', '/')
+inpname = shortPath(tmpfname).replace('\\', '/') 
 else:
 inpname = cmdOutput('cygpath -m ' + tmpfname)
 logname = os.path.basename(re.sub("(?i).ltx", ".log", inpname))
 inpname = inpname.replace('~', '\\string~')
-os.write(fd, r'\relax')
+os.write(fd, b'\\relax')
 os.close(fd)
 latex_out = cmdOutput(r'latex 
"\nonstopmode\input{%s}\makeatletter\@@end"'
   % inpname)
@@ -1349,7 +1349,11 @@ def checkLatexConfig(check_config, bool_docbook):
 classname = file.split(os.sep)[-1].split('.')[0]
 decline = ""
 catline = ""
-for line in open(file).readlines():
+if os.name == 'nt':
+enco = sys.getfilesystemencoding()
+else:
+enco="utf8"
+for line in io.open(file, encoding=enco).readlines():
 if not empty.match(line) and line[0] != '#':
 if decline == "":
 logger.warning("Failed to find valid \Declare line "

Re: LyX master still not ready for Python 3

[Uwe Stöhr]

Am 30.03.2017 um 14:37 schrieb José Abílio Matos:


What about changing that line to:

os.write(fd, b'\\relax')

it should work for both versions, no?


No. This works for Python 2 but it does not fix the real problem I desribed:

inpname = shortPath(str(tmpfname, encoding)).replace('\\', '/')

failes because tmpfname is a byte-like object and no string.

As I also wrote Python 3 opens the file by default in binary mode. This 
is the bug, we must open it explicitly as text.


I don't know enough about Python and cannot provide a patch.

regards Uwe

Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 29 March 2017 23.09.23 WEST Uwe Stöhr wrote:
> And indeed by using i n line 208
> 
> os.write(fd, b'\relax')
> instead of
> os.write(fd, r'\relax')
> 
> I get with
> inpname = shortPath(str(tmpfname)).replace('\\', '/')
> no error. But then it will of course fail with Python 2.
> 
> regards Uwe

What about changing that line to:

os.write(fd, b'\\relax')

it should work for both versions, no?


r'\relax' just says not to escape the backslash char, so
r'\relax' is the same as '\\relax'.

Both python 2 and 3 accept the _b_ prefix for representing byte, it just 
happens that for python 2 this a no-op.


Regards,
-- 
José Abílio

Re: LyX master still not ready for Python 3

[Uwe Stöhr]

Am 29.03.2017 um 23:05 schrieb Uwe Stöhr:


('de_DE', 'cp1252')


OK, using

inpname = shortPath(str(tmpfname).encode(encoding)).replace('\\', '/')
or
inpname = shortPath(str(tmpfname).encode('cp1252')).replace('\\', '/')

gives this error:

TypeError: a bytes-like object is required, not 'str'

I googled this:
"
You are using Python 2 methodology instead of Python 3.
Change:
outfile=open('./immates.csv','wb')
To:
outfile=open('./immates.csv','w')
.
In Python 3 csv takes the input in text mode, whereas in Python 2 it 
took it in binary mode.

"

And indeed by using i n line 208

os.write(fd, b'\relax')
instead of
os.write(fd, r'\relax')

I get with
inpname = shortPath(str(tmpfname)).replace('\\', '/')
no error. But then it will of course fail with Python 2.

regards Uwe

Re: LyX master still not ready for Python 3

[Uwe Stöhr]

Am 29.03.2017 um 15:41 schrieb José Abílio Matos:


OK, I committed a change that should fix this problem.


Thanks José,

this does not fix the bug. I get still the same error message:

22:59:50.996:   File "D:/LyXGit/Master/lib/configure.py", line 1811, in 


22:59:50.999: windows_style_tex_paths = checkTeXPaths()
22:59:51.000:   File "D:/LyXGit/Master/lib/configure.py", line 203, in 
checkTeXPaths
22:59:51.003: inpname = shortPath(str(tmpfname, 
encoding)).replace('\\', '/')

22:59:51.004: TypeError: decoding str is not supported

> Could you, please, open a terminal/power shell to call directly
> python and then run:
> import locale
> locale.getdefaultlocale()
> I am interested in the output of the second line.

I get only one line of output. It is

('de_DE', 'cp1252')

Here is the complete content of the Python console:

D:\LyXGit\Master\compile-2015\bin\Release>python
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit 
(Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getdefaultlocale()
('de_DE', 'cp1252')
>>>

regards Uwe

Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 29 March 2017 18.24.26 WEST Enrico Forestieri wrote:
> On Wed, Mar 29, 2017 at 02:41:23PM +0100, José Abílio Matos wrote:
> > OK, I committed a change that should fix this problem.
> 
> I hope so ;)

When dealing with windows I always hope, after all hope is the last to die. 
:-)
 
> C:\python>python
> Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
> on win32 Type "help", "copyright", "credits" or "license" for more
> information.
> >>> import locale
> >>> locale.getdefaultlocale()
> 
> ('it_IT', 'cp1252')
> 
> >>> import sys
> >>> sys.getfilesystemencoding()
> 
> 'mbcs'
> 
> Hm?

multi-byte character set, I suspect that it means UTF-16 and not UCS2. :-)

> > Looking into that function I find it strange that we have to change the
> > path separators if it is windows... I would expect this to be
> > unnecessary...
> No, it is necessary because the path is going to be used in a latex file.

OK, that makes sense.
 
> > I hope that this works.
> 
> Let's see...

I am a man of faith.

-- 
José Abílio

Re: LyX master still not ready for Python 3

[Enrico Forestieri]

On Wed, Mar 29, 2017 at 02:41:23PM +0100, José Abílio Matos wrote:
> 
> OK, I committed a change that should fix this problem.

I hope so ;)

C:\python>python
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getdefaultlocale()
('it_IT', 'cp1252')
>>> import sys
>>> sys.getfilesystemencoding()
'mbcs'

Hm?

> Looking into that function I find it strange that we have to change the path 
> separators if it is windows... I would expect this to be unnecessary...

No, it is necessary because the path is going to be used in a latex file.

> I hope that this works.

Let's see...

-- 
Enrico

Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 29 March 2017 01.12.06 WEST Uwe Stöhr wrote:
> As requested by José, I installed Python 3.6.1 and tested today's master
> with it. As result LyX cannot be started because the reconfiguration fails:
> 
> 02:05:53.187: Checking whether TeX allows spaces in file names... yes
> 02:05:53.188: Traceback (most recent call last):
> 02:05:53.189:   File "D:/LyXGit/Master/lib/configure.py", line 1814, in
> 
> 02:05:53.192: windows_style_tex_paths = checkTeXPaths()
> 02:05:53.193:   File "D:/LyXGit/Master/lib/configure.py", line 206, in
> checkTeXPaths
> 02:05:53.194: inpname = shortPath(str(tmpfname,
> encoding)).replace('\\', '/')
> 02:05:53.196: TypeError: decoding str is not supported
> 02:05:53.198: configuration will be reloaded...
> D:\LyXGit\Master\src\support\Systemcall.cpp (295): Systemcall: 'python
> -tt "D:/LyXGit/Master/lib/configure.py"
> --binary-dir="D:/LyXGit/Master/compile-2015/bin/Release/"' finished with
> exit code 1
> 
> regards Uwe

OK, I committed a change that should fix this problem.

Looking into that function I find it strange that we have to change the path 
separators if it is windows... I would expect this to be unnecessary...

I hope that this works.

Regards,
-- 
José Abílio

Re: LyX master still not ready for Python 3

[José Abílio Matos]

On Wednesday, 29 March 2017 01.12.06 WEST Uwe Stöhr wrote:
> As requested by José, I installed Python 3.6.1 and tested today's master
> with it. As result LyX cannot be started because the reconfiguration fails:
> 
> 02:05:53.187: Checking whether TeX allows spaces in file names... yes
> 02:05:53.188: Traceback (most recent call last):
> 02:05:53.189:   File "D:/LyXGit/Master/lib/configure.py", line 1814, in
> 
> 02:05:53.192: windows_style_tex_paths = checkTeXPaths()
> 02:05:53.193:   File "D:/LyXGit/Master/lib/configure.py", line 206, in
> checkTeXPaths
> 02:05:53.194: inpname = shortPath(str(tmpfname,
> encoding)).replace('\\', '/')
> 02:05:53.196: TypeError: decoding str is not supported
> 02:05:53.198: configuration will be reloaded...
> D:\LyXGit\Master\src\support\Systemcall.cpp (295): Systemcall: 'python
> -tt "D:/LyXGit/Master/lib/configure.py"
> --binary-dir="D:/LyXGit/Master/compile-2015/bin/Release/"' finished with
> exit code 1
> 
> regards Uwe

Could you, please, open a terminal/power shell to call directly python and 
then run:

import locale
locale.getdefaultlocale()

I am interested in the output of the second line.

It should be something like, I am guessing here,
('de_DE', 'cp1252') 

but in this case since there is an error I suspect that the outcome is

(None, None)

FWIW in Fedora 25 I get

(None, None) for python 2

and

('en_US', 'UTF-8') for python 3 # the correct answer is this case. :-)

Regards,
-- 
José Abílio

LyX master still not ready for Python 3

[Uwe Stöhr]

As requested by José, I installed Python 3.6.1 and tested today's master 
with it. As result LyX cannot be started because the reconfiguration fails:


02:05:53.187: Checking whether TeX allows spaces in file names... yes
02:05:53.188: Traceback (most recent call last):
02:05:53.189:   File "D:/LyXGit/Master/lib/configure.py", line 1814, in 


02:05:53.192: windows_style_tex_paths = checkTeXPaths()
02:05:53.193:   File "D:/LyXGit/Master/lib/configure.py", line 206, in 
checkTeXPaths
02:05:53.194: inpname = shortPath(str(tmpfname, 
encoding)).replace('\\', '/')

02:05:53.196: TypeError: decoding str is not supported
02:05:53.198: configuration will be reloaded...
D:\LyXGit\Master\src\support\Systemcall.cpp (295): Systemcall: 'python 
-tt "D:/LyXGit/Master/lib/configure.py" 
--binary-dir="D:/LyXGit/Master/compile-2015/bin/Release/"' finished with 
exit code 1


regards Uwe

Re: Python 3 incompatibilities still exist right?

[Guenter Milde]

On 2015-10-14, Scott Kostyshak wrote:
> On Fri, Dec 19, 2014 at 11:26:35AM -0500, Scott Kostyshak wrote:
>> On Fri, Dec 19, 2014 at 4:40 AM, Benjamin Piwowarski <bpiwo...@lyx.org> 
>> wrote:

...

>> > sorry for the long delay - I started to clean up python scripts to
>> > make them compatible with both python 2 and 3 so there are no more
>> > issues with this. I was stopped by lack of time but will start to
>> > look at that again - it is not such a big amount of work.


Could we speed up things by (at least temporarily) providing Python 3 vs.
Py 2 versions of the scripts and a wrapper script that selects the
correct version depending on sys.version_info?

The Python 3 version might be generated semi-automatically using 2to3.

Günter

Re: Python 3 incompatibilities still exist right?

[Scott Kostyshak]

On Fri, Dec 19, 2014 at 11:26:35AM -0500, Scott Kostyshak wrote:
> On Fri, Dec 19, 2014 at 4:40 AM, Benjamin Piwowarski <bpiwo...@lyx.org> wrote:
> > Hi to all,
> >
> > sorry for the long delay - I started to clean up python scripts to make them
> > compatible with both python 2 and 3 so there are no more issues with this. I
> > was stopped by lack of time but will start to look at that again - it is not
> > such a big amount of work.
> >
> > Benjamin
> 
> Thanks for the update, Benjamin.
> 
> Can you please remember to update RELEASE-NOTES in the master branch
> when this work is completed (perhaps on the final commit that fixes
> compatibility issues)? Or if you prefer, let me know and I can do it.
> Thanks for doing this work.
> 
> Scott

Can someone (Richard, José, Benjamin?) please suggest an updated message
for our RELEASE-NOTES? The current item is:

* LyX needs to be run under Python 2 and will not work properly on systems
  where Python 3 is the default binary. See bug #7030 to know how to fix
  this properly, since simple shebang conversion in *.py files will not
  be enough.

Please make the change yourself or respond to this email with the message and I
will copy/paste to make the change.

Scott

Re: Python 3 incompatibilities still exist right?

[Benjamin Piwowarski]

Hi to all,

sorry for the long delay - I started to clean up python scripts to make
them compatible with both python 2 and 3 so there are no more issues with
this. I was stopped by lack of time but will start to look at that again -
it is not such a big amount of work.

Benjamin

On Fri, Nov 21, 2014 at 8:05 PM, Georg Baum georg.b...@post.rwth-aachen.de
wrote:

 Richard Heck wrote:

  It might be possible to specify the full path to the python version you
  want to use in
  the relevant converter definition. But I am not sure.

 This is possible. The magic happens only for python -tt. Even specifying
 only python3 or python3 -tt as the interpreter for self defined
 converters should work, if python3 is in the path. If it does not, please
 report a bug, this can probably be fixed easily.


 Georg

Re: Re: Python 3 incompatibilities still exist right?

[José Matos]

On Friday 19 December 2014 10:40:00 Benjamin Piwowarski wrote:
 Hi to all,
 
 sorry for the long delay - I started to clean up python scripts to make
 them compatible with both python 2 and 3 so there are no more issues with
 this. I was stopped by lack of time but will start to look at that again -
 it is not such a big amount of work.
 
 Benjamin

Hi,
have you seen the updated version of the porting guide 
https://docs.python.org/3/howto/pyporting.html

There are some interesting tidbits there that make our task doable 
without too much hassle.

Regards,
-- 
José Abílio

Re: Python 3 incompatibilities still exist right?

[Scott Kostyshak]

On Fri, Dec 19, 2014 at 4:40 AM, Benjamin Piwowarski bpiwo...@lyx.org wrote:
 Hi to all,

 sorry for the long delay - I started to clean up python scripts to make them
 compatible with both python 2 and 3 so there are no more issues with this. I
 was stopped by lack of time but will start to look at that again - it is not
 such a big amount of work.

 Benjamin

Thanks for the update, Benjamin.

Can you please remember to update RELEASE-NOTES in the master branch
when this work is completed (perhaps on the final commit that fixes
compatibility issues)? Or if you prefer, let me know and I can do it.
Thanks for doing this work.

Scott

Re: Python 3 incompatibilities still exist right?

[Benjamin Piwowarski]

Hi to all,

sorry for the long delay - I started to clean up python scripts to make
them compatible with both python 2 and 3 so there are no more issues with
this. I was stopped by lack of time but will start to look at that again -
it is not such a big amount of work.

Benjamin

On Fri, Nov 21, 2014 at 8:05 PM, Georg Baum 
wrote:
>
> Richard Heck wrote:
>
> > It might be possible to specify the full path to the python version you
> > want to use in
> > the relevant converter definition. But I am not sure.
>
> This is possible. The magic happens only for "python -tt". Even specifying
> only "python3" or "python3 -tt" as the interpreter for self defined
> converters should work, if python3 is in the path. If it does not, please
> report a bug, this can probably be fixed easily.
>
>
> Georg
>
>

Re: Re: Python 3 incompatibilities still exist right?

[José Matos]

On Friday 19 December 2014 10:40:00 Benjamin Piwowarski wrote:
> Hi to all,
> 
> sorry for the long delay - I started to clean up python scripts to make
> them compatible with both python 2 and 3 so there are no more issues with
> this. I was stopped by lack of time but will start to look at that again -
> it is not such a big amount of work.
> 
> Benjamin

Hi,
have you seen the updated version of the porting guide 
https://docs.python.org/3/howto/pyporting.html

There are some interesting tidbits there that make our task doable 
without too much hassle.

Regards,
-- 
José Abílio

Re: Python 3 incompatibilities still exist right?

[Scott Kostyshak]

On Fri, Dec 19, 2014 at 4:40 AM, Benjamin Piwowarski  wrote:
> Hi to all,
>
> sorry for the long delay - I started to clean up python scripts to make them
> compatible with both python 2 and 3 so there are no more issues with this. I
> was stopped by lack of time but will start to look at that again - it is not
> such a big amount of work.
>
> Benjamin

Thanks for the update, Benjamin.

Can you please remember to update RELEASE-NOTES in the master branch
when this work is completed (perhaps on the final commit that fixes
compatibility issues)? Or if you prefer, let me know and I can do it.
Thanks for doing this work.

Scott

Re: Python 3 incompatibilities still exist right?

[Alex Vergara Gil]

Ok, let me be splicit. I use extensively Spyder with python 3 for my
work, I use also LyX to write my articles. When I installed LyX (on
windows) it uses its own bundled python2 and it works fine. The
problem arises when I want to import my python graphics into LyX,
which should be interpreted with python3, I try putting python3 into
LyX and then LyX stops working at all!! it doesn't reconfigure
anymore, and when I try to start it, it crashes with a big failure. So
I am forced to produce python2 only graphics.

to reference this is the article in which I show how to add python
graphics within LyX
http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics

Re: Python 3 incompatibilities still exist right?

[Richard Heck]

On 11/21/2014 08:25 AM, Alex Vergara Gil wrote:

Ok, let me be splicit. I use extensively Spyder with python 3 for my
work, I use also LyX to write my articles. When I installed LyX (on
windows) it uses its own bundled python2 and it works fine. The
problem arises when I want to import my python graphics into LyX,
which should be interpreted with python3, I try putting python3 into
LyX and then LyX stops working at all!! it doesn't reconfigure
anymore, and when I try to start it, it crashes with a big failure. So
I am forced to produce python2 only graphics.


Yes, that is what I would expect.


to reference this is the article in which I show how to add python
graphics within LyX
http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics


It might be possible to specify the full path to the python version you 
want to use in

the relevant converter definition. But I am not sure.

Richard

Re: Python 3 incompatibilities still exist right?

[Kornel Benko]

Am Freitag, 21. November 2014 um 08:55:25, schrieb Richard Heck rgh...@lyx.org
 On 11/21/2014 08:25 AM, Alex Vergara Gil wrote:
  Ok, let me be splicit. I use extensively Spyder with python 3 for my
  work, I use also LyX to write my articles. When I installed LyX (on
  windows) it uses its own bundled python2 and it works fine. The
  problem arises when I want to import my python graphics into LyX,
  which should be interpreted with python3, I try putting python3 into
  LyX and then LyX stops working at all!! it doesn't reconfigure
  anymore, and when I try to start it, it crashes with a big failure. So
  I am forced to produce python2 only graphics.
 
 Yes, that is what I would expect.
 
  to reference this is the article in which I show how to add python
  graphics within LyX
  http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics
 
 It might be possible to specify the full path to the python version you 
 want to use in
 the relevant converter definition. But I am not sure.
 
 Richard

We use hard-coded strings for python calls.
Examples:
./src/support/ForkedCalls.cpp:308
./src/support/Systemcall.cpp:170
./src/support/filetools.cpp:410
./src/graphics/GraphicsConverter.cpp:276

so that full path is not helpfull. On unix I can make a symbolic link
e.g.
# ln -s /usr/bin/python3 $HOME/bin/python
and lyx is still working. ($HOME/bin is at the beginning of my path)

Something similar should be possible for windows too.

Kornel

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

Re: Python 3 incompatibilities still exist right?

[Richard Heck]

On 11/21/2014 09:23 AM, Kornel Benko wrote:

Am Freitag, 21. November 2014 um 08:55:25, schrieb Richard Heck rgh...@lyx.org

On 11/21/2014 08:25 AM, Alex Vergara Gil wrote:

Ok, let me be splicit. I use extensively Spyder with python 3 for my
work, I use also LyX to write my articles. When I installed LyX (on
windows) it uses its own bundled python2 and it works fine. The
problem arises when I want to import my python graphics into LyX,
which should be interpreted with python3, I try putting python3 into
LyX and then LyX stops working at all!! it doesn't reconfigure
anymore, and when I try to start it, it crashes with a big failure. So
I am forced to produce python2 only graphics.

Yes, that is what I would expect.


to reference this is the article in which I show how to add python
graphics within LyX
http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics

It might be possible to specify the full path to the python version you
want to use in
the relevant converter definition. But I am not sure.

Richard

We use hard-coded strings for python calls.
Examples:
./src/support/ForkedCalls.cpp:308
./src/support/Systemcall.cpp:170
./src/support/filetools.cpp:410
./src/graphics/GraphicsConverter.cpp:276

so that full path is not helpfull.


It looks as if this is searching for python -tt at the beginning of 
the command,
and then replacing that with an explicit call to python2. So if one gave 
the full
path in a converter to python3, then it should work. Alternatively, one 
could

create a symbolic link to python3, with some other name, and call that.


On unix I can make a symbolic link e.g.
# ln -s /usr/bin/python3 $HOME/bin/python
and lyx is still working. ($HOME/bin is at the beginning of my path)


Confirmed (though on Linux, too).

Richard

Re: Python 3 incompatibilities still exist right?

[Georg Baum]

Richard Heck wrote:

 It might be possible to specify the full path to the python version you
 want to use in
 the relevant converter definition. But I am not sure.

This is possible. The magic happens only for python -tt. Even specifying 
only python3 or python3 -tt as the interpreter for self defined 
converters should work, if python3 is in the path. If it does not, please 
report a bug, this can probably be fixed easily.


Georg

Re: Python 3 incompatibilities still exist right?

[Alex Vergara Gil]

Ok, let me be splicit. I use extensively Spyder with python 3 for my
work, I use also LyX to write my articles. When I installed LyX (on
windows) it uses its own bundled python2 and it works fine. The
problem arises when I want to import my python graphics into LyX,
which should be interpreted with python3, I try putting python3 into
LyX and then LyX stops working at all!! it doesn't reconfigure
anymore, and when I try to start it, it crashes with a big failure. So
I am forced to produce python2 only graphics.

to reference this is the article in which I show how to add python
graphics within LyX>
http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics

Re: Python 3 incompatibilities still exist right?

[Richard Heck]

On 11/21/2014 08:25 AM, Alex Vergara Gil wrote:

Ok, let me be splicit. I use extensively Spyder with python 3 for my
work, I use also LyX to write my articles. When I installed LyX (on
windows) it uses its own bundled python2 and it works fine. The
problem arises when I want to import my python graphics into LyX,
which should be interpreted with python3, I try putting python3 into
LyX and then LyX stops working at all!! it doesn't reconfigure
anymore, and when I try to start it, it crashes with a big failure. So
I am forced to produce python2 only graphics.


Yes, that is what I would expect.


to reference this is the article in which I show how to add python
graphics within LyX>
http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics


It might be possible to specify the full path to the python version you 
want to use in

the relevant converter definition. But I am not sure.

Richard

Re: Python 3 incompatibilities still exist right?

[Kornel Benko]

Am Freitag, 21. November 2014 um 08:55:25, schrieb Richard Heck <rgh...@lyx.org>
> On 11/21/2014 08:25 AM, Alex Vergara Gil wrote:
> > Ok, let me be splicit. I use extensively Spyder with python 3 for my
> > work, I use also LyX to write my articles. When I installed LyX (on
> > windows) it uses its own bundled python2 and it works fine. The
> > problem arises when I want to import my python graphics into LyX,
> > which should be interpreted with python3, I try putting python3 into
> > LyX and then LyX stops working at all!! it doesn't reconfigure
> > anymore, and when I try to start it, it crashes with a big failure. So
> > I am forced to produce python2 only graphics.
> 
> Yes, that is what I would expect.
> 
> > to reference this is the article in which I show how to add python
> > graphics within LyX>
> > http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics
> 
> It might be possible to specify the full path to the python version you 
> want to use in
> the relevant converter definition. But I am not sure.
> 
> Richard

We use hard-coded strings for python calls.
Examples:
./src/support/ForkedCalls.cpp:308
./src/support/Systemcall.cpp:170
./src/support/filetools.cpp:410
./src/graphics/GraphicsConverter.cpp:276

so that full path is not helpfull. On unix I can make a symbolic link
e.g.
# ln -s /usr/bin/python3 $HOME/bin/python
and lyx is still working. ($HOME/bin is at the beginning of my path)

Something similar should be possible for windows too.

Kornel

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

Re: Python 3 incompatibilities still exist right?

[Richard Heck]

On 11/21/2014 09:23 AM, Kornel Benko wrote:

Am Freitag, 21. November 2014 um 08:55:25, schrieb Richard Heck <rgh...@lyx.org>

On 11/21/2014 08:25 AM, Alex Vergara Gil wrote:

Ok, let me be splicit. I use extensively Spyder with python 3 for my
work, I use also LyX to write my articles. When I installed LyX (on
windows) it uses its own bundled python2 and it works fine. The
problem arises when I want to import my python graphics into LyX,
which should be interpreted with python3, I try putting python3 into
LyX and then LyX stops working at all!! it doesn't reconfigure
anymore, and when I try to start it, it crashes with a big failure. So
I am forced to produce python2 only graphics.

Yes, that is what I would expect.


to reference this is the article in which I show how to add python
graphics within LyX>
http://article.gmane.org/gmane.editors.lyx.general/82745/match=python+graphics

It might be possible to specify the full path to the python version you
want to use in
the relevant converter definition. But I am not sure.

Richard

We use hard-coded strings for python calls.
Examples:
./src/support/ForkedCalls.cpp:308
./src/support/Systemcall.cpp:170
./src/support/filetools.cpp:410
./src/graphics/GraphicsConverter.cpp:276

so that full path is not helpfull.


It looks as if this is searching for "python -tt" at the beginning of 
the command,
and then replacing that with an explicit call to python2. So if one gave 
the full
path in a converter to python3, then it should work. Alternatively, one 
could

create a symbolic link to python3, with some other name, and call that.


On unix I can make a symbolic link e.g.
# ln -s /usr/bin/python3 $HOME/bin/python
and lyx is still working. ($HOME/bin is at the beginning of my path)


Confirmed (though on Linux, too).

Richard

Re: Python 3 incompatibilities still exist right?

[Georg Baum]

Richard Heck wrote:

> It might be possible to specify the full path to the python version you
> want to use in
> the relevant converter definition. But I am not sure.

This is possible. The magic happens only for "python -tt". Even specifying 
only "python3" or "python3 -tt" as the interpreter for self defined 
converters should work, if python3 is in the path. If it does not, please 
report a bug, this can probably be fixed easily.


Georg

Python 3 incompatibilities still exist right?

[Scott Kostyshak]

I cleaned RELEASE-NOTES for the master branch. This note is still
relevant right?

- LyX needs to be run under Python 2 and will not work properly on systems
  where Python 3 is the default binary. See bug #7030 to know how to fix
  this properly, since simple sheebang conversion in *.py files will not
  be enough.


I've seen some references here and there (e.g. Benjamin's work on
features/python3), but Python 3 incompatibility is still in master
right?

Scott

Re: Python 3 incompatibilities still exist right?

[stefano franchi]

On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak skost...@lyx.org wrote:

 I cleaned RELEASE-NOTES for the master branch. This note is still
 relevant right?

 - LyX needs to be run under Python 2 and will not work properly on systems
   where Python 3 is the default binary. See bug #7030 to know how to fix
   this properly, since simple sheebang conversion in *.py files will not
   be enough.


 I've seen some references here and there (e.g. Benjamin's work on
 features/python3), but Python 3 incompatibility is still in master
 right?


Actually, I thought this problem was solved a couple of years or so ago
(about Lyx? 2.0.2)
I used to have problems on my ArchLinux box (with python 3 as a default)
but that is no longer
the case.

Stefano



-- 
__
Stefano Franchi

stefano.fran...@gmail.com stef...@tamu.edu
http://stefano.cleinias.org

Re: Python 3 incompatibilities still exist right?

[Alex Vergara Gil]

The incompatibilities still exist at least in Windows sistems, since
LyX installer bundles a python distribution itself and creates a
conflict when python3 is the default. Moreover you cannot use python3
within LyX in Windows, because you will beak the system, LyX will not
reconfigure anymore!!
Just my experiences
LyX 2.1.2, Win7x64, Anaconda 2.1(python 3.4)

Re: Python 3 incompatibilities still exist right?

[Richard Heck]

On 11/20/2014 09:55 AM, stefano franchi wrote:
On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak skost...@lyx.org 
mailto:skost...@lyx.org wrote:


I cleaned RELEASE-NOTES for the master branch. This note is still
relevant right?

- LyX needs to be run under Python 2 and will not work properly on
systems
  where Python 3 is the default binary. See bug #7030 to know how
to fix
  this properly, since simple sheebang conversion in *.py files
will not
  be enough.


I've seen some references here and there (e.g. Benjamin's work on
features/python3), but Python 3 incompatibility is still in master
right?


Actually, I thought this problem was solved a couple of years or so 
ago (about Lyx? 2.0.2)
I used to have problems on my ArchLinux box (with python 3 as a 
default) but that is no longer

the case.


There are two different issues here: (i) Will LyX work when Python 3 is 
the default? (ii) Will
LyX work with Python 3? The answer to the former is Yes, as long as 
Python 2 is available:
We now look for it explicitly. The answer to the latter, I believe, is 
No: The LyX scripts will
not run under Python 3, though some work has been done on that, as Scott 
mentioned.


Richard

Re: Python 3 incompatibilities still exist right?

[stefano franchi]

On Thu, Nov 20, 2014 at 11:36 AM, Richard Heck rgh...@lyx.org wrote:

  On 11/20/2014 09:55 AM, stefano franchi wrote:

 On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak skost...@lyx.org wrote:

 I cleaned RELEASE-NOTES for the master branch. This note is still
 relevant right?

 - LyX needs to be run under Python 2 and will not work properly on systems
   where Python 3 is the default binary. See bug #7030 to know how to fix
   this properly, since simple sheebang conversion in *.py files will not
   be enough.


 I've seen some references here and there (e.g. Benjamin's work on
 features/python3), but Python 3 incompatibility is still in master
 right?


  Actually, I thought this problem was solved a couple of years or so ago
 (about Lyx? 2.0.2)
 I used to have problems on my ArchLinux box (with python 3 as a default)
 but that is no longer
  the case.


 There are two different issues here: (i) Will LyX work when Python 3 is
 the default? (ii) Will
 LyX work with Python 3? The answer to the former is Yes, as long as
 Python 2 is available:
 We now look for it explicitly. The answer to the latter, I believe, is
 No: The LyX scripts will
 not run under Python 3, though some work has been done on that, as Scott
 mentioned.


That's my experience on Linux. However, Alex seemed to suggest (i) is not
completely true on Windows. If I understood his point correctly, LyX will
work when python 3 is the default by installing its own python2
interpreter, which proceeds to break things (which things, I am not sure.
Alex did not say).

So perhaps there are three cases:

(i) Will LyX work when Python 3 is the default, but Python 2 is available?

(ii) Will LyX work with Python 3?

(iii) Will LyX work when Python 3 is the default and LyX install its own
version of Python?

And he answers are yes, no, kind of?


S.


-- 
__
Stefano Franchi

stefano.fran...@gmail.com stef...@tamu.edu
http://stefano.cleinias.org

Python 3 incompatibilities still exist right?

[Scott Kostyshak]

I cleaned RELEASE-NOTES for the master branch. This note is still
relevant right?

- LyX needs to be run under Python 2 and will not work properly on systems
  where Python 3 is the default binary. See bug #7030 to know how to fix
  this properly, since simple sheebang conversion in *.py files will not
  be enough.


I've seen some references here and there (e.g. Benjamin's work on
features/python3), but Python 3 incompatibility is still in master
right?

Scott

Re: Python 3 incompatibilities still exist right?

[stefano franchi]

On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak <skost...@lyx.org> wrote:

> I cleaned RELEASE-NOTES for the master branch. This note is still
> relevant right?
>
> - LyX needs to be run under Python 2 and will not work properly on systems
>   where Python 3 is the default binary. See bug #7030 to know how to fix
>   this properly, since simple sheebang conversion in *.py files will not
>   be enough.
>
>
> I've seen some references here and there (e.g. Benjamin's work on
> features/python3), but Python 3 incompatibility is still in master
> right?
>

Actually, I thought this problem was solved a couple of years or so ago
(about Lyx? 2.0.2)
I used to have problems on my ArchLinux box (with python 3 as a default)
but that is no longer
the case.

Stefano



-- 
__
Stefano Franchi

stefano.fran...@gmail.com <stef...@tamu.edu>
http://stefano.cleinias.org

Re: Python 3 incompatibilities still exist right?

[Alex Vergara Gil]

The incompatibilities still exist at least in Windows sistems, since
LyX installer bundles a python distribution itself and creates a
conflict when python3 is the default. Moreover you cannot use python3
within LyX in Windows, because you will beak the system, LyX will not
reconfigure anymore!!
Just my experiences
LyX 2.1.2, Win7x64, Anaconda 2.1(python 3.4)

Re: Python 3 incompatibilities still exist right?

[Richard Heck]

On 11/20/2014 09:55 AM, stefano franchi wrote:
On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak <skost...@lyx.org 
<mailto:skost...@lyx.org>> wrote:


I cleaned RELEASE-NOTES for the master branch. This note is still
relevant right?

- LyX needs to be run under Python 2 and will not work properly on
systems
  where Python 3 is the default binary. See bug #7030 to know how
to fix
  this properly, since simple sheebang conversion in *.py files
will not
  be enough.


I've seen some references here and there (e.g. Benjamin's work on
features/python3), but Python 3 incompatibility is still in master
right?


Actually, I thought this problem was solved a couple of years or so 
ago (about Lyx? 2.0.2)
I used to have problems on my ArchLinux box (with python 3 as a 
default) but that is no longer

the case.


There are two different issues here: (i) Will LyX work when Python 3 is 
the default? (ii) Will
LyX work with Python 3? The answer to the former is "Yes", as long as 
Python 2 is available:
We now look for it explicitly. The answer to the latter, I believe, is 
"No": The LyX scripts will
not run under Python 3, though some work has been done on that, as Scott 
mentioned.


Richard

Re: Python 3 incompatibilities still exist right?

[stefano franchi]

On Thu, Nov 20, 2014 at 11:36 AM, Richard Heck <rgh...@lyx.org> wrote:

>  On 11/20/2014 09:55 AM, stefano franchi wrote:
>
> On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak <skost...@lyx.org> wrote:
>
>> I cleaned RELEASE-NOTES for the master branch. This note is still
>> relevant right?
>>
>> - LyX needs to be run under Python 2 and will not work properly on systems
>>   where Python 3 is the default binary. See bug #7030 to know how to fix
>>   this properly, since simple sheebang conversion in *.py files will not
>>   be enough.
>>
>>
>> I've seen some references here and there (e.g. Benjamin's work on
>> features/python3), but Python 3 incompatibility is still in master
>> right?
>>
>
>  Actually, I thought this problem was solved a couple of years or so ago
> (about Lyx? 2.0.2)
> I used to have problems on my ArchLinux box (with python 3 as a default)
> but that is no longer
>  the case.
>
>
> There are two different issues here: (i) Will LyX work when Python 3 is
> the default? (ii) Will
> LyX work with Python 3? The answer to the former is "Yes", as long as
> Python 2 is available:
> We now look for it explicitly. The answer to the latter, I believe, is
> "No": The LyX scripts will
> not run under Python 3, though some work has been done on that, as Scott
> mentioned.
>
>
That's my experience on Linux. However, Alex seemed to suggest (i) is not
completely true on Windows. If I understood his point correctly, LyX will
work when python 3 is the default by installing its own python2
interpreter, which proceeds to break things (which things, I am not sure.
Alex did not say).

So perhaps there are three cases:

(i) Will LyX work when Python 3 is the default, but Python 2 is available?

(ii) Will LyX work with Python 3?

(iii) Will LyX work when Python 3 is the default and LyX install its own
version of Python?

And he answers are yes, no, kind of?


S.


-- 
__
Stefano Franchi

stefano.fran...@gmail.com <stef...@tamu.edu>
http://stefano.cleinias.org

LyX when python 3 is already installed...

[ramkromberg]

 To all whom it may concern,
When installing LyX on a Windows machine with a python 3 distribution already 
in place, LyX may fail to initialize since the python scripts are incompatible.
To resolve this I'm using the following batch file (LyX.bat) to set the 
appropriate environment variable:


@echo off
SETLOCAL
SET pythonpath=C:\Program Files (x86)\LyX16\python;C:\Program Files 
(x86)\LyX16\python\Lib;C:\Program Files (x86)\LyX16\python\Lib\encodings;
start LyX C:\Program Files (x86)\LyX16\bin\LyXLauncher.exe %1 %2 %3 %4 %5 
%6 %7 %8 %9
ENDLOCAL


Good Luck.

-- 
Ram Kromberg
ramkromb...@mail.com

LyX when python 3 is already installed...

[ramkromberg]

 To all whom it may concern,
When installing LyX on a Windows machine with a python 3 distribution already 
in place, LyX may fail to initialize since the python scripts are incompatible.
To resolve this I'm using the following batch file (LyX.bat) to set the 
appropriate environment variable:


@echo off
SETLOCAL
SET pythonpath=C:\Program Files (x86)\LyX16\python;C:\Program Files 
(x86)\LyX16\python\Lib;C:\Program Files (x86)\LyX16\python\Lib\encodings;
start "LyX" "C:\Program Files (x86)\LyX16\bin\LyXLauncher.exe" %1 %2 %3 %4 %5 
%6 %7 %8 %9
ENDLOCAL


Good Luck.

-- 
Ram Kromberg
ramkromb...@mail.com

Re: Python 3

[Guenter Milde]

On 2011-02-14, Pavel Sanda wrote:
 Paul Rubin wrote:
 That makes sense to me.  I know some people in the open source optimization
 software community who are doing the same.  I guess we need to be prepared to
 deal with some installation problems.

 we could add some test that python 2.0 is used, but i have no idea how
 this can be done on windows platform. maybe worth to add into our bugzilla.

Do it platform-independent in Python:

import sys
if sys.version_info = (3,0):


Günter

Re: Python 3

[Guenter Milde]

On 2011-02-14, Richard Heck wrote:

 I committed two simple fixes for configure.py. Here is what 2to3 says 
 about the rest:

 [rgheck@rghquad lib]$ /usr/lib64/python3.1/Tools/scripts/2to3 configure.py
 RefactoringTool: Skipping implicit fixer: buffer
 RefactoringTool: Skipping implicit fixer: idioms
 RefactoringTool: Skipping implicit fixer: set_literal
 RefactoringTool: Skipping implicit fixer: ws_comma
 RefactoringTool: Refactored configure.py
 --- configure.py(original)
 +++ configure.py(refactored)
 @@ -996,7 +996,7 @@
   prereq_latex = checkForClassExtension(classname)
   else:
   prereq_list = optAll[1:-1].split(',')
 -prereq_list = map(checkForClassExtension, prereq_list)
 +prereq_list = list(map(checkForClassExtension, 
 prereq_list))
   prereq_latex = ','.join(prereq_list)
   prereq_docbook = {'true':'', 'false':'docbook'}[bool_docbook]
   prereq = {'LaTeX':prereq_latex, 
 'DocBook':prereq_docbook}[classtype]
 @@ -1280,13 +1280,13 @@
   ## Parse the command line
   for op in sys.argv[1:]:   # default shell/for list is $*, the options
   if op in [ '-help', '--help', '-h' ]:
 -print '''Usage: configure [options]
 +print('''Usage: configure [options]
   Options:
   --help   show this help lines
   --keep-temps keep temporary files (for debug. purposes)
   --without-latex-config   do not run LaTeX to determine configuration
   --with-version-suffix=suffix suffix of binary installed files
 -'''
 +''')
   sys.exit(0)
   elif op == '--without-latex-config':
   lyx_check_config = False
 @@ -1295,7 +1295,7 @@
   elif op[0:22] == '--with-version-suffix=':  # never mind if op 
 is not long enough
   version_suffix = op[22:]
   else:
 -print Unknown option, op
 +print(Unknown option, op)
   sys.exit(1)
   #
   # check if we run from the right directory
 RefactoringTool: Files that need to be modified:
 RefactoringTool: configure.py

 So we have two print statements that need fixing, and one call to map(). 
 For map(), I think the change mentioned works in 2.x anyway, right? So 
 that's easy.

Yes.

 What's the minimum Python version we require these days? If 2.6, then we 
 can handle the print stuff by importing print_function from __future__. 

We can easily use

  print(Unknown option  + op)
  
if I got it right and op is a string variable.¹  
This prints the concatenated string without the parentheses in both
Python 2 and 3.

¹ otherwise it would be print(Unknown option  + str(op))


Günter