DesignOpinion needed
I managed to put together basic UI and mini-code editor/runner inside LyX. The terminal has been implemented. Other functions are still under active development. I would like to use this thread to ask for inputs on what other functions/UI should be prioritized. A screenshot of the current prototype is here: https://github.com/jasonsun0310/JupyLyx/blob/master/prototype.jpg
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 26.06.2019 um 14:08 schrieb Kornel Benko : > > Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: >>> I’m not surprised at these explanation. >>> >>> The real world scenario would be to disable python 3.4 on my system >>> and test it with 2.7.15 - this works for me. >>> >>> But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and >>> used? >>> Or is it this what you propose? Change the tested minimal python version >>> from 3.3.0 to 3.5.0? >>> Then I’ll cannot agree more. >> >> The attached patch works for me on Mac. >> >> Stephan >> > > The patch (and the original) omits to work with python2.7? AFAICS it refuses to work with python < 2.7 (But works with e.g. 1.9 :) ???) > I have not seen problems (cmake build allows 2.7 version) > > My versions are 2.7.12 and 3.5.2. For me it works with 2.7.15 Stephan
About file qt_i18n.h
I see that in every .ui file there is a line that includes qt_i18n.h file. When I create a new .ui file in Qt Creator using in Designer Form, this line is not included. So I have to manually added it. The question is there a way to tell Qt Designer to include this include directive? Jason
Re: master: Python detection on Mac doesn't find python 2.7.15
On Wednesday, 26 June 2019 13.08.37 WEST Kornel Benko wrote: > The patch (and the original) omits to work with python2.7? > I have not seen problems (cmake build allows 2.7 version) > > My versions are 2.7.12 and 3.5.2. > > Kornel They should I have tested them with 2.7 (.16 in my case). -- José Abílio
Re: master: Python detection on Mac doesn't find python 2.7.15
On Wednesday, 26 June 2019 11.40.07 WEST Stephan Witt wrote: > Hi José, > > I’m not surprised at these explanation. > > The real world scenario would be to disable python 3.4 on my system > and test it with 2.7.15 - this works for me. That is what I am proposing. :-) > But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and > used? Or is it this what you propose? Change the tested minimal python > version from 3.3.0 to 3.5.0? Then I’ll cannot agree more. That is also my point. At some point during the process we settled on python 3.3 because it supports the u"" notation. In python 2 those mean unicode strings (strings with an encoding as to differentiate them from the usual "" strings that are basically an array of bytes). In python 3 u"" is a no-op because all the strings have an encoding associated. Until python 3.3 the u"" notation gave an error. Again this notation was introduced to allow an easy migration to python 3 by using a common code base. It is the same reasoning as in the previous case. So I am really proposing is to accept as the minimum version for python 3 the 3.5 release. There are three places to change: * os::python23 function in support; * autotools support; * cmake; We should be simply a matter of replacing 3.3 by 3.5. > Best regards, > Stephan -- José Abílio
Re: master: Python detection on Mac doesn't find python 2.7.15
Am Mittwoch, 26. Juni 2019, 13:21:25 CEST schrieb Stephan Witt: > > I’m not surprised at these explanation. > > > > The real world scenario would be to disable python 3.4 on my system > > and test it with 2.7.15 - this works for me. > > > > But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and > > used? > > Or is it this what you propose? Change the tested minimal python version > > from 3.3.0 to 3.5.0? > > Then I’ll cannot agree more. > > The attached patch works for me on Mac. > > Stephan > The patch (and the original) omits to work with python2.7? I have not seen problems (cmake build allows 2.7 version) My versions are 2.7.12 and 3.5.2. Kornel signature.asc Description: This is a digitally signed message part.
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 26.06.2019 um 12:40 schrieb Stephan Witt :
>
> Am 26.06.2019 um 10:46 schrieb José Abílio Matos :
>>
>> On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
>>> +checking list of modules...
>>> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
>>> me.module Traceback (most recent call last):
>>> File
>>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>>> .py", line 1875, in checkModulesConfig()
>>> File
>>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>>> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
>>> filename.encode('ascii'), bool_docbook) File
>>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>>> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
>>> excl, catgy, local))
>>> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
>>>
>>> Best regards,
>>> Stephan
>>
>> Thank you Stefan,
>> these results make all the sense to me.
>>
>> This problem only occurs in python 3.4, it works for 3.5+.
>>
>> TLDR; I honestly suggest that the minimum python 3 version supported to be
>> python 3.5.
>>
>>
>> The long explanation:
>>
>> For those that have been following the threads regarding python 3 and LyX
>> the
>> main topic is always the same.
>>
>> When python 3 was released in 2008 (really!) there was a wish to drop some
>> features and to fix long standing design decisions on python.
>>
>> It worked is most cases. But in some cases those changes went too far, and
>> thus all the issues regarding the transition from python 2 to python 3.
>>
>> At some point, if you remember I said that in a sense python 2 and python 3
>> were different languages. And I maintain what I said at that time.
>>
>> One motto of python (for versions 2 and 3) though is:
>>
>> $ python3 -m this | grep purity
>> Although practicality beats purity.
>>
>> $ python2 -m this | grep purity
>> Although practicality beats purity.
>>
>> So the practical side won and the successive python 3 versions brought more
>> and more features to support the python 2 transition.
>>
>> The last part of these came with python 3.5, and in one cases is related
>> with
>> the interpolation of byte strings. The feature that works similarly to
>> fprintf
>> and friends in C/C++.
>>
>> The % operator, used to work only on strings (that have a defined encoding)
>> and not in sequence of bytes. That decision was by design. The main issue is
>> that sometimes we are working on text files for which we do not know the
>> encoding but we know that they have ascii.
>>
>> This applies a lot to lyx files before 1.6, but not only.
>>
>> After too many complains the decision was reverted in python 3.5. That
>> allows
>> for the same code to run in both python 2 (that does not distinguishes
>> between
>> strings and sequences of bytes) and in python 3.
>>
>> In this particular case we can track all the cases where this feature is
>> used
>> and ensure that the alternative works for both python 2(.7) and for python 3.
>>
>> My suggestion as in other messages this year is simply to bump the
>> requirement
>> to python 3.5 and live with it.
>>
>> Best regards,
>>
>> PS: the above is technically correct but you should take the philosophical/
>> technical considerations with a grain of salt. After all the language name
>> comes from the "Monty Python Flying Circus" and no one is expecting the
>> Spanish Inquisition. :-) :-D
>
> Hi José,
>
> I’m not surprised at these explanation.
>
> The real world scenario would be to disable python 3.4 on my system
> and test it with 2.7.15 - this works for me.
>
> But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and
> used?
> Or is it this what you propose? Change the tested minimal python version from
> 3.3.0 to 3.5.0?
> Then I’ll cannot agree more.
The attached patch works for me on Mac.
Stephan
The terminal output is:
$ /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/MacOS/lyx -v
Running: python3 -c 'from __future__ import print_function;import sys;
print(sys.version_info[:2], end="")'
sh: python3: command not found
Looking for python 3.x ...
Examining /opt/local/bin/python3.4
Running: /opt/local/bin/python3.4 -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Examining /opt/local/bin/python3.4-config
Running: /opt/local/bin/python3.4-config -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Usage: /opt/local/bin/python3.4-config
[--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir]
Examining /opt/local/bin/python3.4m
Running: /opt/local/bin/python3.4m -c 'from __future__ import
print_function;import sys; print(sys.version_info[:2], end="")'
Examining /opt/local/bin/python3.4m-config
Running:
Re: master: Python detection on Mac doesn't find python 2.7.15
Am 26.06.2019 um 10:46 schrieb José Abílio Matos :
>
> On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
>> +checking list of modules...
>> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
>> me.module Traceback (most recent call last):
>> File
>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>> .py", line 1875, in checkModulesConfig()
>> File
>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
>> filename.encode('ascii'), bool_docbook) File
>> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
>> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
>> excl, catgy, local))
>> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
>>
>> Best regards,
>> Stephan
>
> Thank you Stefan,
> these results make all the sense to me.
>
> This problem only occurs in python 3.4, it works for 3.5+.
>
> TLDR; I honestly suggest that the minimum python 3 version supported to be
> python 3.5.
>
>
> The long explanation:
>
> For those that have been following the threads regarding python 3 and LyX the
> main topic is always the same.
>
> When python 3 was released in 2008 (really!) there was a wish to drop some
> features and to fix long standing design decisions on python.
>
> It worked is most cases. But in some cases those changes went too far, and
> thus all the issues regarding the transition from python 2 to python 3.
>
> At some point, if you remember I said that in a sense python 2 and python 3
> were different languages. And I maintain what I said at that time.
>
> One motto of python (for versions 2 and 3) though is:
>
> $ python3 -m this | grep purity
> Although practicality beats purity.
>
> $ python2 -m this | grep purity
> Although practicality beats purity.
>
> So the practical side won and the successive python 3 versions brought more
> and more features to support the python 2 transition.
>
> The last part of these came with python 3.5, and in one cases is related with
> the interpolation of byte strings. The feature that works similarly to
> fprintf
> and friends in C/C++.
>
> The % operator, used to work only on strings (that have a defined encoding)
> and not in sequence of bytes. That decision was by design. The main issue is
> that sometimes we are working on text files for which we do not know the
> encoding but we know that they have ascii.
>
> This applies a lot to lyx files before 1.6, but not only.
>
> After too many complains the decision was reverted in python 3.5. That allows
> for the same code to run in both python 2 (that does not distinguishes
> between
> strings and sequences of bytes) and in python 3.
>
> In this particular case we can track all the cases where this feature is used
> and ensure that the alternative works for both python 2(.7) and for python 3.
>
> My suggestion as in other messages this year is simply to bump the
> requirement
> to python 3.5 and live with it.
>
> Best regards,
>
> PS: the above is technically correct but you should take the philosophical/
> technical considerations with a grain of salt. After all the language name
> comes from the "Monty Python Flying Circus" and no one is expecting the
> Spanish Inquisition. :-) :-D
Hi José,
I’m not surprised at these explanation.
The real world scenario would be to disable python 3.4 on my system
and test it with 2.7.15 - this works for me.
But - if it’s clear LyX doesn’t work with python 3.4 why is it tried and used?
Or is it this what you propose? Change the tested minimal python version from
3.3.0 to 3.5.0?
Then I’ll cannot agree more.
Best regards,
Stephan
Re: master: Python detection on Mac doesn't find python 2.7.15
On Tuesday, 25 June 2019 19.17.13 WEST Stephan Witt wrote:
> +checking list of modules...
> /Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/layouts/fix
> me.module Traceback (most recent call last):
> File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1875, in checkModulesConfig()
> File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1495, in checkModulesConfig retval = processModuleFile(file,
> filename.encode('ascii'), bool_docbook) File
> "/Users/stephan/git/lyx-build/LyX-2.4.0dev.app/Contents/Resources/configure
> .py", line 1594, in processModuleFile % (modname, filename, desc, pkgs, req,
> excl, catgy, local))
> TypeError: unsupported operand type(s) for %: 'bytes' and 'tuple'
>
> Best regards,
> Stephan
Thank you Stefan,
these results make all the sense to me.
This problem only occurs in python 3.4, it works for 3.5+.
TLDR; I honestly suggest that the minimum python 3 version supported to be
python 3.5.
The long explanation:
For those that have been following the threads regarding python 3 and LyX the
main topic is always the same.
When python 3 was released in 2008 (really!) there was a wish to drop some
features and to fix long standing design decisions on python.
It worked is most cases. But in some cases those changes went too far, and
thus all the issues regarding the transition from python 2 to python 3.
At some point, if you remember I said that in a sense python 2 and python 3
were different languages. And I maintain what I said at that time.
One motto of python (for versions 2 and 3) though is:
$ python3 -m this | grep purity
Although practicality beats purity.
$ python2 -m this | grep purity
Although practicality beats purity.
So the practical side won and the successive python 3 versions brought more
and more features to support the python 2 transition.
The last part of these came with python 3.5, and in one cases is related with
the interpolation of byte strings. The feature that works similarly to fprintf
and friends in C/C++.
The % operator, used to work only on strings (that have a defined encoding)
and not in sequence of bytes. That decision was by design. The main issue is
that sometimes we are working on text files for which we do not know the
encoding but we know that they have ascii.
This applies a lot to lyx files before 1.6, but not only.
After too many complains the decision was reverted in python 3.5. That allows
for the same code to run in both python 2 (that does not distinguishes between
strings and sequences of bytes) and in python 3.
In this particular case we can track all the cases where this feature is used
and ensure that the alternative works for both python 2(.7) and for python 3.
My suggestion as in other messages this year is simply to bump the requirement
to python 3.5 and live with it.
Best regards,
PS: the above is technically correct but you should take the philosophical/
technical considerations with a grain of salt. After all the language name
comes from the "Monty Python Flying Circus" and no one is expecting the
Spanish Inquisition. :-) :-D
--
José Abílio
