Re: Patches for Python scripts
On Sat, 30 Jan 2021 at 02:31, Enrico Forestieri wrote: > On Fri, Jan 29, 2021 at 11:40:29PM +0100, Thibaut Cuvelier wrote: > > Hi Thibaut, > > > - This way to find Java is quite common on Windows platforms (actually, > > it's a lot like a port of JavaCall.jl's relevant portion of code: > > https://github.com/JuliaInterop/JavaCall.jl). It looks like Oracle's JVM > > does the same at installation: > https://stackoverflow.com/a/9094539/1066843. > > Other JVMs mimic the same behaviour: > > https://github.com/AdoptOpenJDK/openjdk-installer/issues/64. > > Moreover, I don't think we can let beginner users on their own to > configure > > the PATH, we really should go an extra step to find a Java binary (while > > letting the PATH have preference over anything else, so that users can > > still choose which Java they want). > > Using things like \HKEY_CLASSES_ROOT\Installer\Products\ is, in my > opinion, > > the wrong way to check for Java in the registry: these identifiers seem > to > > vary a lot between versions of Java ( > > > https://docs.oracle.com/en/java/javase/15/install/installation-jdk-microsoft-windows-platforms.html#GUID-886D35CE-76AF-43B4-8C2F-7B34DB8B1666 > ). > > On my machine, I have no 4EA42A62D9304AC4784BF2238120180F, for instance. > > That was actually my point. I found that key by searching for java with > regedit after not finding JavaSoft under HKEY_LOCAL_MACHINE/SOFTWARE/ > > > I am attaching a new version of the patch based on > > > https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-C11500A9-252C-46FE-BB17-FC5A9528EAEB > . > > Does it work for you? Otherwise, would you have something else under > > HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft? > > I do not have HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft : > > $ ls -F /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Java* > ls: No such file or directory > > but, after reading the stackoverflow link above, I found that I have: > > $ ls -F /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/WOW6432Node/JavaSoft/ > 'Auto Update'/ 'Java Update'/ sponsorsoffered > 'Java Plug-in'/ 'Java Web Start'/ > 'Java Runtime Environment'/ 'Java Web Start Caps'/ > > and: > > $ ls -F > /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/WOW6432Node/JavaSoft/Java\ > Runtime\ Environment/ > 1.8/ 1.8.0_281/ BrowserJavaVersion CurrentVersion > > So, it seems that you have to check also for the 32-bit version. > Indeed. Would the attached patch solve the problem? I first look for a 64-bit version before a 32-bit, just to favour newer things, but there is no other reason to do so. 0013-Configure-look-for-Java-in-the-registry-on-Windows.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: DocBook to ePub
On Sat, 30 Jan 2021 at 01:30, Stephan Witt wrote: > Am 29.01.2021 um 18:38 schrieb Thibaut Cuvelier : > > > > Dear list, > > > > As promised, I started working on ePub output, building upon the new > DocBook output. > > > > Here is a script that performs the complete process of taking a DocBook > file and generating the ePub. It has several dependencies: > > > > - an XSLT processor: > > • not xsltproc (http://xmlsoft.org/xslt/xsltproc2.html): > available for most Linux distributions, I guess it is available by default > on macOS, must be bundled for Windows. I tried several versions for > Windows, but an old bug that should have been fixed in 1.1.24 (roughly > 2010) is still there: > > • I/O error : No such file or directory > > • xsltDocumentElem: unable to save to > C:/Users/Thibaut/AppData/Local/Temp/tmp6c2i6a7h/OEBPS/package.opf > > • Saxon 6 (available for most Linux distributions, must be bundled > for Windows and macOS, requires Java). It's outdated software (circa 2005), > but newer versions are not 100% backward compatible, so it is still very > widely used. Other DocBook stylesheets would work on newer Saxon, but they > are not as reliable as the old ones (like > https://github.com/docbook/xslTNG). > > • not MSXML6 (Windows-only, mostly built-it, but not compatible > with the DocBook stylesheets — it wrongly errors with chunking) or .Net > XSLT engine (nxslt/nxslt2). > > - the official DocBook XSLT stylesheets. Three parts are required: > XHTML, XHTML5, and ePub. For now, I copied the needed parts in a patch. On > some Linux distributions, this could be replaced by a version installed by > the package manager (Ubuntu 20.04 has a near-up-to-date version, although > the latest one has been released in 2016: > https://github.com/docbook/xslt10-stylesheets/releases/tag/release%2F1.79.2; > Fedora is up-to-date). > > > > The integration into LyX should be complete, minus testing on Linux and > others and packaging issues: the dependencies must be included for Windows > and macOS, not for all Linux distros. > > On macOS 10.14 (Mojave) I have: > > $ xsltproc -V > Using libxml 20904, libxslt 10129 and libexslt 817 > xsltproc was compiled against libxml 20904, libxslt 10129 and libexslt 817 > libxslt 10129 was compiled against libxml 20904 > libexslt 817 was compiled against libxml 20904 > > Why not? > I was not able to make xsltproc work on Windows with these stylesheets, it gave many errors when creating new files. What if you try with the following docbook2epub.py script (it goes in lib/scripts)? docbook2epub.py Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Fri, Jan 29, 2021 at 3:40 PM Thibaut Cuvelier wrote: > - The cosmetic changes are based on PEP8, which is the only style guide > for Python. Highly similar patches already went into the code base less > than a year ago ( > http://lists.lyx.org/pipermail/lyx-devel/2020-May/001464.html). Other > style guides for Python are just more precise than PEP8 (e.g., Google: > https://stackoverflow.com/a/2815311/1066843). I have yet to see an > important open-source project that does not use PEP8 style guide. It's as > unopiniated as opinion could get on Python. > For now, the Python scripts follow the WTF style guide: every committer > does what they prefer, without any kind of consistency. Python is very > different from other languages in that there is a real consensus in the > community on one style guide (PHP is going in the same direction, but it's > not yet as commonly used: https://www.php-fig.org/psr/psr-2/). I am not > proposing one style guide for C++ or Perl code, for instance. > Some food for thought based on recent experience... The idea of code style (and style application automation) is something that has been on my mind a lot lately. Applying the black utility [ https://github.com/psf/black] for Python and clang-format utility [ https://clang.llvm.org/docs/ClangFormat.html] for C/C++ to several projects I work on have helped reduce style discussion, ensure uniformity, and provide cognitive ease as code is considered. It's to the point that several projects have early CI static analysis that ensures conformance to the applicable style. While one may not love any particular style, having a standard does help with pattern recognition while reading code. Regards, Joel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Fri, Jan 29, 2021 at 11:40:29PM +0100, Thibaut Cuvelier wrote: Hi Thibaut, > - This way to find Java is quite common on Windows platforms (actually, > it's a lot like a port of JavaCall.jl's relevant portion of code: > https://github.com/JuliaInterop/JavaCall.jl). It looks like Oracle's JVM > does the same at installation: https://stackoverflow.com/a/9094539/1066843. > Other JVMs mimic the same behaviour: > https://github.com/AdoptOpenJDK/openjdk-installer/issues/64. > Moreover, I don't think we can let beginner users on their own to configure > the PATH, we really should go an extra step to find a Java binary (while > letting the PATH have preference over anything else, so that users can > still choose which Java they want). > Using things like \HKEY_CLASSES_ROOT\Installer\Products\ is, in my opinion, > the wrong way to check for Java in the registry: these identifiers seem to > vary a lot between versions of Java ( > https://docs.oracle.com/en/java/javase/15/install/installation-jdk-microsoft-windows-platforms.html#GUID-886D35CE-76AF-43B4-8C2F-7B34DB8B1666). > On my machine, I have no 4EA42A62D9304AC4784BF2238120180F, for instance. That was actually my point. I found that key by searching for java with regedit after not finding JavaSoft under HKEY_LOCAL_MACHINE/SOFTWARE/ > I am attaching a new version of the patch based on > https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-C11500A9-252C-46FE-BB17-FC5A9528EAEB. > Does it work for you? Otherwise, would you have something else under > HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft? I do not have HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft : $ ls -F /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Java* ls: No such file or directory but, after reading the stackoverflow link above, I found that I have: $ ls -F /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/WOW6432Node/JavaSoft/ 'Auto Update'/ 'Java Update'/ sponsorsoffered 'Java Plug-in'/ 'Java Web Start'/ 'Java Runtime Environment'/ 'Java Web Start Caps'/ and: $ ls -F /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/WOW6432Node/JavaSoft/Java\ Runtime\ Environment/ 1.8/ 1.8.0_281/ BrowserJavaVersion CurrentVersion So, it seems that you have to check also for the 32-bit version. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On 1/29/21 7:39 AM, Pavel Sanda wrote: > On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: >> With the extent of the patches I fear that there could be bugs (unintended >> changes) lurking specially in relation to python 2. > Riki's call, but I don't think this is the best time for python scripts > overhaul. > Except the changes fixing real bugs we should IMHO postpone these to post 2.4 > world. I would agree with that. We don't want to do anything risky at this stage. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Issue in LyX 2.3.6.1 with \maketitle and \uppertitleback
On 1/29/21 9:47 AM, Jürgen Spitzmüller wrote: > Am Freitag, dem 29.01.2021 um 14:15 +0100 schrieb Michael Ruder: >> Hi, >> >> I just upgraded to LyX 2.3.6.1 and have an issue with \uppertitleback >> and >> multiple \maketitle. This issue did not exist in LyX 2.3.5 and >> before. >> >> Attached is a small sample file. I could reproduce with scrartcl with >> titlepage=true and two side document or scrreprt (I did not test >> other >> styles). In the exported TeX source the issue can be seen. >> >> I used a table in the \uppertitleback area (we use a revision history >> there for documents) and then a \maketitle is added to every column >> and >> line in the \uppertitleback. >> >> Thanks for working on the great tool, we enjoy using it for many >> years >> already! > Fixed in master at 6d05e7816863. > > Riki, this needs to go to stable. Please proceed. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: DocBook to ePub
Am 29.01.2021 um 18:38 schrieb Thibaut Cuvelier : > > Dear list, > > As promised, I started working on ePub output, building upon the new DocBook > output. > > Here is a script that performs the complete process of taking a DocBook file > and generating the ePub. It has several dependencies: > > - an XSLT processor: > • not xsltproc (http://xmlsoft.org/xslt/xsltproc2.html): available for > most Linux distributions, I guess it is available by default on macOS, must > be bundled for Windows. I tried several versions for Windows, but an old bug > that should have been fixed in 1.1.24 (roughly 2010) is still there: > • I/O error : No such file or directory > • xsltDocumentElem: unable to save to > C:/Users/Thibaut/AppData/Local/Temp/tmp6c2i6a7h/OEBPS/package.opf > • Saxon 6 (available for most Linux distributions, must be bundled for > Windows and macOS, requires Java). It's outdated software (circa 2005), but > newer versions are not 100% backward compatible, so it is still very widely > used. Other DocBook stylesheets would work on newer Saxon, but they are not > as reliable as the old ones (like https://github.com/docbook/xslTNG). > • not MSXML6 (Windows-only, mostly built-it, but not compatible with > the DocBook stylesheets — it wrongly errors with chunking) or .Net XSLT > engine (nxslt/nxslt2). > - the official DocBook XSLT stylesheets. Three parts are required: XHTML, > XHTML5, and ePub. For now, I copied the needed parts in a patch. On some > Linux distributions, this could be replaced by a version installed by the > package manager (Ubuntu 20.04 has a near-up-to-date version, although the > latest one has been released in 2016: > https://github.com/docbook/xslt10-stylesheets/releases/tag/release%2F1.79.2; > Fedora is up-to-date). > > The integration into LyX should be complete, minus testing on Linux and > others and packaging issues: the dependencies must be included for Windows > and macOS, not for all Linux distros. On macOS 10.14 (Mojave) I have: $ xsltproc -V Using libxml 20904, libxslt 10129 and libexslt 817 xsltproc was compiled against libxml 20904, libxslt 10129 and libexslt 817 libxslt 10129 was compiled against libxml 20904 libexslt 817 was compiled against libxml 20904 Why not? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
I will be answering most concerns here, in no particular order. I think it will simplify the next messages. - This is far from an overhaul of the script. The logic did not really change, neither the code structure. I have ideas on how to do it, and I could do it if you are OK with it, but I completely agree that larger changes should be delayed to the next version (or 2.4 should be delayed by a few months). This should also be the occasion to get rid of Python 2 completely, that would make the code much clearer. - The cosmetic changes are based on PEP8, which is the only style guide for Python. Highly similar patches already went into the code base less than a year ago (http://lists.lyx.org/pipermail/lyx-devel/2020-May/001464.html). Other style guides for Python are just more precise than PEP8 (e.g., Google: https://stackoverflow.com/a/2815311/1066843). I have yet to see an important open-source project that does not use PEP8 style guide. It's as unopiniated as opinion could get on Python. For now, the Python scripts follow the WTF style guide: every committer does what they prefer, without any kind of consistency. Python is very different from other languages in that there is a real consensus in the community on one style guide (PHP is going in the same direction, but it's not yet as commonly used: https://www.php-fig.org/psr/psr-2/). I am not proposing one style guide for C++ or Perl code, for instance. - This way to find Java is quite common on Windows platforms (actually, it's a lot like a port of JavaCall.jl's relevant portion of code: https://github.com/JuliaInterop/JavaCall.jl). It looks like Oracle's JVM does the same at installation: https://stackoverflow.com/a/9094539/1066843. Other JVMs mimic the same behaviour: https://github.com/AdoptOpenJDK/openjdk-installer/issues/64. Moreover, I don't think we can let beginner users on their own to configure the PATH, we really should go an extra step to find a Java binary (while letting the PATH have preference over anything else, so that users can still choose which Java they want). Using things like \HKEY_CLASSES_ROOT\Installer\Products\ is, in my opinion, the wrong way to check for Java in the registry: these identifiers seem to vary a lot between versions of Java ( https://docs.oracle.com/en/java/javase/15/install/installation-jdk-microsoft-windows-platforms.html#GUID-886D35CE-76AF-43B4-8C2F-7B34DB8B1666). On my machine, I have no 4EA42A62D9304AC4784BF2238120180F, for instance. I am attaching a new version of the patch based on https://docs.oracle.com/javase/9/install/installation-jdk-and-jre-microsoft-windows-platforms.htm#JSJIG-GUID-C11500A9-252C-46FE-BB17-FC5A9528EAEB. Does it work for you? Otherwise, would you have something else under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft? On Fri, 29 Jan 2021 at 14:41, Kornel Benko wrote: > Am Fri, 29 Jan 2021 13:39:19 +0100 > schrieb Pavel Sanda : > > > On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: > > > With the extent of the patches I fear that there could be bugs > (unintended > > > changes) lurking specially in relation to python 2. > > > > Riki's call, but I don't think this is the best time for python scripts > overhaul. > > Except the changes fixing real bugs we should IMHO postpone these to > post 2.4 world. > > > > Pavel > > +1 > > Kornel > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel > 0013-Configure-look-for-Java-in-the-registry-on-Windows.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Issue in LyX 2.3.6.1 with \maketitle and \uppertitleback
Hi, thanks for the ultra-fast resolution of this issue! And thanks again for the great work all of you are doing! On 29.01.21 15:47, Jürgen Spitzmüller wrote regarding "Re: Issue in LyX...": <> Am Freitag, dem 29.01.2021 um 14:15 +0100 schrieb Michael Ruder: <> > Hi, <> > <> > I just upgraded to LyX 2.3.6.1 and have an issue with \uppertitleback <> > and <> > multiple \maketitle. This issue did not exist in LyX 2.3.5 and <> > before. <> > <> > Attached is a small sample file. I could reproduce with scrartcl with <> > titlepage=true and two side document or scrreprt (I did not test <> > other <> > styles). In the exported TeX source the issue can be seen. <> > <> > I used a table in the \uppertitleback area (we use a revision history <> > there for documents) and then a \maketitle is added to every column <> > and <> > line in the \uppertitleback. <> > <> > Thanks for working on the great tool, we enjoy using it for many <> > years <> > already! <> <> Fixed in master at 6d05e7816863. <> <> Riki, this needs to go to stable. <> <> Jürgen <> <> > <> > Best regards, <> > -- <> > . -Michael <> <> -- . -Michael -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Issue in LyX 2.3.6.1 with \maketitle and \uppertitleback
Am Freitag, dem 29.01.2021 um 14:15 +0100 schrieb Michael Ruder: > Hi, > > I just upgraded to LyX 2.3.6.1 and have an issue with \uppertitleback > and > multiple \maketitle. This issue did not exist in LyX 2.3.5 and > before. > > Attached is a small sample file. I could reproduce with scrartcl with > titlepage=true and two side document or scrreprt (I did not test > other > styles). In the exported TeX source the issue can be seen. > > I used a table in the \uppertitleback area (we use a revision history > there for documents) and then a \maketitle is added to every column > and > line in the \uppertitleback. > > Thanks for working on the great tool, we enjoy using it for many > years > already! Fixed in master at 6d05e7816863. Riki, this needs to go to stable. Jürgen > > Best regards, > -- > . -Michael 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: Issue in LyX 2.3.6.1 with \maketitle and \uppertitleback
Am Freitag, dem 29.01.2021 um 14:15 +0100 schrieb Michael Ruder: > I just upgraded to LyX 2.3.6.1 and have an issue with \uppertitleback > and > multiple \maketitle. This issue did not exist in LyX 2.3.5 and > before. > > Attached is a small sample file. I could reproduce with scrartcl with > titlepage=true and two side document or scrreprt (I did not test > other > styles). In the exported TeX source the issue can be seen. > > I used a table in the \uppertitleback area (we use a revision history > there for documents) and then a \maketitle is added to every column > and > line in the \uppertitleback. > > Thanks for working on the great tool, we enjoy using it for many > years > already! Thanks for the report, I'll have a look. Meanwhile, please find attached a workaround. HTH Jürgen maketitle_bug-wa.lyx Description: application/lyx 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: Patches for Python scripts
Am Fri, 29 Jan 2021 13:39:19 +0100 schrieb Pavel Sanda : > On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: > > With the extent of the patches I fear that there could be bugs (unintended > > changes) lurking specially in relation to python 2. > > Riki's call, but I don't think this is the best time for python scripts > overhaul. > Except the changes fixing real bugs we should IMHO postpone these to post 2.4 > world. > > Pavel +1 Kornel pgpHG7SItevQQ.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Run updateBuffer when adding/merging changes
Le 28/01/2021 à 15:54, Richard Kimberly Heck a écrit :
- if (cur.needBufferUpdate()) {
+ if (cur.needBufferUpdate() || buffer().needUpdate()) {
cur.clearBufferUpdate();
Shouldn't the Buffer::updateBuffer_ member also be reset here?
Good catch. Thanks.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Issue in LyX 2.3.6.1 with \maketitle and \uppertitleback
Hi,
I just upgraded to LyX 2.3.6.1 and have an issue with \uppertitleback and
multiple \maketitle. This issue did not exist in LyX 2.3.5 and before.
Attached is a small sample file. I could reproduce with scrartcl with
titlepage=true and two side document or scrreprt (I did not test other
styles). In the exported TeX source the issue can be seen.
I used a table in the \uppertitleback area (we use a revision history
there for documents) and then a \maketitle is added to every column and
line in the \uppertitleback.
Thanks for working on the great tool, we enjoy using it for many years
already!
Best regards,
--
. -Michael
maketitle_bug.lyx
Description: application/lyx
%% LyX 2.3.6.1 created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[twoside,english]{scrreprt}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\setcounter{secnumdepth}{3}
\setcounter{tocdepth}{3}
\makeatletter
%% LyX specific LaTeX commands.
%% Because html converters don't know tabularnewline
\providecommand{\tabularnewline}{\\}
\makeatother
\usepackage{babel}
\begin{document}
\title{Titel}
\lowertitleback{%
\begin{tabular}{|c|c|}
\hline
\maketitle
Table & \maketitle
as\tabularnewline
\hline
\hline
\maketitle
Uppertitleback & \maketitle
\tabularnewline
\hline
\end{tabular}}
\maketitle
\section{Section}
text
\end{document}
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Fri, Jan 29, 2021 at 11:07:43AM +, José Abílio Matos wrote: > With the extent of the patches I fear that there could be bugs (unintended > changes) lurking specially in relation to python 2. Riki's call, but I don't think this is the best time for python scripts overhaul. Except the changes fixing real bugs we should IMHO postpone these to post 2.4 world. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Friday, January 29, 2021 11:48:40 AM WET Kornel Benko wrote:
> Right, the last one should be escaped.
> Given the line
> # \DeclareLaTeXClass[revtex,revtex.sty]{REVTeX (Obsolete Version)}
> and the original regex
>
> '\\s*#\\s*DeclareLaTeXClass\\s*(\[([^,]*)(,.*)*\])*\\s*{(.*)}\\s*$' the
> result in found(1) would be "revtex"
> and found(2) would be the rest inside the escaped brackets, e.g.
> "revtex.sty"
>
> Not escaping the last ']' probably not intended.
> (I would escape also '{' and '}' if that were a perl regex)
Now that you mention it the code should use raw strings in order to avoid
doubling the backslashes, e.g. in order to match \DeclareLaTeXclass the code
has "DeclareLaTeXclass" because the backslash needs to be escaped twice
the first time for the regular expression and then each needs to be escaped
again for python.
Using raw strings the results would be r"\\DeclareLaTeXclass" more in line
with what we usually write. :-)
This is a detour that come from the code analysis and it does not come from
Thibault's changes.
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
Am Fri, 29 Jan 2021 11:07:43 +
schrieb José Abílio Matos :
> On Friday, January 29, 2021 5:05:19 AM WET Richard Kimberly Heck wrote:
> > José, can you look at these please?
> >
> > Riki
>
> I think that Thibaut wants to impose black[1] on us. :-D
>
> Most of the changes are cosmetic, e.g. one import per line, or to use the
> same
> indentation for documentation.
>
> The only bits where I am unsure are on the regular expressions (I am trimming
> the expression to make it easier to read):
> -declare = re.compile('\\s*(\[([^,]*)(,.*)*\])*$')
> +declare = re.compile('\\s*(\[([^,]*)(,.*)*])*$')
Right, the last one should be escaped.
Given the line
# \DeclareLaTeXClass[revtex,revtex.sty]{REVTeX (Obsolete Version)}
and the original regex
'\\s*#\\s*DeclareLaTeXClass\\s*(\[([^,]*)(,.*)*\])*\\s*{(.*)}\\s*$'
the result in found(1) would be "revtex"
and found(2) would be the rest inside the escaped brackets, e.g. "revtex.sty"
Not escaping the last ']' probably not intended.
(I would escape also '{' and '}' if that were a perl regex)
> The left bracket is escaped but not the right one. What do other, more
> knowledgeable about the black magic of regular expressions think?
>
> The are other issues like mistakes in the documentation strings. For the
> moment those are harmless, I am referring to e.g. "\c" since \c it is not an
> escape sequence it gets transformed to "\\c".
>
>
> With the extent of the patches I fear that there could be bugs (unintended
> changes) lurking specially in relation to python 2.
>
> In particular this just reinforces my feeling that configure.py should get an
> overhaul. :-)
>
> This is my preliminary overview. I will keep looking into the patches.
>
>
> [1] From Henry Ford's T model "You can choose any color as long as it is
> black".
> https://black.readthedocs.io/en/stable/
>
pgppUSmSKjpVK.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Friday, January 29, 2021 3:51:12 AM WET Thibaut Cuvelier wrote: > Dear list, > > While working on the ePub output, I ran through many Python scripts. I > corrected a few bgs and a lot of formatting, plus one feature (find Java in > the Windows registry in configure.py), here are the patches. May I push > them on the master branch? There are things that I like on the patches that fix real bugs, there are others that are cosmetic and in same case are white space changes. I am ignoring the java detection part already discussed by Enrico. Patches that should go in (they fix real bugs): * 10 (this is a matter of principle) * 7 * 5 * 6 * 12 (a good idea, that could be used elsewhere) I have doubts: * 11 (the regex changes) I am neutral on all the other. These changes are opinionated changes that change formatting mostly. BTW to continue with the joke regarding black there is a new package called blue: https://pypi.org/project/blue/ -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Friday, January 29, 2021 5:05:19 AM WET Richard Kimberly Heck wrote:
> José, can you look at these please?
>
> Riki
I think that Thibaut wants to impose black[1] on us. :-D
Most of the changes are cosmetic, e.g. one import per line, or to use the same
indentation for documentation.
The only bits where I am unsure are on the regular expressions (I am trimming
the expression to make it easier to read):
-declare = re.compile('\\s*(\[([^,]*)(,.*)*\])*$')
+declare = re.compile('\\s*(\[([^,]*)(,.*)*])*$')
The left bracket is escaped but not the right one. What do other, more
knowledgeable about the black magic of regular expressions think?
The are other issues like mistakes in the documentation strings. For the
moment those are harmless, I am referring to e.g. "\c" since \c it is not an
escape sequence it gets transformed to "\\c".
With the extent of the patches I fear that there could be bugs (unintended
changes) lurking specially in relation to python 2.
In particular this just reinforces my feeling that configure.py should get an
overhaul. :-)
This is my preliminary overview. I will keep looking into the patches.
[1] From Henry Ford's T model "You can choose any color as long as it is
black".
https://black.readthedocs.io/en/stable/
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On 1/29/21 4:41 AM, Enrico Forestieri wrote: > On Fri, Jan 29, 2021 at 04:51:12AM +0100, Thibaut Cuvelier wrote: >> While working on the ePub output, I ran through many Python scripts. I >> corrected a few bgs and a lot of formatting, plus one feature (find Java in >> the Windows registry in configure.py), here are the patches. May I push >> them on the master branch? > As regarda java, I have it installed but it is not found. I don't have the > registry keys that are searched for. A key containing a usable path is > \HKEY_CLASSES_ROOT\Installer\Products\4EA42A62D9304AC4784BF2238120180F\ProductIcon > and the fact that it *should* be something related to java is the fact that > \HKEY_CLASSES_ROOT\Installer\Products\4EA42A62D9304AC4784BF2238120180F\ProductName > contains "Java 8 Update 281". > > However, the java installer updates the PATH env var, so that I can > simply access the java executables from any command line. > > I discourage using ad hoc techniques that only work on some configurations. I would agree with that. But of course that makes it quite difficult to detect certain programs on Windows. I guess we have to live with that, then. I'll omit the usual complaints about Windows Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Patches for Python scripts
On Fri, Jan 29, 2021 at 04:51:12AM +0100, Thibaut Cuvelier wrote: > > While working on the ePub output, I ran through many Python scripts. I > corrected a few bgs and a lot of formatting, plus one feature (find Java in > the Windows registry in configure.py), here are the patches. May I push > them on the master branch? As regarda java, I have it installed but it is not found. I don't have the registry keys that are searched for. A key containing a usable path is \HKEY_CLASSES_ROOT\Installer\Products\4EA42A62D9304AC4784BF2238120180F\ProductIcon and the fact that it *should* be something related to java is the fact that \HKEY_CLASSES_ROOT\Installer\Products\4EA42A62D9304AC4784BF2238120180F\ProductName contains "Java 8 Update 281". However, the java installer updates the PATH env var, so that I can simply access the java executables from any command line. I discourage using ad hoc techniques that only work on some configurations. -- Enrico -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
