Re: Change LyX release numbering to Semantic Versioning
On Wednesday, January 13, 2021 8:27:28 PM WET Pavel Sanda wrote: > The question really is why it should be wrong to give new major version > +0.1. > > Anyway, I do not see that this subthread is moving in a constructive > direction, so it's perhaps best to agree that we disagree I agree, I tried to expose the reasons why I think that the change is worth. I think that by now all the arguments have been presented. We should make a decision and proceed. :-) > It's not a grave issue to me so if majority decides that we should > abandon the current versioning scheme I can live with that. > > .. I might fight for LyX-year.minor versioning scheme once we hit 9 though That is fair. :-) On the other hand at that time I will be probably hunted by the year 2038 problem. :-D > Pavel -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Change LyX release numbering to Semantic Versioning
On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote: > Fortunately I do not have to rely only on my memory > > Wiki: Sat Nov 15 18:59:02 2008 : LyX 2_0: Wiki pages creation > SVN:Sun Dec 7 18:09:18 2008 : [Cvslog] r27798 Makefile.am: PSpell and > ISpell was removed for LyX 2.0 at the developer meeting dev list: Wed Dec > 17 00:29:31 2008 : When compiling LyX 2.0svn I get: ... regards Uwe I stand corrected. :-) I had searched yesterday in the mailing list archive. There I found a thread named "Subversion don't work in 1.7 version". This induced me in error. It really meant that svn 1.7 was not working with the lyx. I read it wrongly, that svn did not work lyx 1.7. My mistake. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Change LyX release numbering to Semantic Versioning
On Wednesday, January 13, 2021 9:48:58 AM WET Jean-Marc Lasgouttes wrote: > I do not really like this. I find it very useful to add weird character > in a version string to indicate that the version is not a regular one. > > JMarc This is what I call the "Paris Syndrome", a mild form of the "Stockholm Syndrome". :-D On a more serious note, I do not insist on the particular use of the x.0 convention. I find it elegant and it gives a nice justification, for example, why gcc stable releases always starts at .1. FWIW gcc started the new numbering scheme at version 5, and it already the seventh release where this numbering schme is used. In Fedora Rawhide (to be Fedora 34) the current version of gcc is 11.0.0. That immediately shows that this is not the stable version. The first stable version will be 11.1. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Change LyX release numbering to Semantic Versioning
On Wednesday, January 13, 2021 11:51:53 AM WET Pavel Sanda wrote: > I hope my memory serves me well, but the major reason we did not go the > predictable route of 1.6, 1.7, 1.8, 1.9, 2.0, 2.1 etc was your own push for > 2.0 at the Berlin meeting. I can even remember at which corner of the room > were you standing when voicing the issue The meeting was on 2008 and the actual change was in 2010. So it was not at all an immediate effect. > I added justification for 2.0 as a celebration of anniversary of the project > in the release notes, but that was secondary to that push and would not > happen without. Actually I was not even against that particular bump, but > to use it now as an argument against predictability for yeat another > unpredictable jump does not look fair > > Pavel It was not my intention to picture it like that. Joel asked what was the reason for the change from 1.x to 2.y. At the time I said that with so many changes like lyx2lyx or unicode support it was more than time to change to a new major version. The reason why I insist in this for so long is that the changes in lyx are not additive but multiplicative. All the versions since 1.2 were real major versions that deserve their own major version. My concern is also related with communication. We should really stress that any stable series is major change from previous. And clearly since 1.2 that is true for all of them IMHO. The time scale it is also relevant, releasing a new version every 2-3 years contributes to major changes between the successive versions. If we follow Jean-Marc's analogy with LibreOffice (they are comparable to us in terms of solving similar problems) they have point releases but on the other hand they release on a periodic basis (~every 6 months). -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Change LyX release numbering to Semantic Versioning
On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote: > I guess that's the point where we break. I agree that moving from 2 to 3 > signals major change. At the same time once some project moves to double > digits versions my experience is that I am no more keeping track which > version is which unless I have special interest in some bug etc. So let me see if I understand. You have a problem with LyX 10 but not with LyX 2.10 series. Is that correct? My other remark is that are not changes that meet the litmus test of being considered important enough to deserve the major version jump. There has not been none in the previous 20 years. If we applied this reasoning we would start work on the release of LyX 1.11. > Pavel -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Monday, January 4, 2021 2:02:30 PM WET Jean-Marc Lasgouttes wrote: > Strangely enough, the test is present. Assuming your configure script is > updated, could you send the output of >g++ -dumpversion > and >g++ -dumpfullversion > ? > > JMarc [root@centos7 ~]# g++ -dumpversion 4.8.5 [root@centos7 ~]# g++ -dumpfullversion g++: fatal error: no input files compilation terminated. [root@centos7 ~]# rpm -qf /usr/bin/g++ gcc-c++-4.8.5-44.el7.x86_64 -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Remove elipses after 'Open'
On Sunday, January 3, 2021 7:19:11 PM WET Jean-Marc Lasgouttes wrote: > > Remove elipses after 'Open' > > Why is that? > > JMarc I agree with Jean-Marc. Open always launches a pop up and so it always has ellipses in every program I tried. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Monday, January 4, 2021 2:02:30 PM WET Jean-Marc Lasgouttes wrote: > > Strangely enough, the test is present. Assuming your configure script is > updated, I will answer this in two parts. :-) I would assume that the configure script is updated as I am compiling from the tar balls created by Riki for alpha 1. > could you send the output of >g++ -dumpversion > and >g++ -dumpfullversion > ? > > JMarc I asked in the Fedora EPEL's list for this output as I do not have CentOS or RHEL installed (either version 7 or any other). As soon as I have a feedback I will answer this part. Thank you. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Monday, January 4, 2021 5:02:24 PM WET Jean-Marc Lasgouttes wrote: > It should be fixed now at 69eb262721b445, a wildcard was missing. > > Please test when you have the occasion. > > JMarc Actually I went the other way, I brought the big brother to the fight. :-) I am now using gcc9 to compile the code in epel7. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Change LyX release numbering to Semantic Versioning
On Monday, January 11, 2021 10:58:48 PM WET Joel Kulesza wrote: > Regarding semantic versioning: I feel like LyX already (arguably) uses that. > The argument I imagine: it's not clear what prompted moving from version > 1->2, What is the rationale of the number change? I have been bugging the mailing list ever since 0.12. :-) And that worked because we changed to version 1.0 (Feb 1999). In the case of what prompt the change from version 1 to 2 you can search in the mailing list. The changed occurred mostly at this time https://marc.info/?l=lyx-devel=12651045747=2 FWIW this was January-February 2010. In particular the 1.5 release where we changed to Unicode/UTF-8 it was in a sense a fundamental change. > but a Python-based conversion script manages forward/backward > compatibility in such a way that I regard the "API" as unchanging with the > various changes that underpin 2.4.0 (maybe I'm mistaken). I would imagine > a change from 2->3 if, for example, the .lyx file migrated irreversibly > from what it is now to XML. Otherwise, as JMarc noted once I was already > composing this, the "API" is pretty stable. We are, and try very hard to be, backwards compatible, but we are in no way forward compatible. I have been very clear since the begin of lyx2lyx we should be able to read perfectly what previous versions LyX version wrote. If for some reason that does not happen we have a bug. The conversion of the lyx file format to previous releases works on a best basis level but there are changes that are impossible to replicate in a general way. They do work most of the time but it is impossible to have them work correctly every time. The second law of thermodynamics and the arrow of the time... FWIW this is the list of API breaks that we had previously is: ... 0.6.0 0.8.0 0.10.0 0.12.0 1.0.0 1.1.0 1.1.5 1.1.6.0 1.1.6.3 1.2.0 1.3.0 1.4.0 1.5.0 1.6.0 2.0.0 2.1.0 2.2.0 2.3.0 The version that I placed is the first release of the cycle. lyx2lyx appeared after 1.2 and with it we had a way to make a more regular changes. After that such as it was the first number is irrelevant. BTW, do you know that at some point the file format was a real number, in the bank format? What I am proposing is to change to a saner and more predictable model, either the semantic version or the scheme used by several gnu projects, like at least gcc and octave. This is similar to the semantic version with one exception. In order to give an example suppose that we decide to follow that scheme an so the next version is LyX 3. The development version, unreleased version is 3.0.0. As soon as the first test version is released it gets the 3.0.1, the next one is 3.0.2 and so on. When the release candidates stage is over and a stable version is released as LyX 3.1. If a micro release is required then it goes to 3.1.1. The usual stable releases that we do will be 3.2, 3.3, 3.4... In short this scheme is similar to the semver scheme with the exception that releases where the second number is zero are reserved for development/ stabilizing versions. What I like in this scheme is that there is no need to place other symbols in releases to convey its meaning. -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Virtual meeting summary (2021-01-11)
Hi, we have met virtually on Monday, 2021-01-11. A short summary of the major points discussed can be found here: https://wiki.lyx.org/Devel/Meeting2021-01-11 For those who were not able to attend feel free to ask question if the summary is too terse. Personally I think that the meeting was a success and part of it can be seen from the activity in this list towards the next stable release. As Jean-Marc said the face-to-face meetings are more productive, when possible, but this has the advantage of bringing people from more places/time zones. :-) I think that we should repeat this meeting (say in 6-8 weeks) in order to assess the evolution of the stable release. Anyone interested is welcome to participate. Thanks to Pavel for chairing the meeting and for all the participants for IMHO a very productive meeting. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Reduce the amount of needed boost headers
On Friday, December 11, 2020 8:14:59 PM WET Richard Kimberly Heck wrote: > I'm not really competent, either. But if there were going to be > problems, I think we would see them fairly quickly. Maybe it would be a > good time, after this were committed, to do another alpha-ish release. > > Riki +1 It would be nice to change the date even if it an alpha version. In About LyX->Version it is weird to get "Version 2.4.0dev (Saturday, February 24, 2018)". -- 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 Monday, February 1, 2021 2:42:43 AM WET Thibaut Cuvelier wrote: > More generally, what about the other patches? Are formatting changes > considered risky? What about Joel's suggestions? My issue is not about the formatting changes, I can live with them even if in some cases I think that it is a matter of taste. The example about documentation strings is striking, why do I need triple quotes if the documentation string will only span a single line? My main doubt, that I still did not get any feedback, comes from the regular expression changes. Those are in no way formatting changes... And even if the current code is faulty, i.e. it works by accident, the proposed changes are wrong. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Sunday, January 31, 2021 12:12:41 PM WET Enrico Forestieri wrote: > Does the attached patch work for you? Yes. Without the patch "make check" fails, with the patch it works. Thank you. :-) -- 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 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 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: LyX 2.4.0-alpha1
On Sunday, January 31, 2021 6:56:31 AM WET Liviu Andronic wrote: > Any idea what's wrong? I'm not sure if maybe there are some new > dependencies for 2.4 I should take into account or if maybe a specific > compiler flag is needed. > > > Thank you, > Liviu I am looking into it. Note that I am building LyX with RHEL-7 that predates Bionic. I have reviewed the spec files and there are no changes in the build requirements between 2.3 and 2.4. I will look in the log file you referred to see if I get any clue and I will report it later. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Sunday, January 31, 2021 6:56:31 AM WET Liviu Andronic wrote: > I've tried building Alpha 1 on Bionic but compilation ends up with this > error: > > g++ -fPIC -O2 -std=c++17 -std=c++17 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -Wl,-z,defs -Wl,--as-needed > -Wl,-Bsymbolic-functions -Wl,-z,relro -o check_convert > tests/check_convert.o tests/dummy_functions.o tests/boost.o > liblyxsupport.a -lQt5Core -lmythes-1.2 -laspell -lmagic > /usr/bin/ld: liblyxsupport.a(checksum.o): undefined reference to symbol > 'crc32' //lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing > from command line > collect2: error: ld returned 1 exit status This fails because there is a missing -lz in the g++ call. This is strange because it is missing in support but is present in tex2lyx (immediately above). Even more stranger I also get this error while compiling in: https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-x86_64/01858213-lyx-devel/build.log.gz All the build logs can be found at: https://download.copr.fedorainfracloud.org/results/jamatos/lyx-devel/epel-7-x86_64/01858213-lyx-devel/ I get the error and yet the compile does not stop as the error is ignored... (scratch head) OK, I found it. We (purposely) ignore errors in the test stage, this is why the build proceeds. This is probably a remnant from previous versions. So the summary is that the compile only fails on the "make check" stage. The package built fine. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0-alpha1
On Sunday, January 31, 2021 10:04:13 AM WET José Abílio Matos wrote: > So the summary is that the compile only fails on the "make check" stage. The > package built fine. After this clue I searched on the logs of all architectures and the error is also present there. Comparing the output with the latest build of lyx-2.3 with gcc-11 I see that the problem is not present there: https://kojipkgs.fedoraproject.org//packages/lyx/2.3.6.1/2.fc34/data/logs/ x86_64/build.log So you are right that we only find this issue in lyx-2.4 and not in lyx-2.3. Although the warning are scarier there like the violation of the "One Definition Rule" in C++. So I suspect that to fix this in the autotools framework we need to link with libz on the check stage. How to this is out of my abilities. :-) Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
On Monday, May 24, 2021 8:18:31 PM WEST Richard Kimberly Heck wrote: > Hi, all, > > I have put tarballs for beta 1 here: > > https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp > =sharing > > I need to get my IP updated with our FTP people before I can upload > again to ftp.lyx.org. Usually that does not take too long. In any event, > please prepare binaries, and I'll release later this week. > > Riki I have built for Centos-7 and 8 and for Fedora 32-35 (35 being the development version). All the builds succeeded and are available at the usual place: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Noweb.lyx: fix a few mistakes from old lyx2lyx
On Thursday, June 3, 2021 12:58:23 AM WEST Scott Kostyshak wrote: > commit 8c5b58a3f83457913579423cc313698a3559a7b4 > Author: Scott Kostyshak > Date: Wed Jun 2 20:03:48 2021 -0400 > > Noweb.lyx: fix a few mistakes from old lyx2lyx > > In fb034884 I made some manual changes to documents that weren't > correctly converted by lyx2lyx (from ERT to Chunk insets) but I left > a "@" inside a chunk, which ended it prematurely and caused > incorrect output. > > This current commit also cleans up a few other things in the > document. > > Thanks to Kornel for catching this. Hi Scott, do you have the original file to fix the issue at the source, i.e. in lyx2lyx. Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Wednesday, February 10, 2021 12:48:17 PM WET Thibaut Cuvelier wrote: > @José : reconfiguring LyX does not solve the problem. It really looks like > it cannot find Python. We did not change the python detection code since alpha-1... :-( -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Tuesday, February 9, 2021 10:09:27 AM WET Andrew Parsloe wrote: > I've attached the output from the messages pane (with All debug messages > set) resulting from when I click on the new document icon. (If this is > not sufficient, then Yes, I can run LyX from the command line. What > arguments should be used?) > > Andrew Hi Andrew, do the problems go away if you run/select: Tools->Reconfigure Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4 Alpha 2
On Friday, February 5, 2021 10:24:23 PM WET Richard Kimberly Heck wrote: > Hi, all, > > I've put tarballs for Alpha 2, built from f4003593, here: > > http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/ > > This includes the latest epub export stuff. > > Please prepare such binaries as it makes sense to release. > > As said previously, we did not get many serious bug reports from alpha > 1. So if this goes well also we can move at the next stage to feature > freeze and beta 1. > > Riki Hi Riki, one small note to help poor packagers, like me in this role :-) , it would be nice for the package to have a consistent name between releases. For alpha1 the directory was called "lyx-2.4.0-alpha1" (OK and the usual procedure) while for alpha 2 it was called "lyx-2.4.0dev". I know that this is a small detail. :-) Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Thursday, February 11, 2021 4:02:19 PM WET Yu Jin wrote: > Will be pointless imo, it's not the script's fault that python is not found. > The fault is to be searched in the part of code which adds the prefix path > to the environment, which part would that be? After all when installing, > the installer adds the prefix path to its environment too on runtime while > installing and then calls the script, it is successful then. Does Tools->Reconfigure works after adding the python path in the environment variable? I expect it to work. If it works that means that the configure.py changes are not the culprit. Eugene, could it be some change in the windows installer between alpha 1 and alpha 2? Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Emergency-dialog options
On Thursday, April 1, 2021 7:56:16 PM WEST Pavel Sanda wrote: > When we disable multithreading, the crashes are gone. > The downside is that comparison can not be canceled while running. > > Attached the final patch. If no objections are raised I'll commit. > > Pavel Please do, this is one area that I like in LyX. Thank you for your work on this specific issue that it is always hard to tackle. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Zoom factor does not show up correctly initially
On Friday, March 12, 2021 3:03:03 PM WET José Abílio Matos wrote: > On Friday, March 12, 2021 1:55:22 PM WET Jürgen Spitzmüller wrote: > > Can you tell me what Qt theme this is? > > > > Jürgen > > Breeze Dark BTW this how it looks like after increasing or decreasing the zoom factor. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Zoom factor does not show up correctly initially
On Friday, March 12, 2021 3:31:45 PM WET Jürgen Spitzmüller wrote: > Thanks. Fixed. > > Jürgen Thank you after the patch the problem is gone. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Zoom factor does not show up correctly initially
On Friday, March 12, 2021 1:55:22 PM WET Jürgen Spitzmüller wrote: > Can you tell me what Qt theme this is? > > Jürgen Breeze Dark -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Command line argument "-dbg all" does not seem to work
On Monday, March 15, 2021 2:39:47 PM WET Pavel Sanda wrote: > I had the same thought, this issue happens for me regularly. > > Pavel It happens to me as well. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Zoom factor does not show up correctly initially
I am not sure if this is already reported. When LyX launches the zoom factor "100%" is not seen initially as it can be seen in the attached figure. After changing it and having it redrawn every looks normal and crispy. :-) So the issue is on start. After interacting with it the percentage shows as it should. Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Zoom factor does not show up correctly initially
On Friday, March 12, 2021 11:24:55 AM WET José Abílio Matos wrote: > So the issue is on start. After interacting with it the percentage shows as > it should. In this context interacting means changing the zoom factor, that is "zoom in" and then "zoom out", after that it shows correctly. Nice touch BTW. Thank you. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Graceful handling of pref conversion failures
On Wednesday, February 17, 2021 11:34:23 AM WET Pavel Sanda wrote: > Hi, > > when pref conversion routines fail you are greeted on terminal with > > LyXRC.cpp (260): Conversion failed for /home/lyx/.lyx/preferences > Warning: Could not read configuration file > > Error while reading the configuration file > preferences. > Please check your installation. > > and no GUI response. This must be totally confusing for users who > just click on icons, because launch will fail without any visible > feedback for them. > > I am not sure what should be our response - just issue warn dialog > and exit or launch lyx with generic settings and some warning on top > of that. Ideas? > > I even think this was raised some time ago, but as of now not fixed > in the master. > > Pavel Pavel do you know if this issue as a tracker issue assigned? Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Meet per-document spelling dictionaries (fixes #86 [sic!])
On Saturday, March 6, 2021 5:52:53 PM WET Jean-Marc Lasgouttes wrote: > Don't tempt me. Or a flutter frontend? > > JMarc I suggest instead a probably less known toolkit: xforms. It is a small code base but the mailing list is still active, the last messages are from last December. :-D -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
On Monday, February 15, 2021 3:25:45 PM WET Scott Kostyshak wrote:
> +1
>
> Thanks for taking a look, José.
>
> Scott
OK. I have lots of issues on hand but at least this is funny. :-)
One option would be to use some kind of string formatting. Actually since
curly braces are usually not used in OS we could use the string format syntax
(that is also used in C++20 format). One example would be:
\converter pdf4 pdf8 "{python} $$s/scripts/convert_pdf.py $$i $$o ebook"...
The lyx could convert internally {python} to the python path. Since lyx
already has this information, or else it would not call configure.py
If you do not like this option one in the same line as the other
interpolations that we apply is to use $${python}.
The other option is to replace this in configure.py like in the following
patch that I have not yet tested.
What do you think?
--
José Abíliodiff --git a/lib/configure.py b/lib/configure.py
index 43073e901d..4e08ef6776 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -29,7 +29,10 @@ formatter = logging.Formatter('%(message)s') # only print out the message itself
console.setFormatter(formatter)
logger = logging.getLogger('LyX')
logger.addHandler(console)
-
+interpreter = sys.executable
+if interpreter == '':
+interpreter = "python"
+
def quoteIfSpace(name):
" utility function: quote name if it contains spaces "
if ' ' in name:
@@ -52,7 +55,7 @@ def addToRC(lines):
add newline at the end of lines.
'''
if lines.strip():
-writeToFile(outfile, lines + '\n', append = True)
+writeToFile(outfile, lines.format(python=interpreter) + '\n', append = True)
logger.debug('Add to RC:\n' + lines + '\n\n')
@@ -653,7 +656,7 @@ def checkLatex(dtl_tools):
if dtl_tools:
# Windows only: DraftDVI
addToRC(r'''\converter latex dvi2 "%s" "latex,hyperref-driver=dvips"
-\converter dvi2 dvi"python -tt $$s/scripts/clean_dvi.py $$i $$o" ""''' % LATEX)
+\converter dvi2 dvi"{python} $$s/scripts/clean_dvi.py $$i $$o" ""''' % LATEX)
else:
addToRC(r'\converter latex dvi"%s" "latex,hyperref-driver=dvips"' % LATEX)
# no latex
@@ -943,7 +946,7 @@ def checkConverterEntries():
checkProg('an HTML -> LaTeX converter', ['html2latex $$i', 'gnuhtml2latex',
'htmltolatex -input $$i -output $$o', 'htmltolatex.jar -input $$i -output $$o'],
rc_entry = [ r'\converter html latex "%%" ""',
- r'\converter html latex "python -tt $$s/scripts/html2latexwrapper.py %% $$i $$o" ""',
+ r'\converter html latex "{python} $$s/scripts/html2latexwrapper.py %% $$i $$o" ""',
r'\converter html latex "%%" ""',
r'\converter html latex "%%" ""', '' ])
#
@@ -964,8 +967,8 @@ def checkConverterEntries():
['elyxer.py --html --nofooter --unicode --directory $$r $$i $$o', 'elyxer --html --nofooter --unicode --directory $$r $$i $$o'],
rc_entry = [ r'\converter lyx word "%%" ""' ])
if elyxer.find('elyxer') >= 0:
- addToRC(r'''\copierhtml "python -tt $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
- addToRC(r'''\copierwordhtml "python -tt $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
+ addToRC(r'''\copierhtml "{python} $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
+ addToRC(r'''\copierwordhtml "{python} $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
else:
# search for HTML converters other than eLyXer
# On SuSE the scripts have a .sh suffix, and on debian they are in /usr/share/tex4ht/
@@ -974,24 +977,24 @@ def checkConverterEntries():
'latex2html -no_subdir -split 0 -show_section_numbers $$i', 'hevea -s $$i'],
rc_entry = [ r'\converter latex html "%%" "needaux"' ])
if htmlconv.find('htlatex') >= 0 or htmlconv == 'latex2html':
-addToRC(r'''\copierhtml "python -tt $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
+addToRC(r'''\copierhtml "{python} $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
else:
-addToRC(r'''\copierhtml "python -tt $$s/scripts/ext_copy.py $$i $$o"''')
+addToRC(r'''\copierhtml "{python} $$s/scripts/ext_copy.py $$i $$o"''')
path, htmlconv = checkProg('a LaTeX -> HTML (MS Word) converter', ["htlatex $$i 'html,word' 'symbol/!' '-cvalidate'",
"htlatex.sh $$i 'html,word' 'symbol/!' '-cvalidate'",
"/usr/share/tex4ht/htlatex $$i 'html,word' 'symbol/!' '-cvalidate'"],
rc_entry = [ r'\converter latex wordhtml "%%" "needaux"' ])
if htmlconv.find('htlatex') >= 0:
-addToRC(r'''\copierwordhtml "python -tt $$s/scripts/ext_copy.py -e html,png,css $$i
Re: [LyX/master] By report autoconf 2.71 works, 2.70 is known to have compatibility issues.
On Monday, February 22, 2021 10:13:33 AM WET Pavel Sanda wrote: > Anyone around with 2.70 installed to check whether the reported issues > affect us? (Not a big deal, no sane distribution will deliver 2.70 with > those issues as a default). > > Pavel Just as you said. In Fedora we will jump from 2.69 to 2.71. So I do not have 2.70 at hand. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: SIGSEGV on master when exporting MergedManuals.lyx in GUI
On Tuesday, April 13, 2021 5:17:24 PM WEST Scott Kostyshak wrote: > I get the following terminal messages followed by a SIGSEGV when opening and > viewing MergedManuals.lyx in the GUI: > > QSocketNotifier: Invalid socket 16 and type 'Read', disabling... > > Does anyone else see this on master? > > Scott For me it is socket 10. :-) LyX does not crash but it enters an infinite cycle (read that after 5 minutes it continues to output that line) sending that line to stderr. I am not sure if I am patient enough to wait for infinity before recovering LyX's control. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Friday, February 12, 2021 3:01:19 PM WET Thibaut Cuvelier wrote: > Actually, it looks like \e is a GCC-only extension that is not > well-understood by MSVC. The attached patch solves the problem for me by > replacing \e by another nonprintable character. You are right \e is a gcc extension: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions https://gcc.gnu.org/onlinedocs/gcc/Character-Escapes.html#Character-Escapes -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Friday, February 12, 2021 3:01:19 PM WET Thibaut Cuvelier wrote: > Actually, it looks like \e is a GCC-only extension that is not > well-understood by MSVC. The attached patch solves the problem for me by > replacing \e by another nonprintable character. @Enrico what do you think about this change. I think that it should be safe to apply. Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4 Alpha 3
On Sunday, February 14, 2021 7:45:37 PM WET Richard Kimberly Heck wrote: > With the Windows problem fixed, we need another alpha. So it's here: > > http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/ > > Please prepare binaries. I have built packages for EPEL 7 and 8 and for Fedora 32-34 and rawhide (to be Fedora 35). Fedora 34 is still a development branch. I worked without any changes for all architectures: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ I still need to integrate the new dependencies on xlstproc but with classes starting today in online only mode that is the best I can do at the moment. > Riki > > PS I did remember to change the version in configure.ac this time. Thank you. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Transform simple search dialog to dock widget (#2625)
On Sunday, February 14, 2021 6:33:03 PM WET Jean-Marc Lasgouttes wrote:
> Am I right that it
> is the same to write:
> BufferView const * bv_ {};
> BufferView const * bv_ = {};
> BufferView const * bv_ = {nullptr};
> BufferView const * bv_ = nullptr;
>
> Why do we need to have all these possibilities? In particular the first
> one is weird to me.
IIRC the first option without the equal sign replaces the notation where
parenthesis are used:
BufferView const * bv_ {nullptr};
instead of
BufferView const * bv_ (nullptr);
Then it becomes evident that are not using a function call here.
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
On Monday, February 15, 2021 4:27:40 AM WET Richard Kimberly Heck wrote:
> We have a Python detection routine, find_python_binary(), so it could be
> modified to check for those commands explicitly. I'm reluctant to touch
> that code myself though.
The detection code in LyX is working correctly, it works if the name is not
python. The code searches for python39 or python3.9 or ...
The issue that Scott is raising is different. The problem is that configure.py
always issue a "python" as the python name. When we get here the lyx detection
code already worked correctly.
I had thought previously about this and I have an idea to fix this.
"""
import os, sys
print(os.path.basename(sys.executable))
"""
so the idea is to replace "python" by os.path.basename(sys.executable) in all
the calls on configure.py.
This code is general, since it takes care of the directory separators, and it
should work everywhere.
Funnily enough the function rescanTeXFiles (line 1920) already does that. :-)
For the next stable release if we assume a minimum of python 3.6 we can use
the f-strings (formatted in case you wonder :-) ) and the code could be
simply.
python = os.path.basename(sys.executable);
...
print (f"{python}")
so that the content of variable python is replaced inside the function...
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4 alpha2 failing on windows 10
On Thursday, February 11, 2021 7:53:36 PM WET Thibaut Cuvelier wrote: > I would guess it is os::find_python_binary. But it has not been touched in a > long time. > > It's highly likely that it does. On Windows, the first thing this function > checks is `py -3`, but I haven't seen any py binary in a long time > (although I've been using the Anaconda Python distribution for quite some > time). Since we require python to run maybe it would make sense to add the information that comes from os::find_python to "Help -> About LyX". What do you think? (this is meant to every one not just Thibaut) :-) Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: python warning
On Sunday, 11 July 2021 17.11.28 WEST Pavel Sanda wrote: > Hi, > > this is what I see after make install: > > DeprecationWarning: the imp module is deprecated in favour of importlib; > see the module's documentation for alternative uses > > Perhaps some pythonst should check... > > Pavel > > log: > make[2]: Entering directory '/tmp/lyx-2.4.0dev/lib/lyx2lyx' > make[2]: Nothing to be done for 'install-exec-am'. > /usr/bin/mkdir -p '/tmp/gugi/share/lyx/lyx2lyx' > /usr/bin/install -c -m 644 lyx2lyx lyx2lyx_version.py lyx2lyx_lang.py > generate_encoding_info.py parser_tools.py lyx2lyx_tools.py > unicode_symbols.py LyX.py lyx_0_06.py lyx_0_08.py lyx_0_10.py lyx_0_12.py > lyx_1_0.py lyx_1_1.py lyx_1_1_5.py lyx_1_1_6_0.py lyx_1_1_6_3.py lyx_1_2.py > lyx_1_3.py lyx_1_4.py lyx_1_5.py lyx_1_6.py lyx_2_0.py lyx_2_1.py > lyx_2_2.py lyx_2_3.py lyx_2_4.py profiling.py test_parser_tools.py > '/tmp/gugi/share/lyx/lyx2lyx' -c:2: DeprecationWarning: the imp module is > deprecated in favour of importlib; see the module's documentation for > alternative uses Byte-compiling python modules... > lyx2lyx_version.pylyx2lyx_lang.pygenerate_encoding_info.pyparser_tools.pylyx > 2lyx_tools.pyunicode_symbols.pyLyX.pylyx_0_06.pylyx_0_08.pylyx_0_10.pylyx_0_ > 12.pylyx_1_0.pylyx_1_1.pylyx_1_1_5.pylyx_1_1_6_0.pylyx_1_1_6_3.pylyx_1_2.pyl > yx_1_3.pylyx_1_4.pylyx_1_5.pylyx_1_6.pylyx_2_0.pylyx_2_1.pylyx_2_2.pylyx_2_3 > .pylyx_2_4.pyprofiling.pytest_parser_tools.py Byte-compiling python modules > (optimized versions) ... > lyx2lyx_version.pylyx2lyx_lang.pygenerate_encoding_info.pyparser_tools.pylyx > 2lyx_tools.pyunicode_symbols.pyLyX.pylyx_0_06.pylyx_0_08.pylyx_0_10.pylyx_0_ > 12.pylyx_1_0.pylyx_1_1.pylyx_1_1_5.pylyx_1_1_6_0.pylyx_1_1_6_3.pylyx_1_2.pyl > yx_1_3.pylyx_1_4.pylyx_1_5.pylyx_1_6.pylyx_2_0.pylyx_2_1.pylyx_2_2.pylyx_2_3 > .pylyx_2_4.pyprofiling.pytest_parser_tools.py Thank you Pavel. This is related with out use of __import__: https://docs.python.org/3/library/functions.html#__import__ The alternative is to use https://docs.python.org/3/library/importlib.html#importlib.import_module I will do it for the next development cycle when we drop python 2 support. importlib was introduced in Python 3.1. It is not that it can be done now, the issue is that we need to ensure that this works correctly in Python 2. Honestly I suspect that the task is simple but since this is a deprecation warning I will ignore it for this cycle. Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: DeprecationWarning when installing master
On Monday, 18 October 2021 12.29.49 WEST Jean-Pierre Chrétien wrote: > Le 18/10/2021 à 13:22, Jean-Pierre Chrétien a écrit : > > Dear developers > > > > I get this : > > > > $ sudo make install-strip >>make.log > > -c:2: DeprecationWarning: the imp module is deprecated in favour of > > importlib; see the module's documentation for alternative uses I saw that and decided to ignore it for lyx2.4. I intend to get rid of it after lyx 2.4 is out and move us finally to python 3 only. So it is not forgotten it just does not pay off all the work required to test with python 2 now. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Performance regression in export to LaTeX?
On Sunday, 19 December 2021 17.15.19 WET Jürgen Spitzmüller wrote: > The first thing to check, since this is a 2.3.x file, is how much time > is taken by lyx2lyx. If this proves to be a problem we can speed lyx2lyx code (using profiling to identify the bottlenecks). -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
On Saturday, 25 December 2021 18.32.21 WET Scott Kostyshak wrote:
> On Sun, Oct 31, 2021 at 12:58:19PM -0400, Scott Kostyshak wrote:
Hi Scott,
I find you choice of dates very convenient. :-)
https://journeys.dartmouth.edu/folklorearchive/2016/11/12/halloween-and-christmas/
“Why do programmers always mix up Halloween and Christmas?”
“Because Oct 31 = Dec 25.”
> Bump.
>
> Scott
Regarding the problem at hand, as an example, my suggestion is to change:
\converter pdf4 pdf8 "python $$s/scripts/convert_pdf.py $$i $$o ebook"
to
\converter pdf4 pdf8 "$${python} $$s/scripts/convert_pdf.py $$i $$o ebook"
The idea is to use the converter code, e.g. the $$i $$o ..., and add there the
substitution from $${python} to the python path that we have already
determined in os::find_python.
Before doing that my question is if others are comfortable with this plan.
The idea of using that syntax is to be in the same spirit as the ones we
already have:
$$i
$$o
$$s
and so on.
The idea of using the curly brackets is similar to what shell (almost all the
variants) does.
I also intend to add the -t to the command invocation, and thus removing all
those from configure.py.
Best regards,
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
On Tuesday, 28 December 2021 12.33.57 WET Stephan Witt wrote: > The LyX tasks here are IMO: > 1. Assure the detected python3 is used consequently. This is not the case > ATM. > 2. Document the meaning of the prompts the LyX user is seeing on > Monterey. > 3. Provide a working python3 or give appropriate feedback on > first start about users option to install python3. > > AFAIK, José Abílio is working on a solution for 1. I’m able to help with the > Mac part of the problem. I am not working on 1, the issue that I am working is a bit different, although related. In the case of mac we can What I suggest is to use by default the latest python version available in the system. As it is now we search for a python version and stick with it. What I propose is to test the different versions available and pick the latest. Python 3 has been tested extensively and so it is ready to be the default option. > Regarding the point 3 - Apples recommendation to bundle python with LyX > (49764202) - I’m not sure if this is a real option. The Windows package > contains python, IMO. So it is possible. But is it clever? I don’t like the > solution to point the user to homebrew or macports to install python. Too > much terminal work, IMO. > > What do others think about the situation? How do you deal with the latex installation in mac? > BR, Stephan -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Why do we add converters in frontends GuiPrefs.cpp?
Hi all,
while searching in order to solve the python issues, I searched for all the
occurrences of "$$o" in src/
$ grep -r '$$o' src/*
The only case where I was surprised were the case of frontends GuiPrefs.cpp:
$ grep '$$o' src/frontends/qt/GuiPrefs.cpp
dviCB->addItem("xdvi -sourceposition '$$n:\\ $$t' $$o");
dviCB->addItem("yap -1 -s \"$$n $$t\" $$o");
dviCB->addItem("okular --unique \"$$o#src:$$n $$f\"");
dviCB->addItem("synctex view -i $$n:0:$$t -o $$o -x \"evince -i %
{page+1} $$o\"");
pdfCB->addItem("CMCDDE SUMATRA control [ForwardSearch(\\\"$$o\\\",\\
\"$$t\\\",$$n,0,0,1)]");
pdfCB->addItem("SumatraPDF -reuse-instance \"$$o\" -forward-search \"$
$t\" $$n");
pdfCB->addItem("synctex view -i $$n:0:$$t -o $$o -x \"xpdf -raise -
remote $$t.tmp $$o %{page+1}\"");
pdfCB->addItem("okular --unique \"$$o#src:$$n $$f\"");
pdfCB->addItem("qpdfview --unique \"$$o#src:$$f:$$n:0\"");
pdfCB->addItem("synctex view -i $$n:0:$$t -o $$o -x \"evince -i %
{page+1} $$o\"");
pdfCB->addItem("/Applications/Skim.app/Contents/SharedSupport/
displayline $$n $$o $$t");
Does any one knows why we are injecting these calls manually there?
Best regards,
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Status of Master?
On Sunday, 2 January 2022 21.36.22 WET Richard Kimberly Heck wrote:
> On 1/2/22 16:15, Pavel Sanda wrote:
> > On Mon, Dec 27, 2021 at 11:29:08AM -0500, Richard Kimberly Heck wrote:
> >> Where do people think things are now?
> >
> > If Jose is close to finish ${python} patch it would be good to have it
> > in the release. I believe this will trigger bunch of changes needed
> > for various distro maintainers and we should get feedback rather soon.
>
> OK, let me cc José on that.
>
> Riki
I have been thinking about this in the last week.
One option would be the one that follows attached. This works but it is not
nice in the sense that it works too soon. That means in particular that the $$
{python} is not exposed to the outside.
Another option would be instead of doing this in LyXRC.cpp to do it in
Converter.cpp and Mover.cpp where supposedly the commands are used. Then we
could expose this to users.
What am I missing?
I wish a happy new year to all. :-)
--
José Abíliodiff --git a/lib/configure.py b/lib/configure.py
index 7d9b61c3b1..17ef38fc6d 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -653,7 +653,7 @@ def checkLatex(dtl_tools):
if dtl_tools:
# Windows only: DraftDVI
addToRC(r'''\converter latex dvi2 "%s" "latex,hyperref-driver=dvips"
-\converter dvi2 dvi"python -tt $$s/scripts/clean_dvi.py $$i $$o" ""''' % LATEX)
+\converter dvi2 dvi"$${python} $$s/scripts/clean_dvi.py $$i $$o" ""''' % LATEX)
else:
addToRC(r'\converter latex dvi"%s" "latex,hyperref-driver=dvips"' % LATEX)
# no latex
@@ -943,7 +943,7 @@ def checkConverterEntries():
checkProg('an HTML -> LaTeX converter', ['html2latex $$i', 'gnuhtml2latex',
'htmltolatex -input $$i -output $$o', 'htmltolatex.jar -input $$i -output $$o'],
rc_entry = [ r'\converter html latex "%%" ""',
- r'\converter html latex "python -tt $$s/scripts/html2latexwrapper.py %% $$i $$o" ""',
+ r'\converter html latex "$${python} $$s/scripts/html2latexwrapper.py %% $$i $$o" ""',
r'\converter html latex "%%" ""',
r'\converter html latex "%%" ""', '' ])
#
@@ -964,8 +964,8 @@ def checkConverterEntries():
['elyxer.py --html --nofooter --unicode --directory $$r $$i $$o', 'elyxer --html --nofooter --unicode --directory $$r $$i $$o'],
rc_entry = [ r'\converter lyx word "%%" ""' ])
if elyxer.find('elyxer') >= 0:
- addToRC(r'''\copierhtml "python -tt $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
- addToRC(r'''\copierwordhtml "python -tt $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
+ addToRC(r'''\copierhtml "$${python} $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
+ addToRC(r'''\copierwordhtml "$${python} $$s/scripts/ext_copy.py -e html,png,jpg,jpeg,css $$i $$o"''')
else:
# search for HTML converters other than eLyXer
# On SuSE the scripts have a .sh suffix, and on debian they are in /usr/share/tex4ht/
@@ -974,17 +974,17 @@ def checkConverterEntries():
'latex2html -no_subdir -split 0 -show_section_numbers $$i', 'hevea -s $$i'],
rc_entry = [ r'\converter latex html "%%" "needaux"' ])
if htmlconv.find('htlatex') >= 0 or htmlconv == 'latex2html':
-addToRC(r'''\copierhtml "python -tt $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
+addToRC(r'''\copierhtml "$${python} $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
else:
-addToRC(r'''\copierhtml "python -tt $$s/scripts/ext_copy.py $$i $$o"''')
+addToRC(r'''\copierhtml "$${python} $$s/scripts/ext_copy.py $$i $$o"''')
path, htmlconv = checkProg('a LaTeX -> HTML (MS Word) converter', ["htlatex $$i 'html,word' 'symbol/!' '-cvalidate'",
"htlatex.sh $$i 'html,word' 'symbol/!' '-cvalidate'",
"/usr/share/tex4ht/htlatex $$i 'html,word' 'symbol/!' '-cvalidate'"],
rc_entry = [ r'\converter latex wordhtml "%%" "needaux"' ])
if htmlconv.find('htlatex') >= 0:
-addToRC(r'''\copierwordhtml "python -tt $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
+addToRC(r'''\copierwordhtml "$${python} $$s/scripts/ext_copy.py -e html,png,css $$i $$o"''')
else:
-addToRC(r'''\copierwordhtml "python -tt $$s/scripts/ext_copy.py $$i $$o"''')
+addToRC(r'''\copierwordhtml "$${python} $$s/scripts/ext_copy.py $$i $$o"''')
# Check if LyXBlogger is installed
@@ -1015,9 +1015,9 @@ def checkConverterEntries():
xpath = 'none'
global java
if xsltproc != '':
-addToRC(r'\converter docbook5 epub "python $$s/scripts/docbook2epub.py none none \"' + xsltproc +
Re: Fwd: String/Bytes Problem in layout2layout.py
On Wednesday, 29 December 2021 14.52.29 WET Pavel Sanda wrote: > Jose, > > are the proposed changes sensible? > I remember there were flowing similar patches to python codebase before. The changes are reasonable for python 3. I am not so sure about python 2 (because we support it) although it seems likely. :-) We are using bytes here to avoid choosing an encoding, that it should be utf-8 for all layout files, if I am not mistaken. In lyx2lyx we do this in 2 passes, first we determine the encoding and then we use that information to read the correct encoding. Looking into further detail I would easily that the first part of the patch is correct (change "..." to b"..."). The second part where it changes sys.stdin to sys.stdin.buffer is probably incorrect: The similar code in 2.4 is: # Open files if options.input_file: source = open(options.input_file, 'rb') elif PY2: source = sys.stdin else: source = sys.stdin.buffer if options.output_file: output = open(options.output_file, 'wb') elif PY2: output = sys.stdout else: output = sys.stdout.buffer So this should be the right change, keep the previous form if PY2 (python 2 is used) else use the new call. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Status of Master?
On Sunday, 2 January 2022 23.52.37 WET José Abílio Matos wrote:
> Another option would be instead of doing this in LyXRC.cpp to do it in
> Converter.cpp and Mover.cpp where supposedly the commands are used. Then we
> could expose this to users.
This is the counterpart to the previous patch. The change in lib/configure.py
is the same.
Now instead of changing directly LyXRC.cpp I change the calls in the places
where they are used. If there are any places that need to be converted the
conversion is similar and immediate.
What do you think?
With this we ensure that we are calling always the same Python interpreter
from inside LyX.
--
José Abíliodiff --git a/src/Converter.cpp b/src/Converter.cpp
index 0578026be3..c00941d21f 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -60,7 +60,7 @@ string const token_orig_path("$$r");
string const token_orig_from("$$f");
string const token_encoding("$$e");
string const token_latex_encoding("$$E");
-
+string const token_python("$${python}");
string const add_options(string const & command, string const & options)
{
@@ -644,6 +644,7 @@ Converters::RetVal Converters::convert(Buffer const * buffer,
command = subst(command, token_orig_path, quoteName(onlyPath(orig_from.absFileName(;
command = subst(command, token_orig_from, quoteName(onlyFileName(orig_from.absFileName(;
command = subst(command, token_encoding, buffer ? buffer->params().encoding().iconvName() : string());
+ command = subst(command, token_python, os::python());
if (!conv.parselog().empty())
command += " 2> " + quoteName(infile2 + ".out");
@@ -684,11 +685,11 @@ Converters::RetVal Converters::convert(Buffer const * buffer,
if (res == Systemcall::KILLED) {
frontend::Alert::warning(
_("Converter killed"),
- bformat(_("The following converter was killed by the user.\n %1$s\n"),
+ bformat(_("The following converter was killed by the user.\n %1$s\n"),
from_utf8(command)));
return KILLED;
}
-
+
if (!real_outfile.empty()) {
Mover const & mover = getMover(conv.to());
if (!mover.rename(outfile, real_outfile))
@@ -713,7 +714,7 @@ Converters::RetVal Converters::convert(Buffer const * buffer,
if (res == Systemcall::KILLED) {
frontend::Alert::warning(
_("Converter killed"),
- bformat(_("The following converter was killed by the user.\n %1$s\n"),
+ bformat(_("The following converter was killed by the user.\n %1$s\n"),
from_utf8(command)));
return KILLED;
}
@@ -728,13 +729,13 @@ Converters::RetVal Converters::convert(Buffer const * buffer,
bformat(_("The conversion process was killed while running:\n%1$s"),
wrapParas(from_utf8(command;
return KILLED;
-}
+}
if (res == Systemcall::TIMEOUT) {
Alert::information(_("Process Timed Out"),
bformat(_("The conversion process:\n%1$s\ntimed out before completing."),
wrapParas(from_utf8(command;
return KILLED;
-}
+}
if (conv.to() == "program") {
Alert::error(_("Build errors"),
_("There were errors during the build process."));
diff --git a/src/Mover.cpp b/src/Mover.cpp
index a901d98b0f..16d225bfa7 100644
--- a/src/Mover.cpp
+++ b/src/Mover.cpp
@@ -63,6 +63,7 @@ bool SpecialisedMover::do_copy(FileName const & from, FileName const & to,
command = subst(command, "$$i", quoteName(from.toFilesystemEncoding()));
command = subst(command, "$$o", quoteName(to.toFilesystemEncoding()));
command = subst(command, "$$l", quoteName(latex));
+ command = subst(command, "$${python}", os::python());
Systemcall one;
return one.startscript(Systemcall::Wait, command) == 0;
diff --git a/src/graphics/PreviewLoader.cpp b/src/graphics/PreviewLoader.cpp
index de04e4db50..28a0e0fa52 100644
--- a/src/graphics/PreviewLoader.cpp
+++ b/src/graphics/PreviewLoader.cpp
@@ -34,6 +34,7 @@
#include "support/filetools.h"
#include "support/ForkedCalls.h"
#include "support/lstrings.h"
+#include "support/os.h"
#include "support/TempFile.h"
@@ -322,7 +323,7 @@ public:
string const file_name = os.str();
return make_pair(snippet, FileName(file_name));
}
-
+
private:
string const & to_format_;
string const & base_;
@@ -678,7 +679,7 @@ void PreviewLoader::Impl::startLoading(bool wait)
// The conversion command.
ostringstream cs;
- cs << pconverter_->command()
+ cs << subst(pconverter_->command(), "$${python}", os::python())
<< " " << quoteName(latexfile.toFilesystemEncoding())
<< " --dpi " << font_scaling_factor_;
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fwd: String/Bytes Problem in layout2layout.py
On Monday, 3 January 2022 14.55.53 WET Pavel Sanda wrote: > If I get that right the part of the "..." -> b"..." should be committed to > 2.4? > > Pavel Good point. Yes, it should (I thought that it already was) specially in order to be consistent with all the other code that already does that. The issue is that in Python 2 str (string type) does not has an encoding associated, later there was a new string type (unicode) where the string has an encode associated. In Python 3 strings become encoding aware and the previous strings were renamed bytes. So b"..." (bytes string) is a no-op in Python 2, because it corresponds to "...". Similarly u"..." (unicode string) is a no-op in Python 3 since it corresponds to "...". If you want I can take care of that, in 2.4, and see if there are cases where the conversion is missing. @Riki: is it possible to have a layout file such that the encoding is not utf-8? -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
On Tuesday, 4 January 2022 08.53.46 WET Enrico Forestieri wrote: > I disagree. It should return the first usable version found first in > PATH. The user has to be in control of what version has to be run, not > the software. I understand what you say, and I agree, but that is precisely what we are doing now. We are choosing the python path based on some criteria automatically. What I would like to have would be a way to configure this. Probably even if you do not expose this in the graphical interface, only on the preferences file. What do you think? -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Status of Master?
On Tuesday, 4 January 2022 10.56.51 WET Kornel Benko wrote:
> There is one:
> File 'preferences' is not updated, so I had to manually change occurrences
> of 'python', 'python3' and 'python -tt' to '$${python}'.
>
> The changed lines in preferences here:
> $ egrep python preferences
>
> \converter "docbook5" "epub2" "$${python} $$s/scripts/docbook2epub.py java
> none none none $$i $$o" ""
> \converter "pygr" "eps" "$${python} $$i $$o" ""
> \copier pdflatex "$${python} $$s/scripts/ext_copy.py -e pdf,aux -d $$i $$o"
>
> Kornel
You raise a good point. What should we do with current preferences?
I am not completly sure that you should do it automatically... Probably
checking for the canonical form "python -tt"?
If we decide to do it then probably the right path is add a new format and
change pref2pref.py in lib/scripts.
What is the general sentiment regarding this change in preferences?
Best regards,
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Why do we add converters in frontends GuiPrefs.cpp?
On Tuesday, 28 December 2021 13.07.19 WET José Abílio Matos wrote: > Does any one knows why we are injecting these calls manually there? Actually the title is wrong we are adding viewers and not converters, but the same question applies since they are already present in configure... -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fwd: String/Bytes Problem in layout2layout.py
On Monday, 3 January 2022 16.02.51 WET Pavel Sanda wrote:
> On Mon, Jan 03, 2022 at 03:16:47PM +0000, José Abílio Matos wrote:
> > If you want I can take care of that, in 2.4, and see if there are cases
> > where the conversion is missing.
>
> Please do, I suffer from ophidiophobia.
You keep insisting that the Norwegian Blue parrot is alive: :-D
https://en.wikipedia.org/wiki/Dead_Parrot_sketch
The name comes from the Monty Python's Flying Circus. :-)
In any case I found other cases where the code is wrong (like the BOM removal
that does not work) and that it does not give an error although it is wrong.
The patch follows attached since I do not have time to test it.
> > @Riki: is it possible to have a layout file such that the encoding is not
> > utf-8?
>
> The original reports most likely downloaded layouts referred in our wiki
> (https://wiki.lyx.org/Layouts/Layouts , LyXBook), so I guess that layout
> encoding is not in our hands.
No the issue is if LyX accepts, or not, other encoding that UTF-8. If not all
the care is useless. Looking to the similar pref2prefs.py we see that it
assumes utf-8.
> Pavel
--
José Abíliodiff --git a/lib/scripts/layout2layout.py b/lib/scripts/layout2layout.py
index 7e40bfbe12..88ada1213e 100644
--- a/lib/scripts/layout2layout.py
+++ b/lib/scripts/layout2layout.py
@@ -256,7 +256,7 @@ currentFormat = 95
# New textclass tag BibInToc
# Incremented to format 77, 6 August 2019 by spitz
-# New textclass tag PageSize (= default page size)
+# New textclass tag PageSize (= default page size)
# and textclass option PageSize (= list of available page sizes)
# Incremented to format 78, 6 August 2019 by spitz
@@ -354,7 +354,7 @@ def error(message):
def trim_bom(line):
" Remove byte order mark."
-if line[0:3] == "\357\273\277":
+if line[0:3] == b"\357\273\277":
return line[3:]
else:
return line
@@ -444,8 +444,8 @@ def convert(lines, end_format):
# for categories
re_Declaration = re.compile(b'^#\\s*\\Declare\\w+Class.*$')
re_ExtractCategory = re.compile(b'^(#\\s*\\Declare\\w+Class(?:\\[[^]]*?\\])?){([^(]+?)\\s+\\(([^)]+?)\\)\\s*}\\s*$')
-ConvDict = {"article": "Articles", "book" : "Books", "letter" : "Letters", "report": "Reports",
-"presentation" : "Presentations", "curriculum vitae" : "Curricula Vitae", "handout" : "Handouts"}
+ConvDict = {b"article": b"Articles", b"book": b"Books", b"letter": b"Letters", b"report": b"Reports",
+b"presentation": b"Presentations", b"curriculum vitae": b"Curricula Vitae", b"handout": b"Handouts"}
# Arguments
re_OptArgs = re.compile(b'^(\\s*)OptionalArgs(\\s+)(\\d+)\\D*$', re.IGNORECASE)
re_ReqArgs = re.compile(b'^(\\s*)RequiredArgs(\\s+)(\\d+)\\D*$', re.IGNORECASE)
@@ -615,7 +615,7 @@ def convert(lines, end_format):
continue
col = match.group(2)
if col == "collapsable":
-lines[i] = match.group(1) + "collapsible"
+lines[i] = match.group(1) + b"collapsible"
i += 1
continue
@@ -833,7 +833,7 @@ def convert(lines, end_format):
# Insert the required number of arguments at the end of the style definition
match = re_End.match(lines[i])
if match:
-newarg = ['']
+newarg = [b'']
# First the optionals (this is the required order pre 2.1)
if opts > 0:
if opts == 1:
@@ -1283,7 +1283,7 @@ def convert(lines, end_format):
if latextype == b"item_environment" and label.lower() == b"counter_enumi":
lines[labeltype_line] = re_LabelType.sub(b'\\1\\2\\3Enumerate', lines[labeltype_line])
# Don't add the LabelCounter line later
-counter = ""
+counter = b""
# Replace
#
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Status of Master?
On Sunday, 2 January 2022 21.36.22 WET Richard Kimberly Heck wrote: > OK, let me cc José on that. > > Riki I have a patch that it is mostly complete but I have one doubt. In src/support/ForkedCalls.cpp there is a comment that says: // Make sure that a V2 python is run, if available Does anyone remembers what does this means? Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
On Wednesday, 29 December 2021 10.38.38 WET Stephan Witt wrote: > In any case we should ensure the detected usable python is used > consequently. > > Stephan This should be done now. All the heuristics regarding Python detection is now placed in src/support/ os.cpp. In particular we can try use Python 3 by default and only use Python 2 as a last resort. Please test this to see if this works as intended. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fwd: String/Bytes Problem in layout2layout.py
On Monday, 3 January 2022 18.32.14 WET José Abílio Matos wrote:
> In any case I found other cases where the code is wrong (like the BOM
> removal that does not work) and that it does not give an error although it
> is wrong.
For future reference this is an issue that happens silently. In this case
Python's versatility comes to bite it.
Notice the following code:
line = "\357\273\277"
if line[0:3] == b"\357\273\277":
print ("BOM found")
This could will give different results in Python 2 and 3.
The problem is that in Python 2 "\357\273\277" and b"\357\273\277" have the
same type while in Python 3 they are different. That would not be a problem if
it were not for another feature of Python, it is possible to compare different
types and in that case the answer is naturally False.
The reason for this is to allow the comparison with None, that is usually used
as sentinel in lots of code.
This bug is insidious because the code seems to work, there are no errors as
those that led the original reporter to issue the proposed fix but the problem
is there. :-(
As far as I understand the problem is specific to comparisons, since all the
other operations will fail since we are using different types...
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Status of Master?
On Monday, 3 January 2022 22.40.05 WET Enrico Forestieri wrote: > If i remember correctly, if the command starts with "python -tt" then we > could be sure it was a command defined by us and we replaced that with > os::python(). The last was for sure invoking a Python 2, while the bare > python command could possibly invoke a Python 3. This was when we still did > not support Python 3 and wanted to avoid substituting a user command > with our invocation. All of this is now obsolete, I think. Thank you Enrico, that makes sense. I removed that transformation now. I have applied the changes that I have described during the previous week (i.e. last year). :-) Please test it to find any weak spots. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
On Friday, 31 December 2021 13.03.57 WET Stephan Witt wrote: > I’m curious how difficult it would be to ignore python2 and present a > message box for users to tell them how to get a python3 interpreter. > > BR, Stephan For now we always search for Python 3 before Python 2. We know what is the version that we are using. So that warn can be done, but then we probably only want to show it once, or at least have an option to turn it off. Probably the case you want to can be best done through documentation, no? -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
On Tuesday, 4 January 2022 07.16.52 WET Stephan Witt wrote: > Interestingly on my system the python3 is detected only if I install the > Python package from python.org. The python3 in /usr/bin is not tried? > Sorry, I didn’t read the code yet. It should according to the code in support/os.cpp. The logic is simple and follows some guidelines from python.org. For posix systems it first tries to see if "python3" can be found. If not try to run "python2" and if that does not work then returns "python". What do you see in Help -> About LyX? In my case I see "Python detected: python3 -tt". The code can be made more complete. E.g. previously we searched for python3* and python2* eventually I think that we can go back to something related. Instead of returning the first python that satisfies the requirement (minimum version) it should return the most recent version available (the best). My use case is e.g. Red Hat Enterprise Linux (and related). /usr/bin/python3 will point to the system python yet there could be available other more recent versions. This is similar to the compiler available, e.g. the default compiler in RHEL 7 default compiler is 4.7.x that is unable to compile LyX. Yet using devtools it is possible to install gcc-9 and that is more than capable to compile LyX. The same applies to the python versions available there. The minimum python version that we support is python 3.5 released more than 6 years ago that it has no longer any security fixes for more than 1 year. > > Probably the case you want to can be best done through documentation, no? > > Yes, at first this is the best option probably. > > My question for the future is how to act on next move of Apple. Neither I > know when it will happen nor I know what happens. They announced to remove > the preinstalled python altogether. ATM they provide python3 as wrapper. > It’s asking the user to download and install the Command Line Developer > Tools from Apple instead of doing anything useful. The exit status is 1. > > Currently LyX is using python (python2) and the warning info pops up once: > „LyX needs to be updated“. Obviously this is wrong now. Python3 needs to be > installed instead. > > So I’ll have to investigate further. > > Stephan Thank you. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Upgrade from buster to bullseye
On Monday, 8 November 2021 20.57.37 WET Pavel Sanda wrote: > This is actually not correct way how to solve this under bullseye. > "python" is gone for good and scripts should use either python2 > or python3 binary. > If you insist on using "python" you should install specific package (IIRC > "python") via: apt install python Now that python2 is gone (the last supported versions were released last year and no new one will be released) it is safe to use python again since it refers to python3. :-) For the moment that is the easiest solution. The more complete solution is the one that Scott mentioned because we already search for python in a more general way, Even python3 is a symlink to some python version. As an example in my computer running Fedora 35 I have: $ ls -l /usr/bin/python lrwxrwxrwx. 1 root root 9 Oct 4 23:36 /usr/bin/python -> ./python3 $ ls -l /usr/bin/python3 lrwxrwxrwx. 1 root root 10 Oct 4 23:10 /usr/bin/python3 -> python3.10 The previous case where python worked relied on python referring to python2. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Update layouts (run layout2layout.py)
On Monday, 25 October 2021 17.14.36 WEST Scott Kostyshak wrote: > Update layouts (run layout2layout.py) > > There is nothing in the diff besides the format number changing from > 93 to 95. From what I understand, this is as expected since 93 -> 94 > and 94 -> 95 just add new layout tags. > > Updating the layouts makes it easier to test master. Otherwise, in > some use cases layout2layout can be run hundreds of times which can > make some things slow (e.g., opening documents or even opening the > advanced find pane). FWIW maybe it could help if this was part of the standard process of layout format updates. If problems occur that is the reason why we have git for. :-) Not only that but the person that commits the change is the one that has the best idea of how the update is supposed to go on. What do you think? -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Update layouts (run layout2layout.py)
On Monday, 25 October 2021 18.48.18 WEST José Abílio Matos wrote: > FWIW maybe it could help if this was part of the standard process of layout > format updates. > > If problems occur that is the reason why we have git for. > > Not only that but the person that commits the change is the one that has the > best idea of how the update is supposed to go on. > > What do you think? When I wrote this message I was quite busy and yet I wanted to give a feedback based on your idea. This reminds me of: http://phdcomics.com/comics/archive.php?comicid=2049 that was out yesterday. :-D Right now, just like Jürgen I am using a lot LyX and not working on it. :-) Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0
On Sunday, 5 December 2021 17.43.30 WET Richard Kimberly Heck wrote: > > 3. LyX's configure should not assume 'python' command exists. > > (https://www.mail-archive.com/search?l=mid=20210215004347.vha7nygqpd6g5h > > 5q%40tallinn) > I've asked Pavel to create a wiki to-do list. Or you can do it. All > such things can be added. > > This last one seems very important, actually. I already had this problem more than 3 years ago but it was masked because at that time /usr/bin/python was pointing to python2. And then /usr/bin/python was removed from Fedora. Now it has returned as an optional package that points to the latest 3.x version (with x==10 in Fedora 35). python-unversioned-command In any case the proposed solutions should be implemented. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Make "wrap" the default in find for 2.4.0?
On Thursday, 15 July 2021 16.37.19 WEST Scott Kostyshak wrote: > Bump. I know most people are lacking time, and I also have not been giving > feedback on others' patches (sorry, racoon!). But I prefer not to push this > change without at least a few more opinions. That said, I'm happy to wait > until more people are around. > > Thanks, > Scott I am used to emacs that also wraps by default. I have just tested other editors that have open at the moment like the octave editor, spyder or R Studio and all of them wrap. I can see why you do not want to wrap but I think that it should be on by default. Regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix bug #12466
On Sunday, 13 February 2022 03.30.57 WET Enrico Forestieri wrote: > commit 777ccce5617aea9b15f27902b9133146eff4e87b > Author: Enrico Forestieri > Date: Sun Feb 13 04:57:27 2022 +0100 > > Fix bug #12466 > > Amend 109ea2be by reintroducing the command prefix that was > inadvertently removed. The prefix sets the proper environment > for latex. Apologies if this was my doing. Not only it was not my intention as I tried to avoid all the changes that could had side effects like this. :-( -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [patch] [RFC] \DocumentMetadata
On Friday, 11 February 2022 13.04.06 WET Jean-Marc Lasgouttes wrote: > Dear Jürgen, > > I had a quick look and it looks good. Of course, only time will tell of > the approach was good enough > > JMarc Just like Jean-Marc I agree that this seems to fit the declared purpose. In particular it takes into account the release schedule of both LyX and LaTeX. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beamer example file: use relative offsets?
On Monday, 7 March 2022 12.57.59 WET Scott Kostyshak wrote: > Let's just leave things as is for now. Perhaps it would make sense for > me to eventually start a separate Beamer example file so that we can > keep the introduction simple. > > Scott That "smells" (I am thinking about cinnamon, do not ask :-D ) as the right solution. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX Bug Tracker Password Reset Behavior
On Tuesday, 8 March 2022 01.53.10 WET Scott Kostyshak wrote: > Thanks, Joel! I've been complaining several years that we should switch, > but I don't do anything about it :). And I still have no plans to > volunteer. > > Scott There are several examples of transitions like that: https://lwn.net/Articles/885854/ In that article from LWN there are references to other moves like llvm. So it not so much is the move is worth, certainly it is in the sense that the administration of a infrastructure takes lots of time. The next issue is when should it be done, before a release, 6 months after a major release, etc... -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Has anyone tried the Mold linker?
On Tuesday, 8 March 2022 18.21.25 WET Scott Kostyshak wrote: > Has anyone tried Mold when linking LyX? I've been curious about it for a > while. I just checked Ubuntu 22.04 daily and it has it packaged, which > makes it more interesting to try when I find the time. > > Some references if curious: > > https://github.com/rui314/mold/releases/tag/v1.1.1 > https://www.phoronix.com/scan.php?page=news_item=Mold-1.1.1-Released > > Scott A thread from last week in Fedora: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/ thread/MCQ7LEB7JPE5VAQ7FD5CUTXDQKPWADW2/#MCQ7LEB7JPE5VAQ7FD5CUTXDQKPWADW2 Since this has only 6 messages it is a light read. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyXHTML doc doesn't pass validation
On Wednesday, 23 March 2022 20.12.23 WET Thibaut Cuvelier wrote: > XHTML 1 dates back from 2001... LyX generates XHTML 5, but the doctype is kept > from XHTML 1 for compatibility issues (some browsers completely change their > behaviour based on the doctype). The issue has been discussed on the mailing > list a while ago. At some point this decision can be revisited. It is question of deciding what are the browsers that we are interested to support. Because of the security associated issues the browsers are kept more up to date now than before so probably at some point this becomes a non issue. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.04.12 WET José Abílio Matos wrote: > Hi, > > we are at the time of year again. :-) > > > The gcc project will release version 12 and in Fedora we are rebuilding all > packages with it. The changes were minimal and already referred here. It was enough to patch two files. The equivalent patch is already applied to the devel branch. -- José Abíliodiff -ur lyx-2.3.6.1.orig/src/insets/InsetListings.cpp lyx-2.3.6.1/src/insets/InsetListings.cpp --- lyx-2.3.6.1.orig/src/insets/InsetListings.cpp 2020-12-29 16:50:45.0 + +++ lyx-2.3.6.1/src/insets/InsetListings.cpp 2022-02-03 16:22:37.983196716 + @@ -44,6 +44,7 @@ #include "support/regex.h" +#include #include using namespace std; Only in lyx-2.3.6.1/src/insets: InsetListings.cpp~ diff -ur lyx-2.3.6.1.orig/src/lyxfind.cpp lyx-2.3.6.1/src/lyxfind.cpp --- lyx-2.3.6.1.orig/src/lyxfind.cpp 2020-12-29 16:50:45.0 + +++ lyx-2.3.6.1/src/lyxfind.cpp 2022-02-03 16:01:54.997152176 + @@ -52,6 +52,7 @@ #include "support/lstrings.h" #include "support/regex.h" +#include using namespace std; using namespace lyx::support; Only in lyx-2.3.6.1/src: lyxfind.cpp~ -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Make layout2layout compatible with Python 2 and 3
On Monday, 3 January 2022 19.30.58 WET José Matos wrote:
> commit 940d3ceeb9e6d8ce216afedf18c898ec075cc27d
> Author: José Matos
> Date: Mon Jan 3 19:59:42 2022 +
>
> Make layout2layout compatible with Python 2 and 3
> ---
> lib/scripts/layout2layout.py | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/lib/scripts/layout2layout.py b/lib/scripts/layout2layout.py
> index 7e40bfb..88ada12 100644
> --- a/lib/scripts/layout2layout.py
> +++ b/lib/scripts/layout2layout.py
> @@ -256,7 +256,7 @@ currentFormat = 95
> # New textclass tag BibInToc
>
> # Incremented to format 77, 6 August 2019 by spitz
> -# New textclass tag PageSize (= default page size)
> +# New textclass tag PageSize (= default page size)
> # and textclass option PageSize (= list of available page sizes)
>
> # Incremented to format 78, 6 August 2019 by spitz
> @@ -354,7 +354,7 @@ def error(message):
>
> def trim_bom(line):
> " Remove byte order mark."
> -if line[0:3] == "\357\273\277":
> +if line[0:3] == b"\357\273\277":
> return line[3:]
> else:
> return line
> @@ -444,8 +444,8 @@ def convert(lines, end_format):
> # for categories
> re_Declaration = re.compile(b'^#\\s*\\Declare\\w+Class.*$')
> re_ExtractCategory =
> re.compile(b'^(#\\s*\\Declare\\w+Class(?:\\[[^]]*?\\])?){([^(]+?)\\s+\\
(([^)]
> +?)\\)\\s*}\\s*$') -ConvDict = {"article": "Articles", "book" : "Books",
> "letter" : "Letters", "report": "Reports", -"presentation" :
> "Presentations", "curriculum vitae" : "Curricula Vitae", "handout" :
> "Handouts"} +ConvDict = {b"article": b"Articles", b"book": b"Books",
> b"letter": b"Letters", b"report": b"Reports", +
> b"presentation": b"Presentations", b"curriculum vitae": b"Curricula Vitae",
> b"handout": b"Handouts"} # Arguments
> re_OptArgs = re.compile(b'^(\\s*)OptionalArgs(\\s+)(\\d+)\\D*$',
> re.IGNORECASE) re_ReqArgs =
> re.compile(b'^(\\s*)RequiredArgs(\\s+)(\\d+)\\D*$', re.IGNORECASE) @@ -615,7
> +615,7 @@ def convert(lines, end_format):
> continue
> col = match.group(2)
> if col == "collapsable":
> -lines[i] = match.group(1) + "collapsible"
> +lines[i] = match.group(1) + b"collapsible"
> i += 1
> continue
>
> @@ -833,7 +833,7 @@ def convert(lines, end_format):
> # Insert the required number of arguments at the end of the
style
> definition match = re_End.match(lines[i])
> if match:
> -newarg = ['']
> +newarg = [b'']
> # First the optionals (this is the required order pre 2.1)
> if opts > 0:
> if opts == 1:
> @@ -1283,7 +1283,7 @@ def convert(lines, end_format):
> if latextype == b"item_environment" and label.lower() ==
> b"counter_enumi": lines[labeltype_line] =
> re_LabelType.sub(b'\\1\\2\\3Enumerate', lines[labeltype_line]) # Don't add
> the LabelCounter line later
> -counter = ""
> +counter = b""
>
> # Replace
> #
This is a candidate to 2.3.x.
FWIW I have backported it in order to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1965118
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.09.09 WET Scott Kostyshak wrote: > Except for that issue does it build with -Werror ? > > Scott For completeness sake, since this was answered before, it follows here an example of the output that you can expect when building lyx with gcc-12. In this case I am still building the stable branch (2.3.x): https://kojipkgs.fedoraproject.org//work/tasks/2847/82342847/build.log Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions)
On Wednesday, 2 February 2022 21.45.40 WET Pavel Sanda wrote: > Jose, could I ask for pythonic help? > We would need a routine in configure.py which check whether to remove eps->png > conversion in case IM bans those conversions. That could be done this way by > checking return status of the conversion. In bash that would be something > like this: > > echo '%!PS' > /tmp/.lyx_configure_test.eps > convert /tmp/.lyx_configure_test.eps /tmp/.lyx_configure_test.png > if ! [ $? == 0 ] ; then > # remove eps->png conversion from configure settings, i.e. set \converter > "eps" "png" "" "" fi > > > Completely different way would be mimicking what IM internally does with GS > when converting eps->png. I already checked little bit and unfortunately it > won't be oneliner if we want to get resolution right. But probably doable > with additional script of our own. Pavel I will look into this in the weekend. At some point I will want to overhaul the configure.py script. The purpose is, among others, to simplify the code required to do this kind of tests. The test above is relatively easy to do. Something that I should, probably, take into account is the order of the tests. In the sense that if we different \convert lines we probably retain the last... -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix compilation with gcc-12
On Thursday, 27 January 2022 15.44.56 WET José Abílio Matos wrote: > The previous patch was all that it was required to compile lyx-2.4 with > gcc-12. :-) But then it does not run: $ src/lyx src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by src/lyx) it is not using the new library. Is there any flag that can be passed to configure to account for this? I can always run it as: $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx and it works... -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 15.48.33 WET Kornel Benko wrote: > This one may be needed for 2.4.0 version of lyxfind.cpp too. You are right but for some reason I got away without this fix, only the cstring of the other thread. (BTW I am puzzled) The reason could be some change in the code between 2.3 and 2.4 but for the moment I am leaving this out. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Failure to compile with gcc-12 (2.3.x)
Hi,
we are at the time of year again. :-)
The gcc project will release version 12 and in Fedora we are rebuilding all
packages with it.
There is a failure to build 2.3.x (e.g. on x86-54):
https://kojipkgs.fedoraproject.org//work/tasks/4412/81984412/build.log
73 | class MatchString : public binary_function
|^~~
In file included from /usr/include/c++/12/string:48,
from support/strfwd.h:42,
from lyxfind.h:19,
from lyxfind.cpp:17:
/usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
131 | struct binary_function
|^~~
lyxfind.cpp: In function 'bool lyx::{anonymous}::regex_replace(const
std::string&, std::string&, const std::string&, const std::string&)':
lyxfind.cpp:677:9: error: 'ostream_iterator' was not declared in this scope
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header
''; did you forget to '#include '?
54 | #include "support/regex.h"
+++ |+#include
55 |
lyxfind.cpp:677:26: error: expected primary-expression before 'char'
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:678:28: error: 'it' was not declared in this scope; did you mean
't'?
678 | lyx::regex_replace(it, s.begin(), s.end(), e, replacestr);
|^~
|t
This seems an example of a missing include, and g++ even suggests to add:
#include
Is there are better fix or is this OK?
I will start to build 2.4 with g++-12 as well FWIW.
Best regards,
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Why do we add converters in frontends GuiPrefs.cpp?
On Sunday, 2 January 2022 21.19.14 WET Pavel Sanda wrote: > Most likely my doing. > These are just suggestions in drop-down menu you can use or edit in > your settings. I do not see much merit in moving it to configure > (they are not automagically used). > > Pavel That makes sense. Thank you. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Depth in/decrease used as equivalent to outline in/out
On Tuesday, 1 February 2022 14.33.49 WET Jean-Marc Lasgouttes wrote: > Note that shift-tab for depth does not always have a local scope either, > since it may change the depth of nested sub elements. Yes, I know and it was a sloppy language. :-) A better expression would be a waterfall model and so it would be waterfall scope. :-) In the worst case it can topple until the end but it behaves differently from what it does now. 1. A 1.1 B 1.1.1 C 1.1.1.1 D It goes to 1. A 2. B 2.1 C 2.1.1 D -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Depth in/decrease used as equivalent to outline in/out
On Tuesday, 1 February 2022 10.23.41 WET Jean-Marc Lasgouttes wrote: > Hello, > > I am looking for feedback about > https://www.lyx.org/trac/ticket/12417 > > Basically, now Tab and the depth icons invoke outline in/out when on a > sectioning layout. > > Do you find that this is confusing? The fact is that these two bindings > have different behavior on layouts that follow the current one. Outline > stuff is more global (and somewhat broken, see #9375). > > The ticket asks to revert b08791f7 (icons) and 31398779/9ab9f2b1 (Tab > key). What are your thought about this functionality? > > JMarc I was surprised by it. I was expecting for Tab to have a local scope. It was surprising to me that it affected all the sections at the same level below that paragraph. I was expecting a behavior similar to what it happens for lists and enumerations. The current behavior is also surprising in the sense that, at least in the examples I tested, Shift-Tab works by promoting a (sub*)section but Tab does not demotes it (at least here it is consistent with listing and enumerations). Also as it is if we have: 1. A 2. B 2.1 C 2.2 D And press Shift-Tab in 2. we get: 1. A 2. B 3. C 4. D My expectation was for this to become a no-op since it is not possible to promote 2. B anymore. Is this the feedback you are expecting? Best regards, -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3 and 2.4 have troubles displaying EPS images
On Wednesday, 9 February 2022 01.06.17 WET Thibaut Cuvelier wrote: > Dear list, > > A friend of mine noticed that LyX 2.3 has problems displaying the attached > EPS file. All other EPS images can be previewed within LyX without any > problem. > All EPS files are displayed correctly in the PDF (produced by pdflatex). I > can reproduce this issue with LyX 2.3.6.1. Both of us are using Windows x64 > (Windows 8 for her, Windows 10 for me). LyX shows the following error > message (within the preview box): > > Error converting to loadable format > > This EPS is quite large (almost 40 MB). All the other EPS files for the LyX > documents are at most 2 MB (and they all display correctly). It was > generated with Photoshop (which certainly explains the size). Using linux I get a parser error for most modern tools. Actually I had to use ghostview to show it (the memories). :-) So I suspect that this is related with the structure of the file. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.3 and 2.4 have troubles displaying EPS images
On Wednesday, 9 February 2022 13.17.29 WET Daniel wrote: > eps is a vector image, png is a bitmap. so, this might not be a > desirable solution depending on what is to be achieved. A small nitpick, eps allows vector images but it does not require it. It is perfectly possible to have an eps that holds a raster representation and looking only to the size of the file that is possibility to consider. > Also, the LaTeX output shows the eps just fine. So why doesn't LyX? It should but the handling of eps is not a simple mater. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.52.56 WET Jean-Marc Lasgouttes wrote: > José, what can you tell me about these messages? > annobin: Timeout.cpp: Warning: -D_GLIBCXX_ASSERTIONS not defined > > We use _GLIBCXX_DEBUG currently. Should we switch to > _GLIBCXX_ASSERTIONS? I have not found the gcc docs very useful in this > respect. > > JMarc I think that this is bug in annobin that was fixed meanwhile. So this can be ignored since it is not our fault. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.52.56 WET Jean-Marc Lasgouttes wrote:
> This one is a warning, but you cut part of it out.
For complete sake the complete diagnose (warnings and errors) is here:
make[4]: Entering directory '/builddir/build/BUILD/lyx-2.3.6.1/src'
g++ -DHAVE_CONFIG_H -I. -I.. -I../src-I/usr/include/enchant
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4
-pthread -I/usr/include/hunspell -DQT_NO_STL -DQT_NO_KEYWORDS -DQT_CORE_LIB
-I/usr/include/qt5/QtCore -I/usr/include/qt5 -fPIC -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-std=c++14 -std=c++14 -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c -o
lyxfind.o lyxfind.cpp
lyxfind.cpp: warning: -D_FORTIFY_SOURCE not defined
annobin: lyxfind.cpp: Warning: -D_GLIBCXX_ASSERTIONS not defined
lyxfind.cpp:73:28: warning: 'template
struct std::binary_function' is deprecated [-Wdeprecated-declarations]
73 | class MatchString : public binary_function
|^~~
In file included from /usr/include/c++/12/string:48,
from support/strfwd.h:42,
from lyxfind.h:19,
from lyxfind.cpp:17:
/usr/include/c++/12/bits/stl_function.h:131:12: note: declared here
131 | struct binary_function
|^~~
lyxfind.cpp: In function 'bool lyx::{anonymous}::regex_replace(const
std::string&, std::string&, const std::string&, const std::string&)':
lyxfind.cpp:677:9: error: 'ostream_iterator' was not declared in this scope
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:55:1: note: 'std::ostream_iterator' is defined in header
''; did you forget to '#include '?
54 | #include "support/regex.h"
+++ |+#include
55 |
lyxfind.cpp:677:26: error: expected primary-expression before 'char'
677 | ostream_iterator it(oss);
| ^~~~
lyxfind.cpp:678:28: error: 'it' was not declared in this scope; did you mean
't'?
678 | lyx::regex_replace(it, s.begin(), s.end(), e, replacestr);
|^~
|t
--
José Abílio--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Failure to compile with gcc-12 (2.3.x)
On Thursday, 27 January 2022 13.09.09 WET Scott Kostyshak wrote: > Except for that issue does it build with -Werror ? > > Scott As Jean-Marc said the compilation has lots of warnings. Some of them are not our fault, so I am not sure if it is possible to filter system warnings from - Werror. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Fix compilation with gcc-12
On Thursday, 27 January 2022 15.06.43 WET José Matos wrote: > commit b73ab0256d113571174fed4b2a3405fe8c44d297 > Author: José Matos > Date: Thu Jan 27 15:37:45 2022 + > > Fix compilation with gcc-12 > --- > src/insets/InsetListings.cpp |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/src/insets/InsetListings.cpp b/src/insets/InsetListings.cpp > index 57df06e..67a0462 100644 > --- a/src/insets/InsetListings.cpp > +++ b/src/insets/InsetListings.cpp > @@ -41,6 +41,7 @@ > #include "frontends/alert.h" > #include "frontends/Application.h" > > +#include > #include > #include @Riki (or any other Fedora user), in case you are interested, this is my work flow: Install gcc-latest from copr: https://copr.fedorainfracloud.org/coprs/jwakely/gcc-latest/ Configure lyx to use it: $ configure --with-version-suffix=-devel CC=/opt/gcc-latest/bin/gcc CXX=/opt/gcc-latest/bin/g++ And that is it. :-) The previous patch was all that it was required to compile lyx-2.4 with gcc-12. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add new placeholder $${python} to configure
On Saturday, 22 January 2022 19.49.26 WET Pavel Sanda wrote:
> Hi Jose,
>
> this what I see in curent master:
> 1. start lyx
> 2. load file
> 3. this is what I see in terminal window:
> env: '$${python}': No such file or directory
>
> Most likely related to image preview conversions, this what I see with debug
> messages on graphics:
> graphics/PreviewLoader.cpp (757): PreviewLoader::finishedInProgress(127):
> processing failed for $${python} $$s/scripts/lyxpreview2bitmap.py --png
> "/tmp/lyx_tmpdir.LiGxsfYQmUxW/lyx_tmpbuf6/lyxpreviewGdodeo.tex" --dpi 115
> --fg ff9822 --bg 00 --bibtex="bibtex"
>
>
> These binaries available on my system:
> python python2python2.7 python3python3.9
> python defaults to python2.7
>
> Pavel
The problem here is that the placeholder is not replaced before being used.
In order to see what python is being used you can see:
Help->About LyX
In a hunch does the attached patch fixes the issue?
The idea is to replace the placeholder when the converter is added/imported.
--
José Abíliodiff --git a/src/Converter.cpp b/src/Converter.cpp
index c00941d21f..7bb998d5a9 100644
--- a/src/Converter.cpp
+++ b/src/Converter.cpp
@@ -148,6 +148,12 @@ void Converter::readFlags()
}
+void Converter::setCommand(std::string const & command)
+{
+ command_ = subst(command, token_python, os::python());
+}
+
+
Converter const * Converters::getConverter(string const & from,
string const & to) const
{
diff --git a/src/Converter.h b/src/Converter.h
index 5197e3447a..091dbcd394 100644
--- a/src/Converter.h
+++ b/src/Converter.h
@@ -58,7 +58,7 @@ public:
///
std::string const command() const { return command_; }
///
- void setCommand(std::string const & command) { command_ = command; }
+ void setCommand(std::string const & command);
///
std::string const flags() const { return flags_; }
///
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add new placeholder $${python} to configure
On Sunday, 23 January 2022 15.01.33 WET Pavel Sanda wrote: > On Sat, Jan 22, 2022 at 09:54:39PM +0000, José Abílio Matos wrote: > > The problem here is that the placeholder is not replaced before being used. > > In order to see what python is being used you can see: > > > > Help->About LyX > > python3 -tt The detection is right. :-) > > In a hunch does the attached patch fixes the issue? > > The idea is to replace the placeholder when the converter is added/ imported. > > Strangely, I can't reproduce the problem anymore. I'll wait if I can catch > it again. Pavel Could it be a cache interfering? Are the previewed files cached? Thank you, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Missing header using gcc-13
Hi, just for fun, I have been compiling lyx with gcc-latest (gcc 13 in development). This is the error I get: /home/jamatos/lyx/lyx.anon/src/tex2lyx/Parser.cpp: In member function ‘void lyx::Parser::tokenize_one()’: /home/jamatos/lyx/lyx.anon/src/tex2lyx/Parser.cpp:857:60: error: ‘uint32_t’ does not name a type 857 | cerr << "ignoring a char: " << static_cast(c) << "\n"; |^~~~ /home/jamatos/lyx/lyx.anon/src/tex2lyx/Parser.cpp:20:1: note: ‘uint32_t’ is defined in header ‘’; did you forget to ‘#include ’? 19 | #include +++ |+#include 20 | This is the only problem found, other than that everything works as expected. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Output word wrapping
On Wednesday, 8 June 2022 22.47.16 WEST Jean-Marc Lasgouttes wrote: > Note that, contrary to .tex, the .lyx file format does not consider a > line break as a space. This is probably a mistake, but it should be > taken into account. > > JMarc That is certainly a mistake, that Joel pointed last year. :-) One issue is that in a counterintuitive way we need to leave empty spaces at the end of lines when we change to a new line to avoid the lyx files to have very long lines... In most formats trimming empty spaces at the end of lines does not, in general, changes the final format while it does it in LyX. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Back
On Wednesday, 4 May 2022 16.52.32 WEST Richard Kimberly Heck wrote: > FWIW, I've been using the master branch for daily work for some time and have > not run into any new major issues. A few small things with line breaking, but > they're hard to reproduce. I think one invovled a quotation mark that stayed > at the end of the previous line, similar to another bug I reported. FWIW I have also been using the development branch on a daily basis and without issues. Even to prepare, in some cases, classes for the next day (or the same day, sometimes). :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 (IM policy.xml ban on eps/pdf conversions)
On Wednesday, 4 May 2022 12.48.10 WEST Pavel Sanda wrote: > > > > ping :) > > ping :) > > > p Riki is not the only person busy. :-D After the next week things will calm down a bit and I will look into that. -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
