Re: [LyX/master] ctest update.
On Fri, Mar 01, 2019 at 05:02:47PM -, Guenter Milde wrote: > On 2019-03-01, Kornel Benko wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > Am Donnerstag, 28. Februar 2019 21:24:45 CET schrieb Scott Kostyshak > > : > >> On Mon, Feb 25, 2019 at 01:17:36AM +0100, Günter Milde wrote: > >> > commit 4de4263f93fdca326d6603e996c7e8ba35454593 > >> > Author: Günter Milde > >> > Date: Mon Feb 25 01:17:20 2019 +0100 > >> > > >> > ctest update. > >> > > >> > * set required non-TeX fonts in the documents > >> > * update comments for inverted tests > >> > * update some tags > > >> I think starting with this commit, the following test now fails for me: > > >> ctest -R "export/examples/uk/splash_pdf4_texF" > > >> I also have the following test failing (but I'm not sure if it's related > >> to this commit): > > >> ctest -R "export/doc/uk/Intro_pdf4_texF" > > >> Scott > > > I see the same, but I don't thing it was this commit. Using > > the original version of useSystemFonts.pl the errors still appear. > > Checking `ctest -R export.*/uk/.*pdf`: > > 100% tests passed, 0 tests failed out of 14 > > So we have either another TeXLive18 problem or one more instance of > "erratic" behaviour: > > With `ctest -R export.*/uk/.*pdf -N` I see > > Test #3398: UNRELIABLE.ERRATIC_export/doc/uk/Intro_pdf4_texF > > and in unreliableTests I see: > > # Missing Cyrillic LICR commands (on first run after changing from > tex-fonts) > # (leftover *.aux file?) > export/doc/uk/Intro_pdf4_texF > > Maybe there is also "erratic" behaviour for other Ukrainean > XeTeX-with-tex-fonts tests. > > Do the documents compile "per hand" > > a) after opening in LyX, setting non-tex-fonts and compiling > > b) after opening in LyX, compiling with pdflatex, setting non-tex-fonts >and compiling Isn't the test about TeX fonts? Should I still check the above? The test starts failing after this commit because the following line was removed from ignoreLatexErrorsTests: export/examples/uk/splash_pdf4_texF The test then appears to fail because of: LaTeX.cpp (719): Log line: Missing character: There is no б in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no е in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no р in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no е in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no з in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no н in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no я in font larm1200! LaTeX.cpp (719): Log line: Missing character: There is no р in font larm1200! Scott signature.asc Description: PGP signature
Re: File import error
On Fri, Mar 01, 2019 at 03:43:08PM -0500, Paul A. Rubin wrote: > On 3/1/19 12:46 AM, Scott Kostyshak wrote: > > On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote: > > > On 2/28/19 9:24 PM, Scott Kostyshak wrote: > > > > On Thu, Feb 28, 2019 at 05:03:45PM -0500, Paul A. Rubin wrote: > > > > > > > > > I don't see anything like this in the bug tracker. Any suggestions on > > > > > something I can test here? Should I file a bug report? > > > > As JMarc mentioned on the lyx-users thread, are there any differences in > > > > preferences? > > > > > > > > Scott > > > I can't find a switch for using native dialogs in the Tools > > > > Preferences... > > I don't think it is accessible from the GUI (but not sure of that > > claim). > > > > > dialog, and I can't find any reference to it in any file in either > > > /usr/share/lyx or ~/.lyx (including subdirectories). Any suggestions > > > where I > > > should look? > > You don't need to look here, but this is the commit that introduced it: > > > >af795b80 > > > > > Is this in 2.3.2? (FWIW, the version I have lists the build > > > date as 12/08/18.) > > Yes the setting does apply for 2.3.x > > > > You can just test with the following added to your preferences file: > > > >\use_native_filedialog false > > > > and also try with > > > >\use_native_filedialog true > > > > Any difference in behavior regarding this bug, between those two? > > > > By the way, is the bug 100% reproducible on the system that has it? Can > > you see *any* .tex files? Does it depend on the directory you're in? > > > > I just tested but can't reproduce. > > > > Scott > I have no idea if this makes a difference, but just in case it triggers a > thought: my desktop (where the issue never manifests) has Qt 4.8.7 and 5.5.1 > installed; my laptop (where the problem manifests if I do not override the > native dialog setting) has Qt 4.8.7 and 5.9.5. LyX uses 4.8.7 on both > machines (or so it claims), so I would not think the Qt 5 version would make > a difference ... but lacking a rational explanation for the difference in > behaviors, who knows? You could compare the output of "ldd" on the binaries. Maybe this will work: ldd "$(which lyx)" Not sure what else to look at. Do both use the same file system? I think you can figure this out with the following command: df -h > Also, is there any place where a Qt configuration file would be stored that > would explain why the native true/false thing has no impact on my desktop > but a big impact on my laptop? (All I know about Qt is the spelling.) There is such thing as Qt preferences but I don't have any experience with setting them. Scott signature.asc Description: PGP signature
Re: File import error
On 3/1/19 12:46 AM, Scott Kostyshak wrote: On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote: On 2/28/19 9:24 PM, Scott Kostyshak wrote: On Thu, Feb 28, 2019 at 05:03:45PM -0500, Paul A. Rubin wrote: I don't see anything like this in the bug tracker. Any suggestions on something I can test here? Should I file a bug report? As JMarc mentioned on the lyx-users thread, are there any differences in preferences? Scott I can't find a switch for using native dialogs in the Tools > Preferences... I don't think it is accessible from the GUI (but not sure of that claim). dialog, and I can't find any reference to it in any file in either /usr/share/lyx or ~/.lyx (including subdirectories). Any suggestions where I should look? You don't need to look here, but this is the commit that introduced it: af795b80 Is this in 2.3.2? (FWIW, the version I have lists the build date as 12/08/18.) Yes the setting does apply for 2.3.x You can just test with the following added to your preferences file: \use_native_filedialog false and also try with \use_native_filedialog true Any difference in behavior regarding this bug, between those two? By the way, is the bug 100% reproducible on the system that has it? Can you see *any* .tex files? Does it depend on the directory you're in? I just tested but can't reproduce. Scott I have no idea if this makes a difference, but just in case it triggers a thought: my desktop (where the issue never manifests) has Qt 4.8.7 and 5.5.1 installed; my laptop (where the problem manifests if I do not override the native dialog setting) has Qt 4.8.7 and 5.9.5. LyX uses 4.8.7 on both machines (or so it claims), so I would not think the Qt 5 version would make a difference ... but lacking a rational explanation for the difference in behaviors, who knows? Also, is there any place where a Qt configuration file would be stored that would explain why the native true/false thing has no impact on my desktop but a big impact on my laptop? (All I know about Qt is the spelling.) Paul
Re: File import error
On 3/1/19 3:30 PM, Andrew Parsloe wrote: On 2/03/2019 8:31 AM, Scott Kostyshak wrote: On Fri, Mar 01, 2019 at 01:45:48PM -0500, Paul A. Rubin wrote: On 3/1/19 12:46 AM, Scott Kostyshak wrote: On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote: Is this in 2.3.2? (FWIW, the version I have lists the build date as 12/08/18.) Yes the setting does apply for 2.3.x You can just test with the following added to your preferences file: \use_native_filedialog false and also try with \use_native_filedialog true Any difference in behavior regarding this bug, between those two? Yes and no. On my desktop (where the problem does not manifest), neither of those statements has any effect. Not only does the problem not occur, but the file dialog layout/appearance does not change with either. On my laptop (where the problem does manifest), the true setting matches what is currently happening (with no setting in preferences), while the false setting switches the dialog layout to match that of my desktop and /gets rid of the problem/ (.tex files appear as expected). That still leaves unanswered why it happens one place and not the other with the same version of LyX (as best I can tell). I searched both ~/.lyx and /usr/share/lyx (including subdirectories) on both laptop and desktop, and \use_native_filedialog does not appear anywhere. By the way, is the bug 100% reproducible on the system that has it? Yes. Can you see *any* .tex files? No. With the default filter (.tex), only subdirectories appear; no files do. Does it depend on the directory you're in? No. I just tested but can't reproduce. Interesting! So there seem to be two puzzles from what I understand: 1. Why is the default different on your systems. 2. Why can you only reproduce the bug on one system. I wondered if this issue might show on a windows 10 laptop. The true/false settings produce different dialogues (dialogs?) but the .tex files show in both. Andrew Different looking dialogs would make sense. It would be interesting to know how the file filtering on Windows differs from the file filtering on Mint and Ubuntu. Thanks. It's one more puzzle piece. Paul
Re: File import error
On 2/03/2019 8:31 AM, Scott Kostyshak wrote: On Fri, Mar 01, 2019 at 01:45:48PM -0500, Paul A. Rubin wrote: On 3/1/19 12:46 AM, Scott Kostyshak wrote: On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote: Is this in 2.3.2? (FWIW, the version I have lists the build date as 12/08/18.) Yes the setting does apply for 2.3.x You can just test with the following added to your preferences file: \use_native_filedialog false and also try with \use_native_filedialog true Any difference in behavior regarding this bug, between those two? Yes and no. On my desktop (where the problem does not manifest), neither of those statements has any effect. Not only does the problem not occur, but the file dialog layout/appearance does not change with either. On my laptop (where the problem does manifest), the true setting matches what is currently happening (with no setting in preferences), while the false setting switches the dialog layout to match that of my desktop and /gets rid of the problem/ (.tex files appear as expected). That still leaves unanswered why it happens one place and not the other with the same version of LyX (as best I can tell). I searched both ~/.lyx and /usr/share/lyx (including subdirectories) on both laptop and desktop, and \use_native_filedialog does not appear anywhere. By the way, is the bug 100% reproducible on the system that has it? Yes. Can you see *any* .tex files? No. With the default filter (.tex), only subdirectories appear; no files do. Does it depend on the directory you're in? No. I just tested but can't reproduce. Interesting! So there seem to be two puzzles from what I understand: 1. Why is the default different on your systems. 2. Why can you only reproduce the bug on one system. I wondered if this issue might show on a windows 10 laptop. The true/false settings produce different dialogues (dialogs?) but the .tex files show in both. Andrew Scott
Re: File import error
On 3/1/19 2:31 PM, Scott Kostyshak wrote: Interesting! So there seem to be two puzzles from what I understand: 1. Why is the default different on your systems. 2. Why can you only reproduce the bug on one system. I agree. I am accursed. If there is a bug in any piece of software, no matter how obscure or hard to trigger, it will bite me. :-( I missed my calling -- should've been an alpha tester. "First of all, it’s not in your head. [bugs] really do prefer some people to others" http://time.com/3311624/why-mosquitoes-bite/ That's another thing. Female mosquitoes adore me. (Female humans, not so much.) Paul
Re: File import error
On Fri, Mar 01, 2019 at 01:45:48PM -0500, Paul A. Rubin wrote: > On 3/1/19 12:46 AM, Scott Kostyshak wrote: > > On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote: > > > > > Is this in 2.3.2? (FWIW, the version I have lists the build > > > date as 12/08/18.) > > Yes the setting does apply for 2.3.x > > > > You can just test with the following added to your preferences file: > > > >\use_native_filedialog false > > > > and also try with > > > >\use_native_filedialog true > > > > Any difference in behavior regarding this bug, between those two? > Yes and no. On my desktop (where the problem does not manifest), neither of > those statements has any effect. Not only does the problem not occur, but > the file dialog layout/appearance does not change with either. > > On my laptop (where the problem does manifest), the true setting matches > what is currently happening (with no setting in preferences), while the > false setting switches the dialog layout to match that of my desktop and > /gets rid of the problem/ (.tex files appear as expected). > > That still leaves unanswered why it happens one place and not the other with > the same version of LyX (as best I can tell). I searched both ~/.lyx and > /usr/share/lyx (including subdirectories) on both laptop and desktop, and > \use_native_filedialog does not appear anywhere. > > > > By the way, is the bug 100% reproducible on the system that has it? > Yes. > > Can > > you see *any* .tex files? > No. With the default filter (.tex), only subdirectories appear; no files do. > > Does it depend on the directory you're in? > No. > > > > I just tested but can't reproduce. Interesting! So there seem to be two puzzles from what I understand: 1. Why is the default different on your systems. 2. Why can you only reproduce the bug on one system. > I am accursed. If there is a bug in any piece of software, no matter how > obscure or hard to trigger, it will bite me. :-( I missed my calling -- > should've been an alpha tester. "First of all, it’s not in your head. [bugs] really do prefer some people to others" http://time.com/3311624/why-mosquitoes-bite/ Scott signature.asc Description: PGP signature
Re: File import error
On 3/1/19 12:46 AM, Scott Kostyshak wrote: On Thu, Feb 28, 2019 at 11:27:06PM -0500, Paul A. Rubin wrote: Is this in 2.3.2? (FWIW, the version I have lists the build date as 12/08/18.) Yes the setting does apply for 2.3.x You can just test with the following added to your preferences file: \use_native_filedialog false and also try with \use_native_filedialog true Any difference in behavior regarding this bug, between those two? Yes and no. On my desktop (where the problem does not manifest), neither of those statements has any effect. Not only does the problem not occur, but the file dialog layout/appearance does not change with either. On my laptop (where the problem does manifest), the true setting matches what is currently happening (with no setting in preferences), while the false setting switches the dialog layout to match that of my desktop and /gets rid of the problem/ (.tex files appear as expected). That still leaves unanswered why it happens one place and not the other with the same version of LyX (as best I can tell). I searched both ~/.lyx and /usr/share/lyx (including subdirectories) on both laptop and desktop, and \use_native_filedialog does not appear anywhere. By the way, is the bug 100% reproducible on the system that has it? Yes. Can you see *any* .tex files? No. With the default filter (.tex), only subdirectories appear; no files do. Does it depend on the directory you're in? No. I just tested but can't reproduce. I am accursed. If there is a bug in any piece of software, no matter how obscure or hard to trigger, it will bite me. :-( I missed my calling -- should've been an alpha tester. Paul
Re: [LyX/master] ctest update.
On Fri, Mar 01, 2019 at 05:02:47PM -, Guenter Milde wrote: > On 2019-03-01, Kornel Benko wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > Am Donnerstag, 28. Februar 2019 21:24:45 CET schrieb Scott Kostyshak > > : > >> On Mon, Feb 25, 2019 at 01:17:36AM +0100, Günter Milde wrote: > >> > commit 4de4263f93fdca326d6603e996c7e8ba35454593 > >> > Author: Günter Milde > >> > Date: Mon Feb 25 01:17:20 2019 +0100 > >> > > >> > ctest update. > >> > > >> > * set required non-TeX fonts in the documents > >> > * update comments for inverted tests > >> > * update some tags > > >> I think starting with this commit, the following test now fails for me: > > >> ctest -R "export/examples/uk/splash_pdf4_texF" > > >> I also have the following test failing (but I'm not sure if it's related > >> to this commit): > > >> ctest -R "export/doc/uk/Intro_pdf4_texF" > > >> Scott > > > I see the same, but I don't thing it was this commit. Using > > the original version of useSystemFonts.pl the errors still appear. > > Checking `ctest -R export.*/uk/.*pdf`: > > 100% tests passed, 0 tests failed out of 14 > > So we have either another TeXLive18 problem or one more instance of > "erratic" behaviour: > > With `ctest -R export.*/uk/.*pdf -N` I see > > Test #3398: UNRELIABLE.ERRATIC_export/doc/uk/Intro_pdf4_texF > > and in unreliableTests I see: > > # Missing Cyrillic LICR commands (on first run after changing from > tex-fonts) > # (leftover *.aux file?) > export/doc/uk/Intro_pdf4_texF > > Maybe there is also "erratic" behaviour for other Ukrainean > XeTeX-with-tex-fonts tests. > > Do the documents compile "per hand" > > a) after opening in LyX, setting non-tex-fonts and compiling > > b) after opening in LyX, compiling with pdflatex, setting non-tex-fonts >and compiling > > ? Thanks, Kornel and Günter for taking a look. I will look into this further and figure out why the test started failing for me. I will report back. Scott signature.asc Description: PGP signature
Re: [LyX/master] ctest update.
On 2019-03-01, Kornel Benko wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > Am Donnerstag, 28. Februar 2019 21:24:45 CET schrieb Scott Kostyshak > : >> On Mon, Feb 25, 2019 at 01:17:36AM +0100, Günter Milde wrote: >> > commit 4de4263f93fdca326d6603e996c7e8ba35454593 >> > Author: Günter Milde >> > Date: Mon Feb 25 01:17:20 2019 +0100 >> > >> > ctest update. >> > >> > * set required non-TeX fonts in the documents >> > * update comments for inverted tests >> > * update some tags >> I think starting with this commit, the following test now fails for me: >> ctest -R "export/examples/uk/splash_pdf4_texF" >> I also have the following test failing (but I'm not sure if it's related >> to this commit): >> ctest -R "export/doc/uk/Intro_pdf4_texF" >> Scott > I see the same, but I don't thing it was this commit. Using > the original version of useSystemFonts.pl the errors still appear. Checking `ctest -R export.*/uk/.*pdf`: 100% tests passed, 0 tests failed out of 14 So we have either another TeXLive18 problem or one more instance of "erratic" behaviour: With `ctest -R export.*/uk/.*pdf -N` I see Test #3398: UNRELIABLE.ERRATIC_export/doc/uk/Intro_pdf4_texF and in unreliableTests I see: # Missing Cyrillic LICR commands (on first run after changing from tex-fonts) # (leftover *.aux file?) export/doc/uk/Intro_pdf4_texF Maybe there is also "erratic" behaviour for other Ukrainean XeTeX-with-tex-fonts tests. Do the documents compile "per hand" a) after opening in LyX, setting non-tex-fonts and compiling b) after opening in LyX, compiling with pdflatex, setting non-tex-fonts and compiling ? Günter
Re: False negative for search including quotation marks
On 01/03/2019 12:14, Kornel Benko wrote: Am Freitag, 1. März 2019 11:43:23 CET schrieb Daniel : On 01/03/2019 11:08, Kornel Benko wrote: Am Freitag, 1. März 2019 10:57:50 CET schrieb Daniel : Just in case this went under the radar: https://www.lyx.org/trac/ticket/11462 Daniel This works now with F&R Adv + format enabled. Sooner or later we may discard quick search ..., now that the advanced find starts to be comparable quick. (Still slower, but not that much). Kornel I can see how a replacement makes sense when it becomes comparable in speed. However, I'd really like to see the analogue of the patch to https://www.lyx.org/trac/ticket/10235 for Advanced F&R, i.e. when pressing the shortcut to open the Advanced F&R pane the whole search field gets selected. This is really helpful for quick successive searches and standard in all applications I know. OK, +1 Unfortunately, I have no clue how to achieve that. Another thing that should be done before this transition is to allow the pane to become much smaller than currently when docked to the bottom, i.e. so that there can be basically just one line of text to search and the buttons and checkboxes become spread out horizontally. I tried unsuccessfully to fix the problem. I think I know how to make things align horizontally, but I could not figure out why the pane's height is now allowed to get smaller. Don't know, maybe because it has 'childrens' which share the same high and width? I don't think so. I noticed that the message and code panes don't share this fate. I think they are somehow differently initialised. But to figure the exact difference out beyond my knowledge, too. Daniel
Re: False negative for search including quotation marks
Am Freitag, 1. März 2019 11:43:23 CET schrieb Daniel : > On 01/03/2019 11:08, Kornel Benko wrote: > > Am Freitag, 1. März 2019 10:57:50 CET schrieb Daniel : > >> Just in case this went under the radar: > >> > >> https://www.lyx.org/trac/ticket/11462 > >> > >> Daniel > >> > > > > This works now with F&R Adv + format enabled. > > > > Sooner or later we may discard quick search ..., now that the advanced find > > starts to be comparable quick. (Still slower, but not that much). > > > > Kornel > > I can see how a replacement makes sense when it becomes comparable in > speed. However, I'd really like to see the analogue of the patch to > > https://www.lyx.org/trac/ticket/10235 > > for Advanced F&R, i.e. when pressing the shortcut to open the Advanced > F&R pane the whole search field gets selected. This is really helpful > for quick successive searches and standard in all applications I know. OK, +1 > Another thing that should be done before this transition is to allow the > pane to become much smaller than currently when docked to the bottom, > i.e. so that there can be basically just one line of text to search and > the buttons and checkboxes become spread out horizontally. I tried > unsuccessfully to fix the problem. I think I know how to make things > align horizontally, but I could not figure out why the pane's height is > now allowed to get smaller. Don't know, maybe because it has 'childrens' which share the same high and width? > Daniel Kornel signature.asc Description: This is a digitally signed message part.
Re: False negative for search including quotation marks
On 01/03/2019 11:08, Kornel Benko wrote: Am Freitag, 1. März 2019 10:57:50 CET schrieb Daniel : Just in case this went under the radar: https://www.lyx.org/trac/ticket/11462 Daniel This works now with F&R Adv + format enabled. Sooner or later we may discard quick search ..., now that the advanced find starts to be comparable quick. (Still slower, but not that much). Kornel I can see how a replacement makes sense when it becomes comparable in speed. However, I'd really like to see the analogue of the patch to https://www.lyx.org/trac/ticket/10235 for Advanced F&R, i.e. when pressing the shortcut to open the Advanced F&R pane the whole search field gets selected. This is really helpful for quick successive searches and standard in all applications I know. Another thing that should be done before this transition is to allow the pane to become much smaller than currently when docked to the bottom, i.e. so that there can be basically just one line of text to search and the buttons and checkboxes become spread out horizontally. I tried unsuccessfully to fix the problem. I think I know how to make things align horizontally, but I could not figure out why the pane's height is now allowed to get smaller. Daniel
Re: False negative for search including quotation marks
Am Freitag, 1. März 2019 10:57:50 CET schrieb Daniel : > Just in case this went under the radar: > > https://www.lyx.org/trac/ticket/11462 > > Daniel > This works now with F&R Adv + format enabled. Sooner or later we may discard quick search ..., now that the advanced find starts to be comparable quick. (Still slower, but not that much). Kornel signature.asc Description: This is a digitally signed message part.
False negative for search including quotation marks
Just in case this went under the radar: https://www.lyx.org/trac/ticket/11462 Daniel
