Re: [LyX/master] ctests: invert a failing xhtml test
On Mon, Jul 15, 2024 at 11:41:02AM GMT, Kornel Benko wrote: > Am Sun, 14 Jul 2024 11:36:26 -0400 > schrieb Scott Kostyshak : > > > On Sun, Jul 14, 2024 at 09:25:03AM GMT, Kornel Benko wrote: > > > Am Sun, 14 Jul 2024 04:27:30 + > > > schrieb Scott Kostyshak : > > > > > > > commit 4d15427935b7c965af0aff748ffa2549856c232c > > > > Author: Scott Kostyshak > > > > Date: Sun Jul 14 00:16:19 2024 -0400 > > > > > > > > ctests: invert a failing xhtml test > > > > > > > > Explanation from Jürgen: > > > > > > > > the author-specific keys now can have a trailing & > > > > (after the key as in "abbrvciteauthor&" or at the start of the type > > > > subtag, as in "abbrvnames:&author" (see 5c2652fa12b). This indicates > > > > that we want "&" rather than "and" (in APA context). > > > > > > > > See: > > > > https://www.mail-archive.com/search?l=mid&q=ildx4xd4o7ybeqroh3blxgnxqnsqnte256utip2fbmcwi4zolz%40wsh7ez36kkhl > > > > > > > > > > Since we can expect a fix in a not too distant future, > > > > I'm not sure. No one has volunteered to work on the support. > > > > > I think it deserves also an entry > > > in suspendedTests. > > > > The first couple of lines of suspendedTests says the following: > > > > # Regular expressions for tests that are most likely "wontfix" > > # or "sep" (someone else's problem) > > > > That said, I'd be happy to add an entry if you think it's best. > > > > Scott > > I have to reconsider. Always thought it be another way. > Having a test be 'inverted' only feels easily forgotten. > Maybe some new tag like 'needsfix' or 'needsattention' additionally to > 'inverted' may be > good. I put it under the sublabel "lyxbugs". We'll see if someone has time to work on it, but otherwise I'm not sure it's that serious of a bug. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] ctests: invert a failing xhtml test
Am Sun, 14 Jul 2024 11:36:26 -0400 schrieb Scott Kostyshak : > On Sun, Jul 14, 2024 at 09:25:03AM GMT, Kornel Benko wrote: > > Am Sun, 14 Jul 2024 04:27:30 + > > schrieb Scott Kostyshak : > > > > > commit 4d15427935b7c965af0aff748ffa2549856c232c > > > Author: Scott Kostyshak > > > Date: Sun Jul 14 00:16:19 2024 -0400 > > > > > > ctests: invert a failing xhtml test > > > > > > Explanation from Jürgen: > > > > > > the author-specific keys now can have a trailing & > > > (after the key as in "abbrvciteauthor&" or at the start of the type > > > subtag, as in "abbrvnames:&author" (see 5c2652fa12b). This indicates > > > that we want "&" rather than "and" (in APA context). > > > > > > See: > > > https://www.mail-archive.com/search?l=mid&q=ildx4xd4o7ybeqroh3blxgnxqnsqnte256utip2fbmcwi4zolz%40wsh7ez36kkhl > > > > > > > Since we can expect a fix in a not too distant future, > > I'm not sure. No one has volunteered to work on the support. > > > I think it deserves also an entry > > in suspendedTests. > > The first couple of lines of suspendedTests says the following: > > # Regular expressions for tests that are most likely "wontfix" > # or "sep" (someone else's problem) > > That said, I'd be happy to add an entry if you think it's best. > > Scott I have to reconsider. Always thought it be another way. Having a test be 'inverted' only feels easily forgotten. Maybe some new tag like 'needsfix' or 'needsattention' additionally to 'inverted' may be good. Kornel pgpJqWeqLE66Z.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] ctests: invert a failing xhtml test
On Sun, Jul 14, 2024 at 09:25:03AM GMT, Kornel Benko wrote: > Am Sun, 14 Jul 2024 04:27:30 + > schrieb Scott Kostyshak : > > > commit 4d15427935b7c965af0aff748ffa2549856c232c > > Author: Scott Kostyshak > > Date: Sun Jul 14 00:16:19 2024 -0400 > > > > ctests: invert a failing xhtml test > > > > Explanation from Jürgen: > > > > the author-specific keys now can have a trailing & > > (after the key as in "abbrvciteauthor&" or at the start of the type > > subtag, as in "abbrvnames:&author" (see 5c2652fa12b). This indicates > > that we want "&" rather than "and" (in APA context). > > > > See: > > https://www.mail-archive.com/search?l=mid&q=ildx4xd4o7ybeqroh3blxgnxqnsqnte256utip2fbmcwi4zolz%40wsh7ez36kkhl > > Since we can expect a fix in a not too distant future, I'm not sure. No one has volunteered to work on the support. > I think it deserves also an entry > in suspendedTests. The first couple of lines of suspendedTests says the following: # Regular expressions for tests that are most likely "wontfix" # or "sep" (someone else's problem) That said, I'd be happy to add an entry if you think it's best. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] ctests: invert a failing xhtml test
Am Sun, 14 Jul 2024 04:27:30 + schrieb Scott Kostyshak : > commit 4d15427935b7c965af0aff748ffa2549856c232c > Author: Scott Kostyshak > Date: Sun Jul 14 00:16:19 2024 -0400 > > ctests: invert a failing xhtml test > > Explanation from Jürgen: > > the author-specific keys now can have a trailing & > (after the key as in "abbrvciteauthor&" or at the start of the type > subtag, as in "abbrvnames:&author" (see 5c2652fa12b). This indicates > that we want "&" rather than "and" (in APA context). > > See: > https://www.mail-archive.com/search?l=mid&q=ildx4xd4o7ybeqroh3blxgnxqnsqnte256utip2fbmcwi4zolz%40wsh7ez36kkhl Since we can expect a fix in a not too distant future, I think it deserves also an entry in suspendedTests. Kornel pgpHUaExZ1w9O.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test failure after tlmgr update (not a LyX issue)
On Mon, May 06, 2024 at 01:59:50PM GMT, Kornel Benko wrote: > Am Sun, 5 May 2024 13:12:48 +0200 > schrieb Kornel Benko : > > > > > > > > > See: https://tug.org/pipermail/tex-live/2024-May/050511.html > > > > > > > > Udi > > > > > > Thanks, Kornel and Udi. Indeed, after a new tlmgr update these tests > > > pass. Now the following tests fail for me: > > > > > > export/examples/ja/Modules/Braille_pdf5_systemF > > > export/examples/ja/Welcome_pdf5_systemF > > > export/doc/ja/Shortcuts_pdf5_systemF > > > export/doc/ja/Formula-numbering_pdf5_systemF > > > export/examples/ja/Modules/Multilingual_Captions_pdf5_systemF > > > export/doc/ja/Tutorial_pdf5_systemF > > > > Same here. > > > > > Perhaps my plan should be to wait a couple of weeks and see if the > > > failure persists before spending time checking them out. > > > > +1 > > > > > Scott > > > > Kornel > > Today's tl update: The reported tests succeeded now. Thanks! Now all tests are back to normal. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test failure after tlmgr update (not a LyX issue)
Am Sun, 5 May 2024 13:12:48 +0200 schrieb Kornel Benko : > > > > > > See: https://tug.org/pipermail/tex-live/2024-May/050511.html > > > > > > Udi > > > > Thanks, Kornel and Udi. Indeed, after a new tlmgr update these tests > > pass. Now the following tests fail for me: > > > > export/examples/ja/Modules/Braille_pdf5_systemF > > export/examples/ja/Welcome_pdf5_systemF > > export/doc/ja/Shortcuts_pdf5_systemF > > export/doc/ja/Formula-numbering_pdf5_systemF > > export/examples/ja/Modules/Multilingual_Captions_pdf5_systemF > > export/doc/ja/Tutorial_pdf5_systemF > > Same here. > > > Perhaps my plan should be to wait a couple of weeks and see if the > > failure persists before spending time checking them out. > > +1 > > > Scott > > Kornel Today's tl update: The reported tests succeeded now. Kornel pgpuRI6GieJ1Y.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test failure after tlmgr update (not a LyX issue)
Am Sat, 4 May 2024 23:18:51 -0400 schrieb Scott Kostyshak : > On Sat, May 04, 2024 at 09:57:22PM GMT, Udicoudco wrote: > > On Sat, May 4, 2024, 9:46 PM Kornel Benko wrote: > > > > > Am Fri, 3 May 2024 10:31:42 -0400 > > > schrieb Scott Kostyshak : > > > > > > > This is likely not a LyX issue so feel free to ignore. > > > > > > > > After a tlmgr update, the following tests now fail: > > > > > > > > export/export/latex/languages/en-ja_platex_dvi3_systemF (Failed) > > > > export/export/latex/languages/en-ja_platex_pdf4_systemF (Failed) > > > > export/export/latex/languages/en-ja_platex_pdf5_systemF (Failed) > > > > > > > > I attach the file that corresponds to the pdf4_systemF test for > > > > convenience. > > > > > > > > The LaTeX error I now get is the following: > > > > > > > > ! Illegal parameter number in definition of \l__exp_internal_tl. > > > > > > > > I'm going to ask a question on tex.se to figure out where to report this > > > > potential regression, but first I wanted to check in here and see if > > > > anyone else can reproduce this error after a tlmgr update or if it might > > > > be something local to my system (I have a few hacks in there). > > > > > > > > Scott > > > > > > I don't have these errors. (TL24 updated today) > > > # ctest -R en-ja_platex_ > > > ... > > > 100% tests passed, 0 tests failed out of 7 > > > > > > Kornel > > > -- > > > > > > See: https://tug.org/pipermail/tex-live/2024-May/050511.html > > > > Udi > > Thanks, Kornel and Udi. Indeed, after a new tlmgr update these tests > pass. Now the following tests fail for me: > > export/examples/ja/Modules/Braille_pdf5_systemF > export/examples/ja/Welcome_pdf5_systemF > export/doc/ja/Shortcuts_pdf5_systemF > export/doc/ja/Formula-numbering_pdf5_systemF > export/examples/ja/Modules/Multilingual_Captions_pdf5_systemF > export/doc/ja/Tutorial_pdf5_systemF Same here. > Perhaps my plan should be to wait a couple of weeks and see if the > failure persists before spending time checking them out. +1 > Scott Kornel pgpAICvvwd_HP.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test failure after tlmgr update (not a LyX issue)
On Sat, May 04, 2024 at 09:57:22PM GMT, Udicoudco wrote: > On Sat, May 4, 2024, 9:46 PM Kornel Benko wrote: > > > Am Fri, 3 May 2024 10:31:42 -0400 > > schrieb Scott Kostyshak : > > > > > This is likely not a LyX issue so feel free to ignore. > > > > > > After a tlmgr update, the following tests now fail: > > > > > > export/export/latex/languages/en-ja_platex_dvi3_systemF (Failed) > > > export/export/latex/languages/en-ja_platex_pdf4_systemF (Failed) > > > export/export/latex/languages/en-ja_platex_pdf5_systemF (Failed) > > > > > > I attach the file that corresponds to the pdf4_systemF test for > > > convenience. > > > > > > The LaTeX error I now get is the following: > > > > > > ! Illegal parameter number in definition of \l__exp_internal_tl. > > > > > > I'm going to ask a question on tex.se to figure out where to report this > > > potential regression, but first I wanted to check in here and see if > > > anyone else can reproduce this error after a tlmgr update or if it might > > > be something local to my system (I have a few hacks in there). > > > > > > Scott > > > > I don't have these errors. (TL24 updated today) > > # ctest -R en-ja_platex_ > > ... > > 100% tests passed, 0 tests failed out of 7 > > > > Kornel > > -- > > > See: https://tug.org/pipermail/tex-live/2024-May/050511.html > > Udi Thanks, Kornel and Udi. Indeed, after a new tlmgr update these tests pass. Now the following tests fail for me: export/examples/ja/Modules/Braille_pdf5_systemF export/examples/ja/Welcome_pdf5_systemF export/doc/ja/Shortcuts_pdf5_systemF export/doc/ja/Formula-numbering_pdf5_systemF export/examples/ja/Modules/Multilingual_Captions_pdf5_systemF export/doc/ja/Tutorial_pdf5_systemF Perhaps my plan should be to wait a couple of weeks and see if the failure persists before spending time checking them out. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test failure after tlmgr update (not a LyX issue)
On Sat, May 4, 2024, 9:46 PM Kornel Benko wrote: > Am Fri, 3 May 2024 10:31:42 -0400 > schrieb Scott Kostyshak : > > > This is likely not a LyX issue so feel free to ignore. > > > > After a tlmgr update, the following tests now fail: > > > > export/export/latex/languages/en-ja_platex_dvi3_systemF (Failed) > > export/export/latex/languages/en-ja_platex_pdf4_systemF (Failed) > > export/export/latex/languages/en-ja_platex_pdf5_systemF (Failed) > > > > I attach the file that corresponds to the pdf4_systemF test for > > convenience. > > > > The LaTeX error I now get is the following: > > > > ! Illegal parameter number in definition of \l__exp_internal_tl. > > > > I'm going to ask a question on tex.se to figure out where to report this > > potential regression, but first I wanted to check in here and see if > > anyone else can reproduce this error after a tlmgr update or if it might > > be something local to my system (I have a few hacks in there). > > > > Scott > > I don't have these errors. (TL24 updated today) > # ctest -R en-ja_platex_ > ... > 100% tests passed, 0 tests failed out of 7 > > Kornel > -- See: https://tug.org/pipermail/tex-live/2024-May/050511.html Udi > > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test failure after tlmgr update (not a LyX issue)
Am Fri, 3 May 2024 10:31:42 -0400 schrieb Scott Kostyshak : > This is likely not a LyX issue so feel free to ignore. > > After a tlmgr update, the following tests now fail: > > export/export/latex/languages/en-ja_platex_dvi3_systemF (Failed) > export/export/latex/languages/en-ja_platex_pdf4_systemF (Failed) > export/export/latex/languages/en-ja_platex_pdf5_systemF (Failed) > > I attach the file that corresponds to the pdf4_systemF test for > convenience. > > The LaTeX error I now get is the following: > > ! Illegal parameter number in definition of \l__exp_internal_tl. > > I'm going to ask a question on tex.se to figure out where to report this > potential regression, but first I wanted to check in here and see if > anyone else can reproduce this error after a tlmgr update or if it might > be something local to my system (I have a few hacks in there). > > Scott I don't have these errors. (TL24 updated today) # ctest -R en-ja_platex_ ... 100% tests passed, 0 tests failed out of 7 Kornel pgphPZ_OcE7Cm.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Test failure after tlmgr update (not a LyX issue)
This is likely not a LyX issue so feel free to ignore. After a tlmgr update, the following tests now fail: export/export/latex/languages/en-ja_platex_dvi3_systemF (Failed) export/export/latex/languages/en-ja_platex_pdf4_systemF (Failed) export/export/latex/languages/en-ja_platex_pdf5_systemF (Failed) I attach the file that corresponds to the pdf4_systemF test for convenience. The LaTeX error I now get is the following: ! Illegal parameter number in definition of \l__exp_internal_tl. I'm going to ask a question on tex.se to figure out where to report this potential regression, but first I wanted to check in here and see if anyone else can reproduce this error after a tlmgr update or if it might be something local to my system (I have a few hacks in there). Scott en-ja_platex.lyx Description: application/lyx signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Mon, Apr 08, 2024 at 10:14:07AM GMT, José Matos wrote: > On Sun, 2024-04-07 at 23:03 -0400, Scott Kostyshak wrote: > > Thanks, that is a good idea, but I would not want to use that setting > > for most of my documents. I find that doing repeated lyx2lyx does not > > create a smooth workflow. > > > > Scott > > I pushed against the guarantee before. :-) > The rationale was the main priority was to ensure the best upgrade > (forward). > > On the other hand after hundreds of file updates we have now a better > understanding of what it involves and so I think that with some small > effort we can improve, make it for a smoother experience, the round > trip experience. > > BTW, I know that this is orthogonal to your issue. :-) Fair enough! You are more optimistic than I about making roundtrip smooth :) Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Sun, 2024-04-07 at 23:03 -0400, Scott Kostyshak wrote: > Thanks, that is a good idea, but I would not want to use that setting > for most of my documents. I find that doing repeated lyx2lyx does not > create a smooth workflow. > > Scott I pushed against the guarantee before. :-) The rationale was the main priority was to ensure the best upgrade (forward). On the other hand after hundreds of file updates we have now a better understanding of what it involves and so I think that with some small effort we can improve, make it for a smoother experience, the round trip experience. BTW, I know that this is orthogonal to your issue. :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Sun, Apr 07, 2024 at 03:13:44PM GMT, Richard Kimberly Heck wrote: > On 4/7/24 12:46, José Matos wrote: > > On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote: > > > Fair enough. That was what I was afraid of (and expected). > > > > > > Scott > > A possible mid-term solution, to your use case, is to set the output > > format of the latest stable version. > > > > This would mean that any document is always imported to the latest > > development release and when saved it is done in the stable file > > format. > > > > On the other hand what this would mean to stress the > > conversion/reversion round trip. > > > > This could be implemented as some kind of option to set, by default, > > the save file format version or even better, because in this case this > > is what it intended, the target version. > > > > In the preferences file this could go as: > > > > \save_file_format 2.4 > > > > If this option is not set then everything works as usual. > > If it is set then, when the file is saved, the file is reverted to that > > file format. > > > > I hope that this idea helps, :-) > > That is a good idea. It's too late for 2.4.x, but if it were added early to > master, then it would be usable for Scott's purpose. > > The roundtrip would of course only matter if one made use of features that > required a format change. Thanks, that is a good idea, but I would not want to use that setting for most of my documents. I find that doing repeated lyx2lyx does not create a smooth workflow. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On 4/7/24 12:46, José Matos wrote: On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote: Fair enough. That was what I was afraid of (and expected). Scott A possible mid-term solution, to your use case, is to set the output format of the latest stable version. This would mean that any document is always imported to the latest development release and when saved it is done in the stable file format. On the other hand what this would mean to stress the conversion/reversion round trip. This could be implemented as some kind of option to set, by default, the save file format version or even better, because in this case this is what it intended, the target version. In the preferences file this could go as: \save_file_format 2.4 If this option is not set then everything works as usual. If it is set then, when the file is saved, the file is reverted to that file format. I hope that this idea helps, :-) That is a good idea. It's too late for 2.4.x, but if it were added early to master, then it would be usable for Scott's purpose. The roundtrip would of course only matter if one made use of features that required a format change. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Sun, 2024-04-07 at 11:31 -0400, Scott Kostyshak wrote: > Fair enough. That was what I was afraid of (and expected). > > Scott A possible mid-term solution, to your use case, is to set the output format of the latest stable version. This would mean that any document is always imported to the latest development release and when saved it is done in the stable file format. On the other hand what this would mean to stress the conversion/reversion round trip. This could be implemented as some kind of option to set, by default, the save file format version or even better, because in this case this is what it intended, the target version. In the preferences file this could go as: \save_file_format 2.4 If this option is not set then everything works as usual. If it is set then, when the file is saved, the file is reverted to that file format. I hope that this idea helps, :-) -- José Abílio -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
On Sun, Apr 07, 2024 at 06:32:47AM GMT, Jürgen Spitzmüller wrote: > Am Samstag, dem 06.04.2024 um 16:51 -0400 schrieb Scott Kostyshak: > > I imagine others face the same situation? Is there anything that can > > be done? > > No, I think this will be a nightmare to maintain. And then, you really > do not "text master" if you strip the most interesting commits. Fair enough. That was what I was afraid of (and expected). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: File format increases on master make it hard to test
Am Samstag, dem 06.04.2024 um 16:51 -0400 schrieb Scott Kostyshak: > I imagine others face the same situation? Is there anything that can > be done? No, I think this will be a nightmare to maintain. And then, you really do not "text master" if you strip the most interesting commits. -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
File format increases on master make it hard to test
I've been enjoying testing master, but on the first file format increment, I'll stop a lot of my testing since they're documents I will want to work on with other people. I have a few documents that only I use and for that I'll try to continue to test master. I imagine others face the same situation? Is there anything that can be done? I remember that Guillaume used to maintain a lyx-unstable (I think this was the name) where I think he removed the file format updates. How hard would that be to maintain? I guess ideally anything that doesn't involve a file format bump would also eventually be pushed to 2.4.x, so our testing of 2.4.x should help indirectly to test master, but there are a lot of commits that don't go to 2.4.x (for good reason). I guess an alternative would be to have a master-no-file-format branch, that gets all the commits master does except file format increments? But in this case it seems it would be less work to maintain the lyx-unstable referenced above, so that we don't have to double-commit each time? Not sure if anything can feasibly be done here, but wanted to ask. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fwd: DocBook test now failing on master
On Mon, Feb 26, 2024 at 04:14:14PM +0100, Thibaut Cuvelier wrote: > On Mon, 26 Feb 2024 at 16:00, Scott Kostyshak wrote: > > > On Mon, Feb 26, 2024 at 03:07:12PM +0100, Thibaut Cuvelier wrote: > > > On Mon, 26 Feb 2024 at 10:46, wrote: > > > > > > > Thank you so much, Thibaut. > > > > > > > > Could you send the patch to lyx-devel, so Scott can test it? I am too > > > > unsure about all things docbook to judge. > > > > > > > > > > I tried sending it to the mailing list, but my emails from my @lyx.org > > > alias are still refused :/. > > > > > > > > > > I will submit the bookauthor change this evening when I am back at my > > > > home machine. > > > > > > > > > > I didn't really test bookauthor, not knowing exactly what you had in mind > > > (the code for authors is more complex that I thought). > > > > > > @Scott: I have just pushed a fix for the initial issue! I tested it on > > the > > > basic test case, it seems to work (as tested with my usual DocBook setup, > > > which is not identical to LyX tests, but hopefully close enough). > > > > Thanks for working on a fix. Did you run jing on it? I still get the > > following after pulling in your fix: > > > > -- Calling: /usr/bin/java -jar > > "/home/scott/lyxbuilds/master-master/repo/development/tools/jing.jar" " > > https://docbook.org/xml/5.2b09/rng/docbook.rng"; "/home/ > > scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml" > > -- _err = 1, jingout = > > /home/scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml:379:1: > > error: text not allowed here; expected the element end-tag, element > > "abbrev", "abstract", "acronym", "address", "annotation", "artpagenums", > > "author", "authorgroup", "authorinitials", > > "bibliocoverage", "biblioid", "bibliomisc", "bibliomset", "bibliorelation", > > "biblioset", "bibliosource", "citebiblioid", "citerefentry", > > "citetitle", "collab", "confgroup", "contractnum", "contractsponsor", > > "copyright", "coref", "cover", "date", "edition", "editor", "emphasis", > > "extendedlink", "firstterm", "footnote", "footnoteref", "foreignphrase", > > "glossterm", "issuenum", "itermset", "keywordset", "legalnotice", > > "mediaobject", "org", "orgname", "othercredit", "pagenums", "person", > > "personblurb", "personname", "phrase", "printhistory", "productname", > > "productnumber", "pubdate", "publisher", "publishername", > > "quote", "releaseinfo", "revhistory", "revnumber", "seriesvolnums", > > "subjectset", "subscript", "subtitle", "superscript", "title", > > "titleabbrev", "volumenum" or "wordasword" or an element from another > > namespace > > > > I had trouble replicating this one locally, it should no longer appear as > of 2be72a15. Thanks, works well here now! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fwd: DocBook test now failing on master
On Mon, 26 Feb 2024 at 16:00, Scott Kostyshak wrote: > On Mon, Feb 26, 2024 at 03:07:12PM +0100, Thibaut Cuvelier wrote: > > On Mon, 26 Feb 2024 at 10:46, wrote: > > > > > Thank you so much, Thibaut. > > > > > > Could you send the patch to lyx-devel, so Scott can test it? I am too > > > unsure about all things docbook to judge. > > > > > > > I tried sending it to the mailing list, but my emails from my @lyx.org > > alias are still refused :/. > > > > > > > I will submit the bookauthor change this evening when I am back at my > > > home machine. > > > > > > > I didn't really test bookauthor, not knowing exactly what you had in mind > > (the code for authors is more complex that I thought). > > > > @Scott: I have just pushed a fix for the initial issue! I tested it on > the > > basic test case, it seems to work (as tested with my usual DocBook setup, > > which is not identical to LyX tests, but hopefully close enough). > > Thanks for working on a fix. Did you run jing on it? I still get the > following after pulling in your fix: > > -- Calling: /usr/bin/java -jar > "/home/scott/lyxbuilds/master-master/repo/development/tools/jing.jar" " > https://docbook.org/xml/5.2b09/rng/docbook.rng"; "/home/ > scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml" > -- _err = 1, jingout = > /home/scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml:379:1: > error: text not allowed here; expected the element end-tag, element > "abbrev", "abstract", "acronym", "address", "annotation", "artpagenums", > "author", "authorgroup", "authorinitials", > "bibliocoverage", "biblioid", "bibliomisc", "bibliomset", "bibliorelation", > "biblioset", "bibliosource", "citebiblioid", "citerefentry", > "citetitle", "collab", "confgroup", "contractnum", "contractsponsor", > "copyright", "coref", "cover", "date", "edition", "editor", "emphasis", > "extendedlink", "firstterm", "footnote", "footnoteref", "foreignphrase", > "glossterm", "issuenum", "itermset", "keywordset", "legalnotice", > "mediaobject", "org", "orgname", "othercredit", "pagenums", "person", > "personblurb", "personname", "phrase", "printhistory", "productname", > "productnumber", "pubdate", "publisher", "publishername", > "quote", "releaseinfo", "revhistory", "revnumber", "seriesvolnums", > "subjectset", "subscript", "subtitle", "superscript", "title", > "titleabbrev", "volumenum" or "wordasword" or an element from another > namespace > I had trouble replicating this one locally, it should no longer appear as of 2be72a15. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Fwd: DocBook test now failing on master
On Mon, Feb 26, 2024 at 03:07:12PM +0100, Thibaut Cuvelier wrote: > On Mon, 26 Feb 2024 at 10:46, wrote: > > > Thank you so much, Thibaut. > > > > Could you send the patch to lyx-devel, so Scott can test it? I am too > > unsure about all things docbook to judge. > > > > I tried sending it to the mailing list, but my emails from my @lyx.org > alias are still refused :/. > > > > I will submit the bookauthor change this evening when I am back at my > > home machine. > > > > I didn't really test bookauthor, not knowing exactly what you had in mind > (the code for authors is more complex that I thought). > > @Scott: I have just pushed a fix for the initial issue! I tested it on the > basic test case, it seems to work (as tested with my usual DocBook setup, > which is not identical to LyX tests, but hopefully close enough). Thanks for working on a fix. Did you run jing on it? I still get the following after pulling in your fix: -- Calling: /usr/bin/java -jar "/home/scott/lyxbuilds/master-master/repo/development/tools/jing.jar" "https://docbook.org/xml/5.2b09/rng/docbook.rng"; "/home/ scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml" -- _err = 1, jingout = /home/scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_ZafZvY/export/docbook/basic.xml:379:1: error: text not allowed here; expected the element end-tag, element "abbrev", "abstract", "acronym", "address", "annotation", "artpagenums", "author", "authorgroup", "authorinitials", "bibliocoverage", "biblioid", "bibliomisc", "bibliomset", "bibliorelation", "biblioset", "bibliosource", "citebiblioid", "citerefentry","citetitle", "collab", "confgroup", "contractnum", "contractsponsor", "copyright", "coref", "cover", "date", "edition", "editor", "emphasis", "extendedlink", "firstterm", "footnote", "footnoteref", "foreignphrase", "glossterm", "issuenum", "itermset", "keywordset", "legalnotice", "mediaobject", "org", "orgname", "othercredit", "pagenums", "person", "personblurb", "personname", "phrase", "printhistory", "productname", "productnumber", "pubdate", "publisher", "publishername", "quote", "releaseinfo", "revhisto ry", "revnumber", "seriesvolnums", "subjectset", "subscript", "subtitle", "superscript", "title", "titleabbrev", "volumenum" or "wordasword" or an element from another namespace Scott -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: DocBook test now failing on master
Am Sonntag, dem 25.02.2024 um 07:23 +0100 schrieb Jürgen Spitzmüller: > I suppose DocBook does not know how to handle booksubtitle and > journalsubtitle (both standard biblatex fields). The other field, > subtitle, seems to be covered already. > > Thibaut? While you are at it, could you please also check whether "bookauthor" is supported? This is also missing from the preview and supposedly docbook/xhtml output currently. It's easy to add in the cite format, but I refrain from doing it if it breaks docbook. -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: DocBook test now failing on master
Am Samstag, dem 24.02.2024 um 19:53 -0500 schrieb Scott Kostyshak: > The following test now fails for me on current master: > > export/export/docbook/basic_docbook5 > > It does not necessarily mean there's a regression. From what I > understand, DocBook support is fragile for some things so it may be > that > our DocBook export mechanism needs to adapt to a new feature that was > introduced? I suppose DocBook does not know how to handle booksubtitle and journalsubtitle (both standard biblatex fields). The other field, subtitle, seems to be covered already. Thibaut? If this is too difficult to handle now, I can revert 337f9534260 and we re-introduce that later. -- Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
DocBook test now failing on master
The following test now fails for me on current master: export/export/docbook/basic_docbook5 It does not necessarily mean there's a regression. From what I understand, DocBook support is fragile for some things so it may be that our DocBook export mechanism needs to adapt to a new feature that was introduced? The log has the following output now: -- Calling: /usr/bin/java -jar "/home/scott/lyxbuilds/master-master/repo/development/tools/jing.jar" "https://docbook.org/xml/5.2b09/rng/docbook.rng"; "/home/scott/lyxbuilds/master-master/ CMakeBuild/autotests/out-home/AbC_NVwGj_/export/docbook/basic.xml" -- _err = 1, jingout = /home/scott/lyxbuilds/master-master/CMakeBuild/autotests/out-home/AbC_NVwGj_/export/docbook/basic.xml:385:1: error: text not allowed here; expected the element end- tag, element "abbrev", "abstract", "acronym", "address", "annotation", "artpagenums", "author", "authorgroup", "authorinitials", "bibliocoverage", "biblioid", "bibliomisc", "bibliomset","bibliorelation", "biblioset", "bibliosource", "citebiblioid", "citerefentry", "citetitle", "collab", "confgroup", "contractnum", "contractsponsor", "copyright", "coref", "cover", "date", "edition", "editor", "emphasis", "extendedlink", "firstterm", "footnote", "footnoteref", "foreignphrase", "glossterm", "issuenum", "itermset", "keywordset", "legalnotice", "mediaobject","org", "orgname", "othercredit", "pagenums", "person", "personblurb", "personname", "phrase", "printhistory", "productname", "productnumber", "pubdate", "publisher", "publishername", "quote", "releaseinfo", "revhistory", "revnumber", "seriesvolnums", "subjectset", "subscript", "subtitle", "superscript", "title", "titleabbrev", "volumenum" or "wordasword" or an element from another namespace Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
test
Dear manager, Good day. This is Fiona from Hebei Juying Hoisting Machinery Co.,Ltd. Our factory mainly produces chain hoist, electric hoist , lifting belt,load chain,hand pallet truck & various lifting equipment. And we have rich export experience for more than 10 years. If any related products you need, welcome to contact with me. Thank you & best regards, Fiona www.hbjuyinggroup.com www.jymhoist.com https://juyingqz.en.alibaba.com Company: Hebei Juying Hoisting Machinery Co.,Ltd. Address: Donglv village, Qingyuan Block, Baoding City, Hebei Province,China. Email:bryanty...@hbjuying.com Wechat/Whatsapp: +86 15127251365 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test
I received your test, and it was signed. By the way, that's cool you can add an alias, i.e., I see: gpg: Good signature from "Kornel Benko " [full] gpg: aka "Kornel Benko " [full] I did not know you could do that. That's helpful to know. Note that I did not see any text content to your message (I imagine this was intended but just in case I let you know). Scott On Thu, Jun 23, 2022 at 11:19:50AM +0200, Kornel Benko wrote: > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Test
pgp4Sqj8KCzM2.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: A docbook test is failing on current master
On Sun, Apr 03, 2022 at 03:41:43AM +0200, Thibaut Cuvelier wrote: > On Sat, 2 Apr 2022 at 20:24, Scott Kostyshak wrote: > > > The following test fails for me on current master: > > > > export/export/xhtml/table_borders_docbook5 > > > > Thanks for the notice! It's been fixed as e7ed8213ac. Thanks for the quick fix. Works well! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: A docbook test is failing on current master
On Sat, 2 Apr 2022 at 20:24, Scott Kostyshak wrote: > The following test fails for me on current master: > > export/export/xhtml/table_borders_docbook5 > Thanks for the notice! It's been fixed as e7ed8213ac. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
A docbook test is failing on current master
The following test fails for me on current master: export/export/xhtml/table_borders_docbook5 Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Cmake build: Fix the invalid test for '-Wno-deprecated-copy' flag
Am Wed, 29 Sep 2021 18:16:44 +0200 schrieb Jean-Marc Lasgouttes : > Le 29/09/2021 à 17:32, Kornel Benko a écrit : > > commit c26db650a1e93573e4c09d4612ad45ae1e219854 > > Author: Kornel Benko > > Date: Wed Sep 29 17:53:50 2021 +0200 > > > > Cmake build: Fix the invalid test for '-Wno-deprecated-copy' flag > > > > The original test was always successfull, even if the flag was invalid. > > But checking for '-Wdeprecated-copy' instead yields to error if the > > warning does > > not exist. Existent warning for 'deprecated-copy' implies that > > 'no-deprecated-copy' > > also exist. > > Excellent idea. I stole it. :) > JMarc It was driving me crazy. The test looked correct, still there were warnings about 'unrecognized command line option'. Kornel pgpsV34Q6efMa.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Wed, Nov 11, 2020 at 04:32:57PM +1300, Sam Crawley wrote: > I hereby grant permission to license my contributions to LyX under the GNU > General Public License, version 2 or any later version. Thanks, I added you to credits. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sat, Nov 14, 2020 at 11:28:43AM -0500, Richard Kimberly Heck wrote: > On 11/13/20 8:24 PM, Scott Kostyshak wrote: > > On Sat, Nov 14, 2020 at 01:43:08AM +0100, Kornel Benko wrote: > >> Am Sat, 14 Nov 2020 13:22:39 +1300 > >> schrieb "Sam Crawley" : > >> > >>> On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote: > >>>>> Defined at development/checkurls/CMakeLists.txt:8 > >>>>> find_package(Perl REQUIRED) > >>>>> > >>>>> Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should > >>>>> move the > >>>>> find_package() call to different place, maybe to the main > >>>>> CMakeLists.txt. > >>>>> > >>>>> Kornel > >>>> Hm, done at 5680a4d3. > >>> Thanks, that fixed it! > >>> > >>> Updated patchset attached. > >>> > >>> Thanks, > >>> Sam. > >> Thanks, test works. > >> From my side, it can be committed. Any objections? > >> Pavel, Jean-Marc, Riki, Scott? > > I did not take a look, but I do not have any objection. If it's fine > > with you it's fine with me. > > +1 Committed. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On 11/13/20 8:24 PM, Scott Kostyshak wrote: > On Sat, Nov 14, 2020 at 01:43:08AM +0100, Kornel Benko wrote: >> Am Sat, 14 Nov 2020 13:22:39 +1300 >> schrieb "Sam Crawley" : >> >>> On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote: >>>>> Defined at development/checkurls/CMakeLists.txt:8 >>>>> find_package(Perl REQUIRED) >>>>> >>>>> Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should >>>>> move the >>>>> find_package() call to different place, maybe to the main CMakeLists.txt. >>>>> >>>>> Kornel >>>> Hm, done at 5680a4d3. >>> Thanks, that fixed it! >>> >>> Updated patchset attached. >>> >>> Thanks, >>> Sam. >> Thanks, test works. >> From my side, it can be committed. Any objections? >> Pavel, Jean-Marc, Riki, Scott? > I did not take a look, but I do not have any objection. If it's fine > with you it's fine with me. +1 Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sat, Nov 14, 2020 at 01:43:08AM +0100, Kornel Benko wrote: > Am Sat, 14 Nov 2020 13:22:39 +1300 > schrieb "Sam Crawley" : > > > On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote: > > > > > > > > Defined at development/checkurls/CMakeLists.txt:8 > > > > find_package(Perl REQUIRED) > > > > > > > > Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should > > > > move the > > > > find_package() call to different place, maybe to the main > > > > CMakeLists.txt. > > > > > > > > Kornel > > > > > > Hm, done at 5680a4d3. > > > > Thanks, that fixed it! > > > > Updated patchset attached. > > > > Thanks, > > Sam. > > Thanks, test works. > From my side, it can be committed. Any objections? > Pavel, Jean-Marc, Riki, Scott? I did not take a look, but I do not have any objection. If it's fine with you it's fine with me. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Sat, 14 Nov 2020 13:22:39 +1300 schrieb "Sam Crawley" : > On Sat, 14 Nov 2020, at 12:36, Kornel Benko wrote: > > > > > > Defined at development/checkurls/CMakeLists.txt:8 > > > find_package(Perl REQUIRED) > > > > > > Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should > > > move the > > > find_package() call to different place, maybe to the main CMakeLists.txt. > > > > > > Kornel > > > > Hm, done at 5680a4d3. > > Thanks, that fixed it! > > Updated patchset attached. > > Thanks, > Sam. Thanks, test works. From my side, it can be committed. Any objections? Pavel, Jean-Marc, Riki, Scott? Kornel pgpvSqUi3K_D7.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Fri, 13 Nov 2020 23:42:29 +0100 schrieb Kornel Benko : > Am Sat, 14 Nov 2020 10:55:48 +1300 > schrieb "Sam Crawley" : > > > On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote: > > > Running the test I get: > > > ... > > > Can't exec > > > "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl": > > > Permission denied > > > at /BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/lyx_batch.pl line > > > 195. > > > ... > > > > > > The attached diff to your lyx_batch.pl.in cures it. > > > > Hmm, the @PERL_EXECUTABLE@ macro doesn't expand for me. Is there something > > I need to > > do to make that work? > > > > Sam. > > Defined at development/checkurls/CMakeLists.txt:8 > find_package(Perl REQUIRED) > > Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should move the > find_package() call to different place, maybe to the main CMakeLists.txt. > > Kornel Hm, done at 5680a4d3. Kornel pgpbhutG3NdlQ.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Fri, 13 Nov 2020 23:42:29 +0100
schrieb Kornel Benko :
> Am Sat, 14 Nov 2020 10:55:48 +1300
> schrieb "Sam Crawley" :
>
> > On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote:
> > > Running the test I get:
> > > ...
> > > Can't exec
> > > "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl":
> > > Permission denied
> > > at /BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/lyx_batch.pl line
> > > 195.
> > > ...
> > >
> > > The attached diff to your lyx_batch.pl.in cures it.
> >
> > Hmm, the @PERL_EXECUTABLE@ macro doesn't expand for me. Is there something
> > I need to
> > do to make that work?
> >
> > Sam.
>
> Defined at development/checkurls/CMakeLists.txt:8
> find_package(Perl REQUIRED)
>
> Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should move the
> find_package() call to different place, maybe to the main CMakeLists.txt.
>
> Kornel
Or, for now, change the development/batchtests/CMakeLists.txt.
Kornel
diff --git a/development/batchtests/CMakeLists.txt b/development/batchtests/CMakeLists.txt
index 87a741deee..f93f233d74 100644
--- a/development/batchtests/CMakeLists.txt
+++ b/development/batchtests/CMakeLists.txt
@@ -6,12 +6,16 @@ string(TOUPPER "${testlabel}_" testprefix)
macro(add_batch_test testname testpar)
add_test(NAME "${testprefix}${testname}" COMMAND ${PERL_EXECUTABLE} ${CMAKE_BINARY_DIR}/lyx_batch.pl ${testpar})
setmarkedtestlabel(${testprefix}${testname} ${ARGN} "${testlabel}")
endmacro()
+# Tests not working without defined PERL_EXECUTABLE
+find_package(Perl REQUIRED)
+
add_batch_test(outline-beamer beamer_test "export")
# Checking that info inset correctly fills up VCS information
# see also bug #10835
add_batch_test(vcs-info vcs_info_export)
add_batch_test(AMS-import ams-import "tex2lyx")
add_batch_test(SAVE-as save_as_test "export")
+add_batch_test(compare-test compare_test "compare_test")
pgpZlaKbNgUBN.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Sat, 14 Nov 2020 10:55:48 +1300 schrieb "Sam Crawley" : > On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote: > > Running the test I get: > > ... > > Can't exec > > "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl": > > Permission denied at > > /BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/lyx_batch.pl > > line 195. > > ... > > > > The attached diff to your lyx_batch.pl.in cures it. > > Hmm, the @PERL_EXECUTABLE@ macro doesn't expand for me. Is there something I > need to do > to make that work? > > Sam. Defined at development/checkurls/CMakeLists.txt:8 find_package(Perl REQUIRED) Apparently you do not have '-DLYX_ENABLE_URLTESTS:BOOL=ON'. We should move the find_package() call to different place, maybe to the main CMakeLists.txt. Kornel pgpQWy7nAL69k.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sat, 14 Nov 2020, at 00:12, Kornel Benko wrote: > Running the test I get: > ... > Can't exec > "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl": > Permission denied at > /BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/lyx_batch.pl > line 195. > ... > > The attached diff to your lyx_batch.pl.in cures it. Hmm, the @PERL_EXECUTABLE@ macro doesn't expand for me. Is there something I need to do to make that work? Sam.-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Fri, 13 Nov 2020 21:11:07 +1300
schrieb "Sam Crawley" :
> I've attached an updated patchset.
>
> As discussed, there's now a different parameter for "dialog-show compare"
> called
> "run-blocking", which is appropriate for calling from the command line. The
> tests now
> use this. A couple of other things tidied up too.
>
> Thanks,
> Sam.
>
> On Sun, 8 Nov 2020, at 17:14, Sam Crawley wrote:
> > Hi all,
> >
> > I've created a fairly basic test suite for the Compare function. It uses the
> > lyx_batch.pl script to run compare on two files, and then does a comparison
> > with an
> > expected diff file.
> >
> > This is the first step in some changes I'd like to make to the compare
> > function (see
> > #6889).
> >
> > Comments welcome, and also happy to have suggestions for additional test
> > cases.
> >
> > Thanks,
> > Sam.
Running the test I get:
...
Can't exec "/usr2/src/lyx/lyx-git/development/batchtests/bin/compare_custom.pl":
Permission denied at
/BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/lyx_batch.pl
line 195.
...
The attached diff to your lyx_batch.pl.in cures it.
Another idea is making compare_custom.pl a module.
Kornel
--- lib/scripts/lyx_batch.pl.in.my 2020-11-13 12:05:14.906837305 +0100
+++ lib/scripts/lyx_batch.pl.in 2020-11-13 12:08:38.201504314 +0100
@@ -27,7 +27,6 @@
my $data = "$lyxsource/development/batchtests";
my $test_bin = "$lyxsource/development/batchtests/bin";
my $comparepdf = "@COMPAREPDF_EXECUTABLE@";
-my $perl = "@PERL_EXECUTABLE@";
# src_files := Files to be copied from lyx-source to build-dir
@@ -87,7 +86,7 @@
"compare_test" => {
src_files => ["old.lyx", "new.lyx"],
check_type => 'custom',
- check_script => ["$perl","$test_bin/compare_custom.pl"],
+ check_script => "$test_bin/compare_custom.pl",
test_dir => "$lyxsource/development/batchtests/compare_tests/",
check => [["diffs.lyx", "diffs.expected.lyx"]],
commands => [
@@ -256,7 +255,7 @@
$result = 0;
}
elsif ($check_type eq 'custom') {
-$result = system1(@{$check_script}, $expected, $created);
+$result = system1($check_script, $expected, $created);
}
elsif ($check_type eq 'text') {
# defaut text comparision
pgp1M7sZ1FowG.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Thu, Nov 12, 2020 at 08:57:42PM +1300, Sam Crawley wrote: > In that case, I'll add a different parameter to the LFUN to differentiate > between case (ii) and (iii). So instead of passing "run" (and the two file > names), you will pass "run-sync" to indicate that you want it to block for > the results. (Alternatively it could be "run-cmd" to indicate the command > line, but it technically could be called in other ways, so "run-sync" is more > general). > > Does that sound reasonable? Yes. Maybe run-block or run-barrier would sound more intutive. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Thu, 12 Nov 2020, at 00:18, Pavel Sanda wrote: > On Wed, Nov 11, 2020 at 09:10:09PM +1300, Sam Crawley wrote: > > > > I'm not sure I understand. When cmd_mode == true (which is always the case > > when run() is invoked via the LFUN), > > Maybe I do not understand your intentions then. I thought you > introduced cmd_mode to distinguish command line case, but now you say > it should be always true (when called via lfun). > I'll try to explain my concern from a different angle, maybe we'll meet > that way: > To my knowledge you had two ways to reach 'run' - either (i) normally > through compare dialog's OK or (ii) via version control history > comparison trigger. > And then perhaps (iii) via commandline, which I believe no one ever > seriously tried and per your comments might not even work due to > synchronization issues. > he (ii) case was hijacking slotOK call in initializeparams to mimick as > if the comparison was normally launched by user. > > Now, your patch is fixing (iii) but at the same time undoing the logic > of how error() and finished() is used in case (ii) so my concern is > that (ii) will be broken. > My first thought was that cmd_mode was intended to distinguish (ii) and > (iii) and let (ii) to stay untouched but the rest of code and our > discussion suggest otherwise. > Does it make sense now? > Thanks, yes I understand now. I didn't realise the VC compare invoked Compare in the same way I am from the command line, and my changes will indeed break it. In that case, I'll add a different parameter to the LFUN to differentiate between case (ii) and (iii). So instead of passing "run" (and the two file names), you will pass "run-sync" to indicate that you want it to block for the results. (Alternatively it could be "run-cmd" to indicate the command line, but it technically could be called in other ways, so "run-sync" is more general). Does that sound reasonable? Thanks, Sam. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Wed, Nov 11, 2020 at 09:10:09PM +1300, Sam Crawley wrote: > > 2) It seems that if (!cmd_mode) you will call finished(false) twice > > thus wrongly > >reverting the toggles from FuncRequest(LFUN_CHANGES_OUTPUT) in > > finished(), right? > > I'm not sure I understand. When cmd_mode == true (which is always the case > when run() is invoked via the LFUN), Maybe I do not understand your intentions then. I thought you introduced cmd_mode to distinguish command line case, but now you say it should be always true (when called via lfun). I'll try to explain my concern from a different angle, maybe we'll meet that way: To my knowledge you had two ways to reach 'run' - either (i) normally through compare dialog's OK or (ii) via version control history comparison trigger. And then perhaps (iii) via commandline, which I believe no one ever seriously tried and per your comments might not even work due to synchronization issues. he (ii) case was hijacking slotOK call in initializeparams to mimick as if the comparison was normally launched by user. Now, your patch is fixing (iii) but at the same time undoing the logic of how error() and finished() is used in case (ii) so my concern is that (ii) will be broken. My first thought was that cmd_mode was intended to distinguish (ii) and (iii) and let (ii) to stay untouched but the rest of code and our discussion suggest otherwise. Does it make sense now? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Wed, 11 Nov 2020, at 00:31, Pavel Sanda wrote: > So I looked at the code for the command line run at this place looks > good enough. Thanks for having a look. > I have another concerns though: > 1) slotOK contains error() call which seems to be missed now. If you > don't want it for >commandline run it should be conditioned on cmd_mode. Yes, fair point. I'll add the error checking back in when it's run via the command line. > 2) It seems that if (!cmd_mode) you will call finished(false) twice > thus wrongly >reverting the toggles from FuncRequest(LFUN_CHANGES_OUTPUT) in > finished(), right? I'm not sure I understand. When cmd_mode == true (which is always the case when run() is invoked via the LFUN), then finished will always be called after the wait(), and only once. If cmd_mode == false (which is always the case when run() is otherwise invoked) then finished() is connected to the finished signal from the Compare worker thread. So I'm not seeing the case where finished is called twice, although I may well have missed something. > > Small glitches: > 2) Please add explaining comment for the cmd_mode parameter to the > header. > 3) As said in previous mail I would set timer either to infinity (or to > something >realistically short if you insist on some timing wall). Thanks, I'll fix those, and update the patchset soon (with some of the other suggestions in this thread as well). Sam. -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
I hereby grant permission to license my contributions to LyX under the GNU General Public License, version 2 or any later version. Sam Crawley. On Tue, 10 Nov 2020, at 23:39, Kornel Benko wrote: > Am Sun, 8 Nov 2020 11:32:59 +0100 > schrieb Pavel Sanda : > > > On Sun, Nov 08, 2020 at 05:14:42PM +1300, Sam Crawley wrote: > > > Hi all, > > > > Hi Sam, > > > > welcome and thanks for working on this. Couple small things: > > > > - Please send in a separate email to our list the following GPL statement: > > > > I hereby grant permission to license my contributions to LyX under the GNU > > General Public License, version 2 or any later version. > > Ping > > Kornel > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Mon, Nov 09, 2020 at 01:03:47AM +0100, Pavel Sanda wrote:
> > > > @@ -343,7 +348,12 @@ bool GuiCompare::initialiseParams(std::string
> > > > const &par)
> > > > if (cmd.getArg(0) == "run") {
> > > > oldFileCB->setEditText(toqstr(cmd.getArg(1)));
> > > > newFileCB->setEditText(toqstr(cmd.getArg(2)));
> > > > - slotOK();
> > > > +enableControls(false);
> > > > +run(true);
> > > > +
> > > > +compare_->wait(100);
> > >
> > > On a first sight this looks fishy. We unconditionally launch run
> > > on the place we previously did not without dependency on cmd_mode.
> > > Do I miss something?
> >
> > Previously run() was called through slotOK(). The problem is, when invoking
> > compare from the command line, the next command in the sequence was getting
> > executed before the compare was finished because the compare code was
> > getting executed in a thread (and so buffer-write-as couldn't find a buffer
> > to write, as it had not yet been created).
> >
> > Just adding the 'wait()' call was not enough, because the 'finished' signal
> > still happened asynchronously, so I also added the parameter to run() so
> > that the finished signal is not connected to (and then called the
> > finished() method manually afterwards). There may be a cleaner way to do
> > this, I'm happy to hear suggestions. But the current approach at least
> > didn't seem terrible to me. It probably could use a comment to explain
> > this, though, which I'll add.
>
> Ok, I will dig into the code later. Launching run inside initialiseParams
> looks strange.
So I looked at the code for the command line run at this place looks good
enough.
I have another concerns though:
1) slotOK contains error() call which seems to be missed now. If you don't want
it for
commandline run it should be conditioned on cmd_mode.
2) It seems that if (!cmd_mode) you will call finished(false) twice thus wrongly
reverting the toggles from FuncRequest(LFUN_CHANGES_OUTPUT) in finished(),
right?
Small glitches:
2) Please add explaining comment for the cmd_mode parameter to the header.
3) As said in previous mail I would set timer either to infinity (or to
something
realistically short if you insist on some timing wall).
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Sun, 8 Nov 2020 11:32:59 +0100 schrieb Pavel Sanda : > On Sun, Nov 08, 2020 at 05:14:42PM +1300, Sam Crawley wrote: > > Hi all, > > Hi Sam, > > welcome and thanks for working on this. Couple small things: > > - Please send in a separate email to our list the following GPL statement: > > I hereby grant permission to license my contributions to LyX under the GNU > General Public License, version 2 or any later version. Ping Kornel pgpl67WRkdSvo.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Mon, Nov 09, 2020 at 09:19:42AM +1300, Sam Crawley wrote:
> On Sun, 8 Nov 2020, at 23:32, Pavel Sanda wrote:
>
> > Git commit messages tend to have the following structure: first summary
> > line,
> > empty line and then the details. This helps with log summaries.
>
> That is the format I used, unless I'm missing something. The 'subject' line
> in a git patch file is the first line of the commit message.
My oversight, it's indeed inside subject line.
> > > @@ -343,7 +348,12 @@ bool GuiCompare::initialiseParams(std::string const
> > > &par)
> > > if (cmd.getArg(0) == "run") {
> > > oldFileCB->setEditText(toqstr(cmd.getArg(1)));
> > > newFileCB->setEditText(toqstr(cmd.getArg(2)));
> > > - slotOK();
> > > +enableControls(false);
> > > +run(true);
> > > +
> > > +compare_->wait(100);
> >
> > On a first sight this looks fishy. We unconditionally launch run
> > on the place we previously did not without dependency on cmd_mode.
> > Do I miss something?
>
> Previously run() was called through slotOK(). The problem is, when invoking
> compare from the command line, the next command in the sequence was getting
> executed before the compare was finished because the compare code was getting
> executed in a thread (and so buffer-write-as couldn't find a buffer to write,
> as it had not yet been created).
>
> Just adding the 'wait()' call was not enough, because the 'finished' signal
> still happened asynchronously, so I also added the parameter to run() so that
> the finished signal is not connected to (and then called the finished()
> method manually afterwards). There may be a cleaner way to do this, I'm happy
> to hear suggestions. But the current approach at least didn't seem terrible
> to me. It probably could use a comment to explain this, though, which I'll
> add.
Ok, I will dig into the code later. Launching run inside initialiseParams looks
strange.
> > Secondly instead of waiting for arbitrary time, can't we just wait
> > until it finishes?
>
> The parameter to wait is just a timeout. It will block until the compare
> thread is complete, or the timeout is reached.
I understand that, but unless we have reasonable timeout (not two weeks) the
code with unconditional wait looks cleaner to me.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Mon, 09 Nov 2020 09:07:35 +1300 schrieb "Sam Crawley" : > On Mon, 9 Nov 2020, at 01:01, Kornel Benko wrote: > > Needed new perl module (Slurp.pm), got from package 'libfile-slurp-perl'. > > I think this use to be in Perl core, but it's now been taken out. I can > easily rewrite > if the dependency is a problem. No problem. Peoples who use the tests are rare here. The ones using it can live with occasionally installing some needed modules. Kornel pgpuOP_hTbkNb.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Mon, 09 Nov 2020 09:00:48 +1300 schrieb "Sam Crawley" : > On Sun, 8 Nov 2020, at 22:28, Kornel Benko wrote: > > Am Sun, 08 Nov 2020 17:14:42 +1300 > > schrieb "Sam Crawley" : > > ... > > > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in > > > index 2d93d27c59..32ef0f974a 100644 > > > --- a/lib/scripts/lyx_batch.pl.in > > > +++ b/lib/scripts/lyx_batch.pl.in > > > @@ -8,11 +8,6 @@ use warnings; > > > use File::Copy; > > > use File::Compare; > > > > > > -sub checkPrecondition(); > > > -sub system1(@); > > > -sub addFiles($$$); > > > -sub mycompare($$$); > > > - > > > > Hm, why are you removing the prototypes? > > > > Kornel > > > > -- > > lyx-devel mailing list > > lyx-devel@lists.lyx.org > > http://lists.lyx.org/mailman/listinfo/lyx-devel > > The use of prototypes in Perl is generally discouraged (except in very > specific > circumstances), because they don't work in the way most people expect. In > this case, > the prototypes weren't actually being used, as all the function calls are > prefixed with > '&', which bypasses prototype checking. > Newer versions of Perl have support for signatures, but probably not really > worthwhile > using for this script. Just made more sense to remove them. Better to remove '&' IMHO. I was not aware of it. Kornel pgpsz7KNNgjVK.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sun, 8 Nov 2020, at 23:32, Pavel Sanda wrote:
> Git commit messages tend to have the following structure: first summary line,
> empty line and then the details. This helps with log summaries.
That is the format I used, unless I'm missing something. The 'subject' line in
a git patch file is the first line of the commit message.
>
>
> > src/frontends/qt/GuiCompare.cpp | 28 +++-
> > src/frontends/qt/GuiCompare.h | 2 +-
> > 2 files changed, 20 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/frontends/qt/GuiCompare.cpp
> > b/src/frontends/qt/GuiCompare.cpp
> > index d1da5b337f..380244a5c3 100644
> > --- a/src/frontends/qt/GuiCompare.cpp
> > +++ b/src/frontends/qt/GuiCompare.cpp
> > @@ -42,7 +42,7 @@ namespace frontend {
> >
> > GuiCompare::GuiCompare(GuiView & lv)
> > : GuiDialog(lv, "compare", qt_("Compare LyX files")),
> > - compare_(0), dest_buffer_(0), old_buffer_(0), new_buffer_(0)
> > + compare_(0), dest_buffer_(0), old_buffer_(0), new_buffer_(0)
>
> If possible try to separate patches with whitespace only changes and
> real code changes.
Yes, I'll fix that.
>
> > @@ -343,7 +348,12 @@ bool GuiCompare::initialiseParams(std::string const
> > &par)
> > if (cmd.getArg(0) == "run") {
> > oldFileCB->setEditText(toqstr(cmd.getArg(1)));
> > newFileCB->setEditText(toqstr(cmd.getArg(2)));
> > - slotOK();
> > +enableControls(false);
> > +run(true);
> > +
> > +compare_->wait(100);
>
> On a first sight this looks fishy. We unconditionally launch run
> on the place we previously did not without dependency on cmd_mode.
> Do I miss something?
Previously run() was called through slotOK(). The problem is, when invoking
compare from the command line, the next command in the sequence was getting
executed before the compare was finished because the compare code was getting
executed in a thread (and so buffer-write-as couldn't find a buffer to write,
as it had not yet been created).
Just adding the 'wait()' call was not enough, because the 'finished' signal
still happened asynchronously, so I also added the parameter to run() so that
the finished signal is not connected to (and then called the finished() method
manually afterwards). There may be a cleaner way to do this, I'm happy to hear
suggestions. But the current approach at least didn't seem terrible to me. It
probably could use a comment to explain this, though, which I'll add.
>
> Secondly instead of waiting for arbitrary time, can't we just wait
> until it finishes?
The parameter to wait is just a timeout. It will block until the compare thread
is complete, or the timeout is reached.
Thanks,
Sam.
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sun, 8 Nov 2020, at 22:28, Kornel Benko wrote: > Am Sun, 08 Nov 2020 17:14:42 +1300 > schrieb "Sam Crawley" : > ... > > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in > > index 2d93d27c59..32ef0f974a 100644 > > --- a/lib/scripts/lyx_batch.pl.in > > +++ b/lib/scripts/lyx_batch.pl.in > > @@ -8,11 +8,6 @@ use warnings; > > use File::Copy; > > use File::Compare; > > > > -sub checkPrecondition(); > > -sub system1(@); > > -sub addFiles($$$); > > -sub mycompare($$$); > > - > > Hm, why are you removing the prototypes? > > Kornel > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel The use of prototypes in Perl is generally discouraged (except in very specific circumstances), because they don't work in the way most people expect. In this case, the prototypes weren't actually being used, as all the function calls are prefixed with '&', which bypasses prototype checking. Newer versions of Perl have support for signatures, but probably not really worthwhile using for this script. Just made more sense to remove them.-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Mon, 9 Nov 2020, at 01:01, Kornel Benko wrote: > Needed new perl module (Slurp.pm), got from package 'libfile-slurp-perl'. I think this use to be in Perl core, but it's now been taken out. I can easily rewrite if the dependency is a problem.-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sun, Nov 08, 2020 at 12:48:11PM -0500, Richard Kimberly Heck wrote: > On 11/8/20 12:12 PM, Scott Kostyshak wrote: > > On Sun, Nov 08, 2020 at 11:32:59AM +0100, Pavel Sanda wrote: > >> Scott/Kornel will presumably review/check the testing part. > > I don't have much time to review or help, although I would be happy to take > > a look in the future (possibly not for a while though). Thanks to Pavel and > > Kornel for giving comments, and thanks to Sam for jumping down this rabbit > > hole! > > Agreed. This code needs some TLC. > > Can I make one suggestion about how to improve it? As it is now, it > compares files character by character. This can lead, in my experience, > to some weird and hard to read diffs. Would it be possible to adapt it > so that it could also read word by word where those are, say, split by > whitespace? I know that in some languages that would not make sense, so > this could be a choice the user could make. I agree, that would be a really nice improvement. I think that's Sam's main motivation for working on this (https://www.lyx.org/trac/ticket/6889#comment:24). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On 11/8/20 12:12 PM, Scott Kostyshak wrote: > On Sun, Nov 08, 2020 at 11:32:59AM +0100, Pavel Sanda wrote: >> Scott/Kornel will presumably review/check the testing part. > I don't have much time to review or help, although I would be happy to take a > look in the future (possibly not for a while though). Thanks to Pavel and > Kornel for giving comments, and thanks to Sam for jumping down this rabbit > hole! Agreed. This code needs some TLC. Can I make one suggestion about how to improve it? As it is now, it compares files character by character. This can lead, in my experience, to some weird and hard to read diffs. Would it be possible to adapt it so that it could also read word by word where those are, say, split by whitespace? I know that in some languages that would not make sense, so this could be a choice the user could make. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sun, Nov 08, 2020 at 11:32:59AM +0100, Pavel Sanda wrote: > > Scott/Kornel will presumably review/check the testing part. I don't have much time to review or help, although I would be happy to take a look in the future (possibly not for a while though). Thanks to Pavel and Kornel for giving comments, and thanks to Sam for jumping down this rabbit hole! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Sun, 8 Nov 2020 13:01:14 +0100 schrieb Kornel Benko : > Am Sun, 8 Nov 2020 10:28:51 +0100 > schrieb Kornel Benko : > > > Am Sun, 08 Nov 2020 17:14:42 +1300 > > schrieb "Sam Crawley" : > > ... > > > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in > > > index 2d93d27c59..32ef0f974a 100644 > > > --- a/lib/scripts/lyx_batch.pl.in > > > +++ b/lib/scripts/lyx_batch.pl.in > > > @@ -8,11 +8,6 @@ use warnings; > > > use File::Copy; > > > use File::Compare; > > > > > > -sub checkPrecondition(); > > > -sub system1(@); > > > -sub addFiles($$$); > > > -sub mycompare($$$); > > > - > > > > Hm, why are you removing the prototypes? > > > > Kornel > > Applies clean. > Needed new perl module (Slurp.pm), got from package 'libfile-slurp-perl'. > Test passes after 17 seconds. > All other batch tests are still OK. > > Nice work. (The testfiles old.lyx/new.lyx are hm... not very complex) > > Kornel Hm, I was mislead by the last result files (which are small). You could name the name tested documents differently (or use own directory (like in the source)) Kornel pgpvkSIWVGl70.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Sun, 8 Nov 2020 10:28:51 +0100 schrieb Kornel Benko : > Am Sun, 08 Nov 2020 17:14:42 +1300 > schrieb "Sam Crawley" : > ... > > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in > > index 2d93d27c59..32ef0f974a 100644 > > --- a/lib/scripts/lyx_batch.pl.in > > +++ b/lib/scripts/lyx_batch.pl.in > > @@ -8,11 +8,6 @@ use warnings; > > use File::Copy; > > use File::Compare; > > > > -sub checkPrecondition(); > > -sub system1(@); > > -sub addFiles($$$); > > -sub mycompare($$$); > > - > > Hm, why are you removing the prototypes? > > Kornel Applies clean. Needed new perl module (Slurp.pm), got from package 'libfile-slurp-perl'. Test passes after 17 seconds. All other batch tests are still OK. Nice work. (The testfiles old.lyx/new.lyx are hm... not very complex) Kornel pgpbO7U0_bW9z.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
On Sun, Nov 08, 2020 at 05:14:42PM +1300, Sam Crawley wrote:
> Hi all,
Hi Sam,
welcome and thanks for working on this. Couple small things:
- Please send in a separate email to our list the following GPL statement:
I hereby grant permission to license my contributions to LyX under the GNU
General Public License, version 2 or any later version.
> From c11d1d7fec19f2c37ed9e2a2162e1d2966d3c643 Mon Sep 17 00:00:00 2001
> From: Sam Crawley
> Date: Fri, 6 Nov 2020 20:56:09 +1300
> Subject: [PATCH 1/4] Fix issue in running compare as a command
>
> Because Compare uses threads, we need to make sure it is finished when a
> compare is "run" through a command. This was a problem for command
> sequences, because the next command would start running before the compare
> was done.
Git commit messages tend to have the following structure: first summary line,
empty line and then the details. This helps with log summaries.
> src/frontends/qt/GuiCompare.cpp | 28 +++-
> src/frontends/qt/GuiCompare.h | 2 +-
> 2 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/src/frontends/qt/GuiCompare.cpp b/src/frontends/qt/GuiCompare.cpp
> index d1da5b337f..380244a5c3 100644
> --- a/src/frontends/qt/GuiCompare.cpp
> +++ b/src/frontends/qt/GuiCompare.cpp
> @@ -42,7 +42,7 @@ namespace frontend {
>
> GuiCompare::GuiCompare(GuiView & lv)
> : GuiDialog(lv, "compare", qt_("Compare LyX files")),
> - compare_(0), dest_buffer_(0), old_buffer_(0), new_buffer_(0)
> + compare_(0), dest_buffer_(0), old_buffer_(0), new_buffer_(0)
If possible try to separate patches with whitespace only changes and
real code changes.
> @@ -343,7 +348,12 @@ bool GuiCompare::initialiseParams(std::string const &par)
> if (cmd.getArg(0) == "run") {
> oldFileCB->setEditText(toqstr(cmd.getArg(1)));
> newFileCB->setEditText(toqstr(cmd.getArg(2)));
> - slotOK();
> +enableControls(false);
> +run(true);
> +
> +compare_->wait(100);
On a first sight this looks fishy. We unconditionally launch run
on the place we previously did not without dependency on cmd_mode.
Do I miss something?
Secondly instead of waiting for arbitrary time, can't we just wait
until it finishes?
> From 9cdd8e876e812b6dd194df1f586a369fb5bcb3d7 Mon Sep 17 00:00:00 2001
> From: Sam Crawley
> Date: Fri, 6 Nov 2020 20:57:14 +1300
> Subject: [PATCH 2/4] Created initial test for compare function
>
> Runs the compare via a command line, and then compared the output to the
> expected result. Required adding a script to do the comparison, so that
> the timestamps on changes in the lyx file are ignored.
Scott/Kornel will presumably review/check the testing part.
Cheers,
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [Patch] Test suite for compare function
Am Sun, 08 Nov 2020 17:14:42 +1300 schrieb "Sam Crawley" : ... > diff --git a/lib/scripts/lyx_batch.pl.in b/lib/scripts/lyx_batch.pl.in > index 2d93d27c59..32ef0f974a 100644 > --- a/lib/scripts/lyx_batch.pl.in > +++ b/lib/scripts/lyx_batch.pl.in > @@ -8,11 +8,6 @@ use warnings; > use File::Copy; > use File::Compare; > > -sub checkPrecondition(); > -sub system1(@); > -sub addFiles($$$); > -sub mycompare($$$); > - Hm, why are you removing the prototypes? Kornel pgpCIsaToudZY.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx roundtrip test failing with BibTeX errors
On Thu, Aug 27, 2020 at 05:32:18AM +0200, Jürgen Spitzmüller wrote: > Am Dienstag, den 25.08.2020, 12:40 -0400 schrieb Scott Kostyshak: > > On Mon, Aug 24, 2020 at 01:02:36AM -0400, Scott Kostyshak wrote: > > > The following test fails for me: > > > > > > > > export/templates/Articles/American_Psychological_Association_%28APA%2 > > 9,_v._7_lyx22 (Failed) > > > > > > To reproduce: > > > > > > lyx -e lyx22x > > American_Psychological_Association_%28APA%29,_v._7.lyx && lyx -e pdf2 > > American_Psychological_Association_%28APA%29,_v._7.22.lyx > > > > > > I get the following errors when exporting from the GUI: > > > > > > This is BibTeX, Version 0.99d (TeX Live 2020) > > > Capacity: max_strings=20, hash_size=20, hash_prime=170003 > > > The top-level auxiliary file: > > American_Psychological_Association__28APA_29,_v._7.22.aux > > > I found no \citation commands---while reading file > > American_Psychological_Association__28APA_29,_v._7.22.aux > > > I found no \bibdata command---while reading file > > American_Psychological_Association__28APA_29,_v._7.22.aux > > > I found no \bibstyle command---while reading file > > American_Psychological_Association__28APA_29,_v._7.22.aux > > > > I'm guessing this happens because we export ERT/preamble stuff in the > > backwards conversion, and in the forwards conversion we > > (understandably) > > do not take into account the ERT. Unless anyone wants to take a > > closer > > look, I plan to invert the test (i.e., mark in the ctests that we > > expect > > this test to fail), especially since it is regarding 2.2.x and not > > even > > 2.3.x. > > In this particular case, it is because this file uses Biblatex, so it > is expected that BibTeX fails on it. And the reversion to ERT is the > reason why Biblatex is not detected. Makes sense, thanks for taking a look. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx roundtrip test failing with BibTeX errors
Am Dienstag, den 25.08.2020, 12:40 -0400 schrieb Scott Kostyshak: > On Mon, Aug 24, 2020 at 01:02:36AM -0400, Scott Kostyshak wrote: > > The following test fails for me: > > > > > export/templates/Articles/American_Psychological_Association_%28APA%2 > 9,_v._7_lyx22 (Failed) > > > > To reproduce: > > > > lyx -e lyx22x > American_Psychological_Association_%28APA%29,_v._7.lyx && lyx -e pdf2 > American_Psychological_Association_%28APA%29,_v._7.22.lyx > > > > I get the following errors when exporting from the GUI: > > > > This is BibTeX, Version 0.99d (TeX Live 2020) > > Capacity: max_strings=20, hash_size=20, hash_prime=170003 > > The top-level auxiliary file: > American_Psychological_Association__28APA_29,_v._7.22.aux > > I found no \citation commands---while reading file > American_Psychological_Association__28APA_29,_v._7.22.aux > > I found no \bibdata command---while reading file > American_Psychological_Association__28APA_29,_v._7.22.aux > > I found no \bibstyle command---while reading file > American_Psychological_Association__28APA_29,_v._7.22.aux > > I'm guessing this happens because we export ERT/preamble stuff in the > backwards conversion, and in the forwards conversion we > (understandably) > do not take into account the ERT. Unless anyone wants to take a > closer > look, I plan to invert the test (i.e., mark in the ctests that we > expect > this test to fail), especially since it is regarding 2.2.x and not > even > 2.3.x. In this particular case, it is because this file uses Biblatex, so it is expected that BibTeX fails on it. And the reversion to ERT is the reason why Biblatex is not detected. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test Email
On 8/26/20 7:27 PM, Doug Martin wrote: > I just got subscribed to this list, thanks to the kind help of Riki Heck. > And I just wanted to check that indeed I can send an email to the list. And it seems to have come through. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Test Email
I just got subscribed to this list, thanks to the kind help of Riki Heck. And I just wanted to check that indeed I can send an email to the list. Doug -- R. Douglas Martin Professor Emeritus in Applied Mathematics and Statistics Founder and Former Director of MS-CFRM Program depts.washington.edu/compfin/ University of Washington -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx roundtrip test failing with BibTeX errors
On Wed, Aug 26, 2020 at 12:14:49PM +0100, José Abílio Matos wrote: > On Tuesday, 25 August 2020 17.40.51 WEST Scott Kostyshak wrote: > > I'm guessing this happens because we export ERT/preamble stuff in the > > backwards conversion, and in the forwards conversion we (understandably) > > do not take into account the ERT. Unless anyone wants to take a closer > > look, I plan to invert the test (i.e., mark in the ctests that we expect > > this test to fail), especially since it is regarding 2.2.x and not even > > 2.3.x. > > > > Scott > > You are right, as soon as ERT enters the backport the roundtrip test becomes > doomed. Yes, it can work but and yes sometimes we could improve the ERT > (probably in convoluted ways) to simplify a later forward conversion but it > is > not worth the cost-benefit of such work. > > IMHO, of course. :-) Thanks for taking a look, José. That sounds good. I added a sublabel for the inverted ctests (at c44cfec3) to track cases that fall under this category. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx roundtrip test failing with BibTeX errors
On Tuesday, 25 August 2020 17.40.51 WEST Scott Kostyshak wrote: > I'm guessing this happens because we export ERT/preamble stuff in the > backwards conversion, and in the forwards conversion we (understandably) > do not take into account the ERT. Unless anyone wants to take a closer > look, I plan to invert the test (i.e., mark in the ctests that we expect > this test to fail), especially since it is regarding 2.2.x and not even > 2.3.x. > > Scott You are right, as soon as ERT enters the backport the roundtrip test becomes doomed. Yes, it can work but and yes sometimes we could improve the ERT (probably in convoluted ways) to simplify a later forward conversion but it is not worth the cost-benefit of such work. IMHO, of course. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: lyx2lyx roundtrip test failing with BibTeX errors
On Mon, Aug 24, 2020 at 01:02:36AM -0400, Scott Kostyshak wrote: > The following test fails for me: > > > export/templates/Articles/American_Psychological_Association_%28APA%29,_v._7_lyx22 > (Failed) > > To reproduce: > > lyx -e lyx22x American_Psychological_Association_%28APA%29,_v._7.lyx && lyx > -e pdf2 American_Psychological_Association_%28APA%29,_v._7.22.lyx > > I get the following errors when exporting from the GUI: > > This is BibTeX, Version 0.99d (TeX Live 2020) > Capacity: max_strings=20, hash_size=20, hash_prime=170003 > The top-level auxiliary file: > American_Psychological_Association__28APA_29,_v._7.22.aux > I found no \citation commands---while reading file > American_Psychological_Association__28APA_29,_v._7.22.aux > I found no \bibdata command---while reading file > American_Psychological_Association__28APA_29,_v._7.22.aux > I found no \bibstyle command---while reading file > American_Psychological_Association__28APA_29,_v._7.22.aux I'm guessing this happens because we export ERT/preamble stuff in the backwards conversion, and in the forwards conversion we (understandably) do not take into account the ERT. Unless anyone wants to take a closer look, I plan to invert the test (i.e., mark in the ctests that we expect this test to fail), especially since it is regarding 2.2.x and not even 2.3.x. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
On Mon, Aug 24, 2020 at 01:44:33AM +0200, Kornel Benko wrote:
> Am Sun, 23 Aug 2020 14:36:52 -0400
> schrieb Scott Kostyshak :
>
> > On Sun, Aug 23, 2020 at 01:35:54PM +0200, Kornel Benko wrote:
> > > Am Sun, 23 Aug 2020 11:53:25 +0200
> > > schrieb Kornel Benko :
> > >
> > > > Am Sun, 23 Aug 2020 10:09:24 +0200
> > > > schrieb Jürgen Spitzmüller :
> > > >
> > > > > Am Samstag, den 22.08.2020, 14:34 +0200 schrieb Kornel Benko:
> > > > > > OK. In the mean time, (I don't expect a solution in the near future)
> > > > > > we should use your patch. Just my 2c.
> > > > >
> > > > > I went for alphabetic ordering now.
> > > > >
> > > > > Jürgen
> > > >
> > > > Thanks, works nice for supported-languages.*. Retesting all takes a
> > > > while ...
> > > >
> > > > Kornel
> > >
> > > Looks good.
> >
> > Looks good here also (I only tested supported-languages). Thanks for the
> > fix.
> >
> > I guess it is still an open puzzle of how it was possible to get
> > different output from the same .lyx file in some situations? Jürgen
> > fixed this particular issue which caused a conflict, but is it possible
> > there could be other situations where we produce different LaTeX output
> > from the same .lyx file?
> >
> > Scott
>
> The languages are stored in a set, so the retrieve sequence is not determined.
>
> src/LaTeXFeatures.h:
> typedef std::set LanguageList;
> LanguageList UsedLanguages_;
> ...
> src/LaTeXFeatures.cpp:
> for (auto const & lang : UsedLanguages_) {
>...
> }
>
> Probably depends on the compiler ...
I see, so it does seem to be specific to that case. That's good to know.
Thanks for figuring that out.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
lyx2lyx roundtrip test failing with BibTeX errors
The following test fails for me: export/templates/Articles/American_Psychological_Association_%28APA%29,_v._7_lyx22 (Failed) To reproduce: lyx -e lyx22x American_Psychological_Association_%28APA%29,_v._7.lyx && lyx -e pdf2 American_Psychological_Association_%28APA%29,_v._7.22.lyx I get the following errors when exporting from the GUI: This is BibTeX, Version 0.99d (TeX Live 2020) Capacity: max_strings=20, hash_size=20, hash_prime=170003 The top-level auxiliary file: American_Psychological_Association__28APA_29,_v._7.22.aux I found no \citation commands---while reading file American_Psychological_Association__28APA_29,_v._7.22.aux I found no \bibdata command---while reading file American_Psychological_Association__28APA_29,_v._7.22.aux I found no \bibstyle command---while reading file American_Psychological_Association__28APA_29,_v._7.22.aux Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Sun, 23 Aug 2020 14:36:52 -0400
schrieb Scott Kostyshak :
> On Sun, Aug 23, 2020 at 01:35:54PM +0200, Kornel Benko wrote:
> > Am Sun, 23 Aug 2020 11:53:25 +0200
> > schrieb Kornel Benko :
> >
> > > Am Sun, 23 Aug 2020 10:09:24 +0200
> > > schrieb Jürgen Spitzmüller :
> > >
> > > > Am Samstag, den 22.08.2020, 14:34 +0200 schrieb Kornel Benko:
> > > > > OK. In the mean time, (I don't expect a solution in the near future)
> > > > > we should use your patch. Just my 2c.
> > > >
> > > > I went for alphabetic ordering now.
> > > >
> > > > Jürgen
> > >
> > > Thanks, works nice for supported-languages.*. Retesting all takes a while
> > > ...
> > >
> > > Kornel
> >
> > Looks good.
>
> Looks good here also (I only tested supported-languages). Thanks for the
> fix.
>
> I guess it is still an open puzzle of how it was possible to get
> different output from the same .lyx file in some situations? Jürgen
> fixed this particular issue which caused a conflict, but is it possible
> there could be other situations where we produce different LaTeX output
> from the same .lyx file?
>
> Scott
The languages are stored in a set, so the retrieve sequence is not determined.
src/LaTeXFeatures.h:
typedef std::set LanguageList;
LanguageList UsedLanguages_;
...
src/LaTeXFeatures.cpp:
for (auto const & lang : UsedLanguages_) {
...
}
Probably depends on the compiler ...
Kornel
pgpaXMapPK916.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
On Sun, Aug 23, 2020 at 01:35:54PM +0200, Kornel Benko wrote: > Am Sun, 23 Aug 2020 11:53:25 +0200 > schrieb Kornel Benko : > > > Am Sun, 23 Aug 2020 10:09:24 +0200 > > schrieb Jürgen Spitzmüller : > > > > > Am Samstag, den 22.08.2020, 14:34 +0200 schrieb Kornel Benko: > > > > OK. In the mean time, (I don't expect a solution in the near future) > > > > we should use your patch. Just my 2c. > > > > > > I went for alphabetic ordering now. > > > > > > Jürgen > > > > Thanks, works nice for supported-languages.*. Retesting all takes a while > > ... > > > > Kornel > > Looks good. Looks good here also (I only tested supported-languages). Thanks for the fix. I guess it is still an open puzzle of how it was possible to get different output from the same .lyx file in some situations? Jürgen fixed this particular issue which caused a conflict, but is it possible there could be other situations where we produce different LaTeX output from the same .lyx file? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Sun, 23 Aug 2020 11:53:25 +0200 schrieb Kornel Benko : > Am Sun, 23 Aug 2020 10:09:24 +0200 > schrieb Jürgen Spitzmüller : > > > Am Samstag, den 22.08.2020, 14:34 +0200 schrieb Kornel Benko: > > > OK. In the mean time, (I don't expect a solution in the near future) > > > we should use your patch. Just my 2c. > > > > I went for alphabetic ordering now. > > > > Jürgen > > Thanks, works nice for supported-languages.*. Retesting all takes a while ... > > Kornel Looks good. Kornel pgpYPutspI3O3.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Sun, 23 Aug 2020 10:09:24 +0200 schrieb Jürgen Spitzmüller : > Am Samstag, den 22.08.2020, 14:34 +0200 schrieb Kornel Benko: > > OK. In the mean time, (I don't expect a solution in the near future) > > we should use your patch. Just my 2c. > > I went for alphabetic ordering now. > > Jürgen Thanks, works nice for supported-languages.*. Retesting all takes a while ... Kornel pgp5XQZzhz6wO.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Samstag, den 22.08.2020, 14:34 +0200 schrieb Kornel Benko: > OK. In the mean time, (I don't expect a solution in the near future) > we should use your patch. Just my 2c. I went for alphabetic ordering now. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Sat, 22 Aug 2020 14:25:53 +0200 schrieb Jürgen Spitzmüller : > Am Samstag, den 22.08.2020, 14:04 +0200 schrieb Kornel Benko: > > The other thing is the unspecified sequence of documentclass options. > > We have to expect different outcome depending on the phase of moon. > > The order really should not matter. And as you demonstrated, the > sequence also differs for preamble definitions. > > > Maybe, a routine returning always the same sequence is not a bad > > idea. > > Something like a language priority comes in mind. > > (In our case arabi and farsi have the priority 1, hebrew 2 and the > > rest 0) > > This looks like overkill just to solve a bug in one language definition > file. > > Of course the easiest way to have a stable order would be to just order > them alphabetically (which would incidentally even solve the hebrew > problem). > > However, this all does not help if one of the conflicting languages is > the main language (which has to come last in any event). > > Jürgen OK. In the mean time, (I don't expect a solution in the near future) we should use your patch. Just my 2c. Kornel pgpnRIp5PV9j3.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Samstag, den 22.08.2020, 14:04 +0200 schrieb Kornel Benko: > The other thing is the unspecified sequence of documentclass options. > We have to expect different outcome depending on the phase of moon. The order really should not matter. And as you demonstrated, the sequence also differs for preamble definitions. > Maybe, a routine returning always the same sequence is not a bad > idea. > Something like a language priority comes in mind. > (In our case arabi and farsi have the priority 1, hebrew 2 and the > rest 0) This looks like overkill just to solve a bug in one language definition file. Of course the easiest way to have a stable order would be to just order them alphabetically (which would incidentally even solve the hebrew problem). However, this all does not help if one of the conflicting languages is the main language (which has to come last in any event). Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Sat, 22 Aug 2020 13:39:28 +0200 schrieb Jürgen Spitzmüller : > Am Samstag, den 22.08.2020, 11:39 +0200 schrieb Kornel Benko: > > Looks good. The endless loop is gone :) > > Thanks. I first try to get it fixed upstream. If this doesn't work, we > can still commit this ugly workaround. > > Jürgen The other thing is the unspecified sequence of documentclass options. We have to expect different outcome depending on the phase of moon. Maybe, a routine returning always the same sequence is not a bad idea. Something like a language priority comes in mind. (In our case arabi and farsi have the priority 1, hebrew 2 and the rest 0) Kornel pgp8wvrC7tAnP.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Samstag, den 22.08.2020, 11:39 +0200 schrieb Kornel Benko: > Looks good. The endless loop is gone :) Thanks. I first try to get it fixed upstream. If this doesn't work, we can still commit this ugly workaround. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Sat, 22 Aug 2020 11:18:58 +0200 schrieb Jürgen Spitzmüller : > Am Samstag, den 22.08.2020, 10:28 +0200 schrieb Jürgen Spitzmüller: > > What we can do is to assure that hebrew is always output after arabic > > and farsi. But this of course only works if Arabic or Farsi are not > > the main language. > > This would be something like the attached. Kornel, Scott, does this > solve your problem? > > Jürgen Looks good. The endless loop is gone :) Kornel pgpwybezSo53Q.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Samstag, den 22.08.2020, 10:28 +0200 schrieb Jürgen Spitzmüller:
> What we can do is to assure that hebrew is always output after arabic
> and farsi. But this of course only works if Arabic or Farsi are not
> the main language.
This would be something like the attached. Kornel, Scott, does this
solve your problem?
Jürgen
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 4f3b87886c..b17cb7e8a4 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -992,19 +992,41 @@ string LaTeXFeatures::getBabelLanguages() const
{
ostringstream langs;
- bool first = true;
+ // hebrew needs to be loaded after arabi (arabic, farsi)
+ bool has_arabi = false;
LanguageList::const_iterator const begin = UsedLanguages_.begin();
+ for (LanguageList::const_iterator cit = begin;
+ cit != UsedLanguages_.end();
+ ++cit) {
+ if ((*cit)->babel() == "farsi" || (*cit)->babel() == "arabic") {
+ has_arabi = true;
+ break;
+ }
+ }
+ bool first = true;
+ bool hebrew = false;
for (LanguageList::const_iterator cit = begin;
cit != UsedLanguages_.end();
++cit) {
if ((*cit)->babel().empty())
continue;
+ if ((*cit)->babel() == "hebrew" && has_arabi) {
+ // this needs to be appended last
+ hebrew = true;
+ continue;
+ }
if (!first)
langs << ',';
else
first = false;
langs << (*cit)->babel();
}
+ if (hebrew) {
+ // append hebrew if needed
+ if (!first)
+ langs << ',';
+ langs << "hebrew";
+ }
return langs.str();
}
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Samstag, den 22.08.2020, 10:28 +0200 schrieb Jürgen Spitzmüller: > My guess is that arabicore.sty (use by Farsi and Arabic) and > lhbabel.def (used by Hebrew) redefine \everypar in incompatible ways. > > What we can do is to assure that hebrew is always output after arabic > and farsi. But this of course only works if Arabic or Farsi are not > the > main language. > > I can try and file a report, but both Arabi and babel-hebrew don't > have > seen updates for a long time. I asked for advice at https://tex.stackexchange.com/questions/559603/ Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Freitag, den 21.08.2020, 19:06 +0200 schrieb Kornel Benko:
> This version does hang. Switch the commented documentclass, and now
> the compilation does not hang.
It boils down to the order of hebrew and farsi (or arabic):
\documentclass[
hebrew,% breaks
farsi,% or: arabic
% hebrew,% compiles
english]{article}
\usepackage[LAE,LFE,T1]{fontenc}
\usepackage[cp1255,utf8,latin9]{inputenc}
\usepackage{babel}
\begin{document}
Hello.
\end{document}
If Hebrew comes after farsi and arabic, it compiles, if it precedes, it
breaks with the following error (which is only ssen when compiling
manually):
! Argument of \o@everypar has an extra }.
\par
l.126\n@everypar\expandafter{\the\o@everypar}
My guess is that arabicore.sty (use by Farsi and Arabic) and
lhbabel.def (used by Hebrew) redefine \everypar in incompatible ways.
What we can do is to assure that hebrew is always output after arabic
and farsi. But this of course only works if Arabic or Farsi are not the
main language.
I can try and file a report, but both Arabi and babel-hebrew don't have
seen updates for a long time.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Freitag, den 21.08.2020, 13:33 -0400 schrieb Scott Kostyshak: > Thanks to you two for looking into this annoying problem. I don't > have > much time to contribute or test. > > The following ML thread is relevant. I'm not sure it contains any > additional information but I put it nonetheless at least as > confirmation > that I've seen the same thing with the language orderings: > > > https://www.mail-archive.com/search?l=mid&q=20200314202907.eherh6ajhtk7lpkx%40tallinn Thanks for pointing this out. I had a vague memory we already had this problem. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
On Fri, Aug 21, 2020 at 07:51:43PM +0200, Kornel Benko wrote: > Am Fri, 21 Aug 2020 13:33:58 -0400 > schrieb Scott Kostyshak : > > > > > Thanks. Could you send also the other file, for comparison? > > > > > > It is too edited (the documentclass line) > > > > Thanks to you two for looking into this annoying problem. I don't have > > much time to contribute or test. > > > > The following ML thread is relevant. I'm not sure it contains any > > additional information but I put it nonetheless at least as confirmation > > that I've seen the same thing with the language orderings: > > > > > > https://www.mail-archive.com/search?l=mid&q=20200314202907.eherh6ajhtk7lpkx%40tallinn > > > > Scott > > It is exactly the same thing, with different document. > 5 months old mail, too much for my memory as it seems. Normally mine also, but this issue was frustrating enough that I remembered. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 13:33:58 -0400 schrieb Scott Kostyshak : > > > Thanks. Could you send also the other file, for comparison? > > > > It is too edited (the documentclass line) > > Thanks to you two for looking into this annoying problem. I don't have > much time to contribute or test. > > The following ML thread is relevant. I'm not sure it contains any > additional information but I put it nonetheless at least as confirmation > that I've seen the same thing with the language orderings: > > > https://www.mail-archive.com/search?l=mid&q=20200314202907.eherh6ajhtk7lpkx%40tallinn > > Scott It is exactly the same thing, with different document. 5 months old mail, too much for my memory as it seems. Kornel pgp4PYR0cWoNV.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
On Fri, Aug 21, 2020 at 07:21:13PM +0200, Kornel Benko wrote: > Am Fri, 21 Aug 2020 19:13:32 +0200 > schrieb Jürgen Spitzmüller : > > > Am Freitag, den 21.08.2020, 19:06 +0200 schrieb Kornel Benko: > > > > Are these the only differences in the tex file? > > > > > > No, but others are only the sequence of defining some latex commands. > > > > But this should also not differ. > > > > > > > > > And does the first tex file also hang if you run pdflatex directly? > > > > > > Yes. > > > > > > > If not, could you send the problematic tex file? > > > > > > Attached. > > > > Thanks. Could you send also the other file, for comparison? > > It is too edited (the documentclass line) Thanks to you two for looking into this annoying problem. I don't have much time to contribute or test. The following ML thread is relevant. I'm not sure it contains any additional information but I put it nonetheless at least as confirmation that I've seen the same thing with the language orderings: https://www.mail-archive.com/search?l=mid&q=20200314202907.eherh6ajhtk7lpkx%40tallinn Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 19:13:32 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, den 21.08.2020, 19:06 +0200 schrieb Kornel Benko:
> > > Are these the only differences in the tex file?
> >
> > No, but others are only the sequence of defining some latex commands.
>
> But this should also not differ.
>
> >
> > > And does the first tex file also hang if you run pdflatex directly?
> >
> > Yes.
> >
> > > If not, could you send the problematic tex file?
> >
> > Attached.
>
> Thanks. Could you send also the other file, for comparison?
It is too edited (the documentclass line)
> Jürgen
Kornel
\batchmode
\makeatletter
\def\input@path{{/BUILD/BUILDMint18/BuildLyxGitQt5.9.5local-gcc8.4.0/autotests/out-home/AbC_EcEImp/export/latex/languages/}}
\makeatother
%\documentclass[paper=a4,bahasam,basque,breton,austrian,afrikaans,belarusian,dutch,bulgarian,hebrew,icelandic,interlingua,irish,albanian,bosnian,croatian,acadian,azerbaijani,catalan,czech,danish,bahasa,piedmontese,polish,portuges,romanian,romansh,russian,samin,scottish,serbianc,serbian,slovak,slovene,spanish,naustrian,brazil,swedish,turkish,turkmen,ukrainian,uppersorbian,vietnamese,welsh,ngerman,nswissgerman,greek,magyar,mongolian,norsk,nynorsk,kurmanji,latin,latvian,lithuanian,lowersorbian,esperanto,estonian,farsi,finnish,french,friulan,german,arabic,english]{scrartcl}
\documentclass[paper=a4,basque,brazil,breton,bosnian,austrian,icelandic,naustrian,romansh,turkmen,czech,kurmanji,azerbaijani,welsh,polish,slovak,russian,bahasa,lowersorbian,danish,swedish,nynorsk,latvian,turkish,albanian,slovene,vietnamese,scottish,greek,magyar,ngerman,french,piedmontese,esperanto,arabic,interlingua,portuges,croatian,samin,afrikaans,farsi,bulgarian,ukrainian,friulan,dutch,uppersorbian,bahasam,german,spanish,irish,nswissgerman,lithuanian,catalan,serbian,hebrew,estonian,mongolian,norsk,latin,finnish,serbianc,romanian,acadian,belarusian,english]{scrartcl}
\usepackage{libertineRoman}
\usepackage{biolinum}
\usepackage[LFE,LAE,L7x,LGR,T5,T2A,HE8,T1]{fontenc}
\usepackage{textcomp}
\usepackage[cp1251,cp1255,cp1256,iso-8859-7,koi8-r,koi8-u,latin10,latin2,latin3,latin4,latin5,latin7,utf8,latin9]{inputenc}
\usepackage{color}
\makeatletter
\IfFileExists{he8david.fd}{%
\providecommand{\HeblatexEncoding}{HE8}
\providecommand{\HeblatexEncodingFile}{he8enc}%
}{}
\providecommand{\l@chapter}{\relax}
\makeatother
\usepackage{babel}
\makeatletter
\addto\extrasbasque{\bbl@deactivate{~}}
% fix albanian: restore \th as LATIN LETTER THORN
\@ifl@aded{def}{t1enc}{\DeclareTextSymbol{\th}{T1}{254}}{}
\DeclareTextCommand{\textschwa}{T1}{\cyrschwa\bbl@allowhyphens}
\DeclareTextCommand{\textSchwa}{T1}{\CYRSCHWA\bbl@allowhyphens}
\addto\shorthandsspanish{\spanishdeactivate{~<>}}
% restore \coyright definition corrupted by l7xenc.def
\DeclareRobustCommand{\copyright}{%
\ifmmode{\nfss@text{\textcopyright}}\else\textcopyright\fi}
\addto\noextraslithuanian{\latintext}
\addto\extrasestonian{\bbl@deactivate{~}}
\DeclareTextSymbol{\guillemotright}{LFE}{62}
\DeclareTextSymbol{\guillemotleft}{LFE}{60}
% arabic + hyperref redefines \noboundary as local textcommand
\let\orig@noboundary\noboundary
\DeclareTextCommandDefault{\noboundary}{\orig@noboundary}
% work around too simple test for article-like classes in arabicore.sty
\ifdefined\chapter\else
\def\thesection{\protect\if@rl\protect\I{\number\c@section}%
\protect\else\protect\textLR{\number\c@section}%
\protect\fi}
\def\thesubsection{\protect\if@rl\protect\I{\number\c@subsection.\number\c@section}%
\protect\else\protect\textLR{\number\c@section.\number\c@subsection}%
\protect\fi}%
\def\thetable{\protect\if@rl\protect\I{\number\c@table}%
\protect\else\protect\textLR{\number\c@table}%
\protect\fi}%
\def\thefigure{\protect\if@rl\protect\I{\number\c@figure}%
\protect\else\protect\textLR{\number\c@figure}%
\protect\fi}%
\fi
\makeatother
\usepackage{enumitem}
\usepackage{setspace}
\usepackage[pdftex,unicode=true,pdfusetitle,
bookmarks=false,
breaklinks=false,pdfborder={0 0 0},pdfborderstyle={},backref=section,colorlinks=true]
{hyperref}
\makeatletter
%% LyX specific LaTeX commands.
\pdfpageheight\paperheight
\pdfpagewidth\paperwidth
%% custom text accent \LyxTextAccent[]{}{}
\newcommand*{\LyxTextAccent}[3][0ex]{%
\hmode@bgroup\ooalign{\null#3\crcr\hidewidth
\raise#1\hbox{#2}\hidewidth}\egroup}
%% select a font size smaller than the current font size:
\newcommand{\LyxAccentSize}[1][\sf@size]{%
\check@mathfonts\fontsize#1\z@\math@fontsfalse\selectfont
}
\ProvideTextCommandDefault{\textcommabelow}[1]{%%
\LyxTextAccent[-.31ex]{\LyxAccentSize,}{#1}}
%% letter schwa missing in Latin fonts, use Cyrillic schwa
\DeclareTextSymbolDefault{\CYRSCHWA}{T2A}
\DeclareTextSymbolDefault{\cyrschwa}{T2A}
\ProvideTextCommandDefault{\textSchwa}{\
Re: Test entering an endless loop in latex processing
Am Freitag, den 21.08.2020, 19:06 +0200 schrieb Kornel Benko: > > Are these the only differences in the tex file? > > No, but others are only the sequence of defining some latex commands. But this should also not differ. > > > And does the first tex file also hang if you run pdflatex directly? > > Yes. > > > If not, could you send the problematic tex file? > > Attached. Thanks. Could you send also the other file, for comparison? Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 18:50:37 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, den 21.08.2020, 18:18 +0200 schrieb Kornel Benko:
> > $ egrep cache Testing/.lyx/preferences
> > \converter_cache_maxage 15552000
> > \use_converter_cache false
> >
> > But I suspect now differences in the used tex-files.
> > The main difference (as I see it) is the definition of document class
> >
> > 1.) (hang)
> > \documentclass[paper=a4,bahasam,basque,breton,austrian,afrikaans,bela
> > rusian,dutch,bulgarian,hebrew,icelandic,interlingua,irish,albanian,bo
> > snian,croatian,acadian,azerbaijani,catalan,czech,danish,bahasa,piedmo
> > ntese,polish,portuges,romanian,romansh,russian,samin,scottish,serbian
> > c,serbian,slovak,slovene,spanish,naustrian,brazil,swedish,turkish,tur
> > kmen,ukrainian,uppersorbian,vietnamese,welsh,ngerman,nswissgerman,gre
> > ek,magyar,mongolian,norsk,nynorsk,kurmanji,latin,latvian,lithuanian,l
> > owersorbian,esperanto,estonian,farsi,finnish,french,friulan,german,ar
> > abic,english]{scrartcl}
> > 2.) (ok)
> > \documentclass[paper=a4,basque,brazil,breton,bosnian,austrian,iceland
> > ic,naustrian,romansh,turkmen,czech,kurmanji,azerbaijani,welsh,polish,
> > slovak,russian,bahasa,lowersorbian,danish,swedish,nynorsk,latvian,tur
> > kish,albanian,slovene,vietnamese,scottish,greek,magyar,ngerman,french
> > ,piedmontese,esperanto,arabic,interlingua,portuges,croatian,samin,afr
> > ikaans,farsi,bulgarian,ukrainian,friulan,dutch,uppersorbian,bahasam,g
> > erman,spanish,irish,nswissgerman,lithuanian,catalan,serbian,hebrew,es
> > tonian,mongolian,norsk,latin,finnish,serbianc,romanian,acadian,belaru
> > sian,english]{scrartcl}
>
> Are these the only differences in the tex file?
No, but others are only the sequence of defining some latex commands.
> And does the first tex file also hang if you run pdflatex directly?
Yes.
> If not, could you send the problematic tex file?
Attached.
This version does hang. Switch the commented documentclass, and now the
compilation does
not hang.
The included tex-file (not sent) is not important for this case.
> > Questions:
> > Why are the two not in the same order?
>
> No idea. IIRC languages are tracked by LyX in order of appearance.
>
> > Is the order important in any way?
>
> Possible. Maybe some conflicts in babel ldf loading order.
>
> Jürgen
>
> > Apparently it is, because the compilation now works.
Kornel
\batchmode
\makeatletter
\def\input@path{{/usr/src/lyx/lyx-git/autotests/export/latex/languages/}}
\makeatother
%\documentclass[paper=a4,basque,brazil,breton,bosnian,austrian,icelandic,naustrian,romansh,turkmen,czech,kurmanji,azerbaijani,welsh,polish,slovak,russian,bahasa,lowersorbian,danish,swedish,nynorsk,latvian,turkish,albanian,slovene,vietnamese,scottish,greek,magyar,ngerman,french,piedmontese,esperanto,arabic,interlingua,portuges,croatian,samin,afrikaans,farsi,bulgarian,ukrainian,friulan,dutch,uppersorbian,bahasam,german,spanish,irish,nswissgerman,lithuanian,catalan,serbian,hebrew,estonian,mongolian,norsk,latin,finnish,serbianc,romanian,acadian,belarusian,english]{scrartcl}
\documentclass[paper=a4,bahasam,basque,breton,austrian,afrikaans,belarusian,dutch,bulgarian,hebrew,icelandic,interlingua,irish,albanian,bosnian,croatian,acadian,azerbaijani,catalan,czech,danish,bahasa,piedmontese,polish,portuges,romanian,romansh,russian,samin,scottish,serbianc,serbian,slovak,slovene,spanish,naustrian,brazil,swedish,turkish,turkmen,ukrainian,uppersorbian,vietnamese,welsh,ngerman,nswissgerman,greek,magyar,mongolian,norsk,nynorsk,kurmanji,latin,latvian,lithuanian,lowersorbian,esperanto,estonian,farsi,finnish,french,friulan,german,arabic,english]{scrartcl}
\usepackage{libertineRoman}
\usepackage{biolinum}
\usepackage[L7x,LFE,LAE,LGR,T5,T2A,HE8,T1]{fontenc}
\usepackage{textcomp}
\usepackage[cp1251,cp1255,cp1256,iso-8859-7,koi8-r,koi8-u,latin10,latin2,latin3,latin4,latin5,latin7,utf8,latin9]{inputenc}
\usepackage{color}
\makeatletter
\IfFileExists{he8david.fd}{%
\providecommand{\HeblatexEncoding}{HE8}
\providecommand{\HeblatexEncodingFile}{he8enc}%
}{}
\providecommand{\l@chapter}{\relax}
\makeatother
\usepackage{babel}
\makeatletter
\addto\extrasbasque{\bbl@deactivate{~}}
\DeclareTextCommand{\textschwa}{T1}{\cyrschwa\bbl@allowhyphens}
\DeclareTextCommand{\textSchwa}{T1}{\CYRSCHWA\bbl@allowhyphens}
% fix albanian: restore \th as LATIN LETTER THORN
\@ifl@aded{def}{t1enc}{\DeclareTextSymbol{\th}{T1}{254}}{}
% arabic + hyperref redefines \noboundary as local textcommand
\let\orig@noboundary\noboundary
\DeclareTextCommandDefault{\noboundary}{\orig@noboundary}
% work around too simple test for article-like classes in arabicore.sty
\ifdefined\chapter\else
\def\thesection{\protect\if@rl\protect\I{\number\c@se
Re: Test entering an endless loop in latex processing
Am Freitag, den 21.08.2020, 18:18 +0200 schrieb Kornel Benko:
> $ egrep cache Testing/.lyx/preferences
> \converter_cache_maxage 15552000
> \use_converter_cache false
>
> But I suspect now differences in the used tex-files.
> The main difference (as I see it) is the definition of document class
>
> 1.) (hang)
> \documentclass[paper=a4,bahasam,basque,breton,austrian,afrikaans,bela
> rusian,dutch,bulgarian,hebrew,icelandic,interlingua,irish,albanian,bo
> snian,croatian,acadian,azerbaijani,catalan,czech,danish,bahasa,piedmo
> ntese,polish,portuges,romanian,romansh,russian,samin,scottish,serbian
> c,serbian,slovak,slovene,spanish,naustrian,brazil,swedish,turkish,tur
> kmen,ukrainian,uppersorbian,vietnamese,welsh,ngerman,nswissgerman,gre
> ek,magyar,mongolian,norsk,nynorsk,kurmanji,latin,latvian,lithuanian,l
> owersorbian,esperanto,estonian,farsi,finnish,french,friulan,german,ar
> abic,english]{scrartcl}
> 2.) (ok)
> \documentclass[paper=a4,basque,brazil,breton,bosnian,austrian,iceland
> ic,naustrian,romansh,turkmen,czech,kurmanji,azerbaijani,welsh,polish,
> slovak,russian,bahasa,lowersorbian,danish,swedish,nynorsk,latvian,tur
> kish,albanian,slovene,vietnamese,scottish,greek,magyar,ngerman,french
> ,piedmontese,esperanto,arabic,interlingua,portuges,croatian,samin,afr
> ikaans,farsi,bulgarian,ukrainian,friulan,dutch,uppersorbian,bahasam,g
> erman,spanish,irish,nswissgerman,lithuanian,catalan,serbian,hebrew,es
> tonian,mongolian,norsk,latin,finnish,serbianc,romanian,acadian,belaru
> sian,english]{scrartcl}
Are these the only differences in the tex file?
And does the first tex file also hang if you run pdflatex directly?
If not, could you send the problematic tex file?
> Questions:
> Why are the two not in the same order?
No idea. IIRC languages are tracked by LyX in order of appearance.
> Is the order important in any way?
Possible. Maybe some conflicts in babel ldf loading order.
Jürgen
> Apparently it is, because the compilation now works.
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 17:48:47 +0200
schrieb Jürgen Spitzmüller :
> Kornel Benko schrieb am Fr., 21. Aug. 2020, 17:13:
> > > Sure?
> >
> > Sure. The execution time of pdflatex is constantly increasing.
>
> I meant: sure cache is disabled?
>
> > Mark, that this is only a single export (no other lyx instance is
> > involved)
>
> Still there might be different threats trying to access it
>
> > and
> > I have the problem even if the cache is disabled (that is no read or
> > write to cache)
>
> If this is true my theory is wrong.
$ egrep cache Testing/.lyx/preferences
\converter_cache_maxage 15552000
\use_converter_cache false
But I suspect now differences in the used tex-files.
The main difference (as I see it) is the definition of document class
1.) (hang)
\documentclass[paper=a4,bahasam,basque,breton,austrian,afrikaans,belarusian,dutch,bulgarian,hebrew,icelandic,interlingua,irish,albanian,bosnian,croatian,acadian,azerbaijani,catalan,czech,danish,bahasa,piedmontese,polish,portuges,romanian,romansh,russian,samin,scottish,serbianc,serbian,slovak,slovene,spanish,naustrian,brazil,swedish,turkish,turkmen,ukrainian,uppersorbian,vietnamese,welsh,ngerman,nswissgerman,greek,magyar,mongolian,norsk,nynorsk,kurmanji,latin,latvian,lithuanian,lowersorbian,esperanto,estonian,farsi,finnish,french,friulan,german,arabic,english]{scrartcl}
2.) (ok)
\documentclass[paper=a4,basque,brazil,breton,bosnian,austrian,icelandic,naustrian,romansh,turkmen,czech,kurmanji,azerbaijani,welsh,polish,slovak,russian,bahasa,lowersorbian,danish,swedish,nynorsk,latvian,turkish,albanian,slovene,vietnamese,scottish,greek,magyar,ngerman,french,piedmontese,esperanto,arabic,interlingua,portuges,croatian,samin,afrikaans,farsi,bulgarian,ukrainian,friulan,dutch,uppersorbian,bahasam,german,spanish,irish,nswissgerman,lithuanian,catalan,serbian,hebrew,estonian,mongolian,norsk,latin,finnish,serbianc,romanian,acadian,belarusian,english]{scrartcl}
Questions:
Why are the two not in the same order?
Is the order important in any way?
Apparently it is, because the compilation now works.
> Jürgen
Kornel
pgp0vTHQctSSE.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Kornel Benko schrieb am Fr., 21. Aug. 2020, 17:13: > > Sure? > > Sure. The execution time of pdflatex is constantly increasing. I meant: sure cache is disabled? > Mark, that this is only a single export (no other lyx instance is > involved) Still there might be different threats trying to access it > and > I have the problem even if the cache is disabled (that is no read or > write to cache) If this is true my theory is wrong. Jürgen > Kornel signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 17:00:34 +0200 schrieb Jürgen Spitzmüller : > Am Fr., 21. Aug. 2020 um 16:41 Uhr schrieb Kornel Benko : > > > There is a problem. Endless loop in pdflatex if disabled cache > > > > Sure? Sure. The execution time of pdflatex is constantly increasing. What I can do is post the data from /tmp/lyx_tmpdir./lyx_tmpbuf0 In fact, calling pdflatex with the tex-file there causes the same effect. (hangs) > > > > > Also it strongly depends on the actual environment of LYX_DEBUG_LATEX (1 > > or 0) > > > > The test runs lyx with '-dbg latex' if LYX_DEBUG_LATEX=1 (no hang) > > else it runs with '-dbg info' (hang in pdflatex) > > > > Sorry, no help from dbg. > > > > I suspect some sort of race condition in the cache (when reading or writing > cache/index). Mark, that this is only a single export (no other lyx instance is involved) and I have the problem even if the cache is disabled (that is no read or write to cache) Kornel pgpinNgu5LiEw.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fr., 21. Aug. 2020 um 16:41 Uhr schrieb Kornel Benko : > There is a problem. Endless loop in pdflatex if disabled cache > Sure? > > Also it strongly depends on the actual environment of LYX_DEBUG_LATEX (1 > or 0) > > The test runs lyx with '-dbg latex' if LYX_DEBUG_LATEX=1 (no hang) > else it runs with '-dbg info' (hang in pdflatex) > > Sorry, no help from dbg. > I suspect some sort of race condition in the cache (when reading or writing cache/index). Jürgen > > Kornel > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 15:56:01 +0200 schrieb Jürgen Spitzmüller : > Am Fr., 21. Aug. 2020 um 14:19 Uhr schrieb Kornel Benko : > > > Correction. If I disable the conversion cache, I can export again. > > > > Also if you manually delete the contents of the cache? > > Do you get any helpful clue if you run the hanging lyx run with "-dbg any"? There is a problem. Endless loop in pdflatex if disabled cache Also it strongly depends on the actual environment of LYX_DEBUG_LATEX (1 or 0) The test runs lyx with '-dbg latex' if LYX_DEBUG_LATEX=1 (no hang) else it runs with '-dbg info' (hang in pdflatex) Sorry, no help from dbg. Kornel pgpFrUE0scBKV.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fr., 21. Aug. 2020 um 14:19 Uhr schrieb Kornel Benko : > Correction. If I disable the conversion cache, I can export again. > Also if you manually delete the contents of the cache? Do you get any helpful clue if you run the hanging lyx run with "-dbg any"? Jürgen > (The commands above were done with other userdir, where the cache was > enabled.) > > Kornel > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 13:58:46 +0200 schrieb Kornel Benko : > Am Fri, 21 Aug 2020 13:25:31 +0200 > schrieb Jürgen Spitzmüller : > > > Am Fr., 21. Aug. 2020 um 12:21 Uhr schrieb Kornel Benko : > > > > > > Does it help if you "Clear all session information" in Prefs > Look & > > > > Feel > Document Handling? > > > > > > ATM, it helped, yes. > > > > > > > Can you reproduce the hanging when trying to compile the file manually from > > the GUI? > > Yes, if trying to export first supported-languages.lyx (which also does not > end) > > > If so, does this warning dialog appear at all? > > No. > > > If not, did you (or maybe the test script) ever hit "Don't show this > > warning again" for the warning in question? > > Never. > > > Jürgen > > On subsequent runs it does not help to use > "Don't show this warning again" > the only difference is, that the dialogue now does not appear. > > To summarize, here the sequence of commands to provoke the hang > > 1.) $ lyx -E pdf2 x1.pdf > > /autotests/export/latex/languages/supported-languages_babel_auto-legacy.lyx > (works OK) > 2.) $ lyx -E pdf2 x.pdf > /autotests/export/latex/languages/supported-languages.lyx > 1a.) kill lyx, because it hangs > 3.) $ lyx -E pdf2 x2.pdf > > /autotests/export/latex/languages/supported-languages_babel_auto-legacy.lyx > 4.) Remove session info ... > 5.) $ lyx -E ... still hangs > > So, now it never exports. (Tried to remove session, session.cmake) > > Kornel Correction. If I disable the conversion cache, I can export again. (The commands above were done with other userdir, where the cache was enabled.) Kornel pgpKLSjxuFv1g.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Test entering an endless loop in latex processing
Am Fri, 21 Aug 2020 13:25:31 +0200 schrieb Jürgen Spitzmüller : > Am Fr., 21. Aug. 2020 um 12:21 Uhr schrieb Kornel Benko : > > > > Does it help if you "Clear all session information" in Prefs > Look & > > > Feel > Document Handling? > > > > ATM, it helped, yes. > > > > Can you reproduce the hanging when trying to compile the file manually from > the GUI? Yes, if trying to export first supported-languages.lyx (which also does not end) > If so, does this warning dialog appear at all? No. > If not, did you (or maybe the test script) ever hit "Don't show this > warning again" for the warning in question? Never. > Jürgen On subsequent runs it does not help to use "Don't show this warning again" the only difference is, that the dialogue now does not appear. To summarize, here the sequence of commands to provoke the hang 1.) $ lyx -E pdf2 x1.pdf /autotests/export/latex/languages/supported-languages_babel_auto-legacy.lyx (works OK) 2.) $ lyx -E pdf2 x.pdf /autotests/export/latex/languages/supported-languages.lyx 1a.) kill lyx, because it hangs 3.) $ lyx -E pdf2 x2.pdf /autotests/export/latex/languages/supported-languages_babel_auto-legacy.lyx 4.) Remove session info ... 5.) $ lyx -E ... still hangs So, now it never exports. (Tried to remove session, session.cmake) Kornel pgpWWPcVo31xV.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
