On Mon, Dec 30, 2024 at 09:54:30AM +, José Matos wrote:
> On Fri, 2024-12-20 at 00:28 +0100, Scott Kostyshak wrote:
> Regarding type checking in Python there are type annotations that are used to
> do
> type hinting.
> [cut]
Thanks for this detailed explanations. It's good to learn about typ
expecting bytes.
>
> Why not assert that at the beginning of the Python function?
> Or, what's the best way to do type-checking of arguments in Python?
This is an artifact of the joint support of Python 2 and Python 3.
https://docs.python.org/3.10/howto/pyporting.html
Python
On Fri, Dec 20, 2024 at 12:53:54AM +0100, Pavel Sanda wrote:
> On Fri, Dec 20, 2024 at 12:28:22AM +0100, Scott Kostyshak wrote:
> > Works well on Welcome.lyx. On my original use case, I get the following now:
>
> New case for the test machinery? P
Could be! Are there a lot of code paths for thex
On Fri, Dec 20, 2024 at 12:28:22AM +0100, Scott Kostyshak wrote:
> Works well on Welcome.lyx. On my original use case, I get the following now:
New case for the test machinery? P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
On Thu, Dec 19, 2024 at 10:31:20PM +, José Matos wrote:
> On Thu, 2024-12-19 at 15:57 +0100, Scott Kostyshak wrote:
> > Is the problem that the object should not be a string?
>
> Yes, it was expecting bytes.
Why not assert that at the beginning of the Python function?
Or, what's the best way
On Thu, 2024-12-19 at 15:57 +0100, Scott Kostyshak wrote:
> Is the problem that the object should not be a string?
Yes, it was expecting bytes.
> $ python3 --version
> Python 3.12.3
Do you know the Whac-A-Mole game? :-)
It was the same game that I was playing here.
I modernized the code a bit,
On Mon, Jun 10, 2024 at 10:30:07AM +, José Matos wrote:
> commit 04ecabef6005640450cb20e813eeb2bb284b9487
> Author: José Matos
> Date: Mon Jun 10 11:29:56 2024 +0100
>
> Update Python scripts to Python 3+
>
> Remove support for Python 2
>
>
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 u
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
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.
C
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?
&
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 t
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
th
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.p
../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)
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 Python
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 su
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
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
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
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].
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 (fol
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
#x27;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
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 e
19 +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 err
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 a
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 "g
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
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.
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
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
>
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
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
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 si
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.
> Al
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
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
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
rsion 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 direct
d 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 extre
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
> > >
> > > f
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 $
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 pytho
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
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
revious 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
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
e 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 in
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
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
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
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
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 ch
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.
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 i
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
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
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. Moreov
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
>
> r
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
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
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, release
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
po
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 a
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('\\', '/')
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
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.
>
> r
ives 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 Py
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_
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.
:-)
>
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 mo
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.1
hen 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
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:/LyX
hem 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 versio
ASE-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 yourse
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 agai
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 a
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, 20
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
On 11/21/2014 09:23 AM, Kornel Benko wrote:
Am Freitag, 21. November 2014 um 08:55:25, schrieb 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
Am Freitag, 21. November 2014 um 08:55:25, schrieb 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
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
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
; - 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
operly 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/pyt
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!!
Jus
On Thu, Nov 20, 2014 at 2:09 AM, Scott Kostyshak 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
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
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 var
Richard Heck wrote:
> I committed two simple fixes for configure.py. Here is what 2to3 says about
> the rest:
Richard, please reread "Python 3" thread we had some time ago with Jose,
mainly the "subtle" problems part.
i'm not sure thats better if we work with py
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:
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
;t be sure.
Has
anyone tested the various Python scripts against Python 3?
I think we have been trying to avoid this. I think I did do some stuff with
lyx2lyx, running it with whatever that flag is that warns you about Python 3
incompatibilities, but that is all I did. Plainly, we need to do this
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
Pavel Sanda lyx.org> writes:
>
> Paul A. Rubin wrote:
> > I swapped a few e-mails with her and eventually discovered that she has
Python
> > 3.1 installed. I suspect that might be the culprit but can't be sure. Has
> > anyone tested the various Python scri
Paul A. Rubin wrote:
> I swapped a few e-mails with her and eventually discovered that she has Python
> 3.1 installed. I suspect that might be the culprit but can't be sure. Has
> anyone tested the various Python scripts against Python 3?
it is very probable there is some issue. c
re.
>> Has
>> anyone tested the various Python scripts against Python 3?
>>
> I think we have been trying to avoid this. I think I did do some stuff with
> lyx2lyx, running it with whatever that flag is that warns you about Python 3
> incompatibilities, but that is all I
sure. Has
anyone tested the various Python scripts against Python 3?
I think we have been trying to avoid this. I think I did do some stuff
with lyx2lyx, running it with whatever that flag is that warns you about
Python 3 incompatibilities, but that is all I did. Plainly, we need to
do this with
1 - 100 of 114 matches
Mail list logo
