[patch] fix bug box changing via context menu (bug 8712)
Attached is a patch to fix bug http://www.lyx.org/trac/ticket/8712.
The problem was that if there is no inner box and one executes to remove
the outer box (frame) the result is an empty box (no inner AND no outer
box). But in this case a makebox must be used. This is already handled
in the box dialog. The bug is that it is not yet handled if the box
changing commands are executed via the context menu.
regards Uwe
diff --git
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\InsDE52.tmp\\InsetBox-78ce4ed-left.cpp"
"b/D:\\LyXGit\\Master\\src\\insets\\InsetBox.cpp"
index fd926f4..0be6fb7 100644
---
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\InsDE52.tmp\\InsetBox-78ce4ed-left.cpp"
+++ "b/D:\\LyXGit\\Master\\src\\insets\\InsetBox.cpp"
@@ -264,9 +264,21 @@ void InsetBox::doDispatch(Cursor & cur, FuncRequest & cmd)
return;
}
cur.recordUndoInset(this);
- if (change_type)
+ if (change_type) {
params_.type = cmd.getArg(1);
- else // if (for_box)
+ // set a makebox if there is no inner box but Frameless
was exectued
+ // otherwise the result would be a non existent box (no
inner AND outer box)
+ // (this was LyX bug 8712)
+ if (params_.type == "Frameless" && !params_.inner_box) {
+ params_.use_makebox = true;
+ params_.inner_box = true;
+ }
+ // handle the opposite case
+ if (params_.type == "Boxed" && params_.use_makebox) {
+ params_.use_makebox = false;
+ params_.inner_box = false;
+ }
+ } else // if (for_box)
string2params(to_utf8(cmd.argument()), params_);
setButtonLabel();
break;
Re: ACM-siggraph uncompilable
Am Freitag, 29. Januar 2016 um 00:47:04, schrieb Uwe Stöhr > Am 27.01.2016 um 23:20 schrieb Kornel Benko: > > > Also many tex2lyx tests fail, but that is another story. > > I don't see this. I followed strictly the steps in Development.lyx and > run all the scripts. > > What error do you get with acm-siggraph? Never mind. Old acmsiggraph version. > regards Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: ACM-siggraph failing with newest class/style files
Am 28.01.2016 um 17:31 schrieb Scott Kostyshak: How can the issue be solved if a minimum version is required? I'm guessing the old version will never work. Should the tests assume that the developer running the tests has the newest version of the LaTeX files needed to run the tests? Yes, definitly. The problem with the article classes is that the user MUST use the newest version or he cannot commit his article. So if LyX is not supporting the latest class version, LyX can no longer easily be used to write an article submission. Therefore our lyx2lyx policy makes troubles: The user cannot wait a year until we released a new LyX where we support new class versions. In my opinion we must break our fileformat rule for scientific articles and be able to release a new layout file with the next LyX maintenance release. Of course the new layout won't be compatible with the old one but nobody needs the old one since it can no longer be used for submissions. We could add lyx2lyx code for the conversion to the same fileformat so that the fileformat doesn't need to be changed. regards Uwe
Re: ACM-siggraph uncompilable
Am 27.01.2016 um 23:20 schrieb Kornel Benko: Also many tex2lyx tests fail, but that is another story. I don't see this. I followed strictly the steps in Development.lyx and run all the scripts. What error do you get with acm-siggraph? regards Uwe
Re: [patch] Re: ACM-siggraph failing with newest class/style files
Am 28.01.2016 um 04:54 schrieb Scott Kostyshak: Please always post complete patches. Are you worried about file size when attaching a patch? So you really want to see a patch where more then 300 files where only a number is changed? This way the real part of the patch is hidden. It was not a +1. I know, this was my "interpretation" ;-) Of course this was not strictly following the rule. When I say that "the ACM tests all pass now", that does not mean anything more than "the ACM tests all pass now". Tests are useful for telling us when something is likely wrong, but they cannot tell us that something is necessarily right. I think only an in-depth code review can tell us that. Who will do this? The goal is to push out beta1 and we agreed that then all expected fileformat changes are done. If you find an issue, this can be corrected any time. The template file in LyX is following the template file of siggraph. I also performed all the tests described in Development.lyx. You did this too, so let's go ahead. (This saved me even some stress for the AGUTeX work.) regards Uwe
language nesting test (was: ACM-siggraph uncompilable)
On 2016-01-28, Kornel Benko wrote: > Am Donnerstag, 28. Januar 2016 um 07:07:43, schrieb Guenter Milde > >> On 2016-01-27, Kornel Benko wrote: >> > The following tests FAILED: >> >772 - INVERTED.MANUALS.TODO_export/doc/es/Customization_dvi3_systemF >> > (Failed) >> >777 - INVERTED.MANUALS.TODO_export/doc/es/Customization_pdf4_systemF >> > (Failed) >> >779 - INVERTED.MANUALS.TODO_export/doc/es/Customization_pdf5_systemF >> > (Failed) >> Good news, seems like the translation solved some issues. >> See the comment in Suspici... >> # language nesting (may disappear after completed translation) > Yes, hiding the problem . Not at all: Exporting the Spanish Customization manual with Unicode fonts failed *temporarily* due to the "language nesting with polyglossia" problem: * It worked before the English version of an addition was added, * it failed after (as a placeholder for the translator), some text parts in English were added, * it works again after these English text parts were translated to Spanish and the document reached its normal "clean" state. Now the document can again be used to test for regressions of export with fontspec and polyglossia. This temporary failure is just noise due to the usual process of manual updates interfering with our use of the manuals as test samples also for non-standard output formats. The problem would only be hidden if we removed/changed *all* test samples showing the problem. However: * there is a bug report, * there is active work, * we have a (failing) dedicated autotest sample. If more samples showing the language nesting problem were required, we could make a minimal example out of the mixed-language version (still available via git) - but I'd leave this to the developer working on the problem. Unfortunately, it is a tricky problem which may stay with us for some more time and may also temporarily turn up in the next rounds of manual updates. Günter
Re: [LyX/master] Invert and document test for "longest labeling label" problem.
On 2016-01-28, Kornel Benko wrote: > Am Donnerstag, 28. Januar 2016 um 08:48:48, schrieb Guenter Milde > ... >> back to a place for failing test samples¹. >> Alternatives: >> a) keep them local (this is what most developers currently do). >>+1 simple, good if you work alone on an issue >>-1 no collaboration >> b) put to autotests/export/ and add a commented inversion pattern >>+1 no need to move the sample once it works >>+1 problem description can be seen without opening a lyx file, >> at the same place like other todo issues (without dedicated test file) >>-1 mix of working and failing files in the sample directory >> c) put in a new directory and move once it works >>-1 problem description canot be seen without opening the lyx sample >>+1 no mix of working and failing files in the sample directory > We could combine b) + c) > The mix of working and failing files would be still there, but clearly > separated. >>+1 problem description can be seen without opening a lyx file, >> at the same place like other todo issues (without dedicated test file) >>+1 no mix of working and failing files in the sample directory -1 after solving the issue, there are two actions to take: move the file, remove the "inversion pattern". I don't see the advantage over just b) but could live with this. Finding failing/working samples would be simple with e.g. ctest -N -L inverted -R /samples/ ctest -N -LE inverted -R /samples/ >> We should also consider that there are already "autotest" files scattered >> at several places: >> development/autotests/ > Historical reasons. I confess that moving the export cmake files from > there makes sense. This is not really difficult, I already separated > the tasks for keytests and export tests. Are the keytests automatic tests? If yes, they would be suitable placed in a subdir under the "autotests" dir. .../autotests/keytests .../autotests/export ... >> autotests/ >> Testing/ # Logs written to Testing/Temporary/ > This is in the build-dir, no way to change the path. >> Suggestions: >> * collect the autotest files under one of >> Testing/autotests/ or >> development/autotests/ > There are some mails from Georg explaining why the /autotests dir is > created. If I recall correctly this was when looking for the best name of the directory, reasons were * this is how it is called at KDE * we want separate dirs for automatic tests and interactive tests Both do not speak against Testing/autotests/ >> * rename (Testing|development)/autotests/export/ to >> (Testing|development)/autotests/samples/ >> * eventually add .../autotests/failing-samples/ >> or .../autotests/samples/failing/ > +1 >> Add a README in the samples/ and failing(-samples)? directory, explaining >> for all to place working samples here and failing samples there. >> ¹ mind, that the "longest labeling label" problem is not a *regression* - >> is is there from the beginning of LyX (well actually only since the >> support for "longest label"). > Once it is corrected it will be part of regressions. Only if something works and then fails (again), it is a regression. So, once it is corrected it will be no regression. Once it is corrected it may become a regressions - if it fails later on. With plan c), this would mean we have to move the sample file again: for the time of failure to failing-samples, after solving the regression back to samples :-( Günter
Re: ACM-siggraph failing with newest class/style files
On 2016-01-28, Scott Kostyshak wrote: > On Mon, Jan 25, 2016 at 09:39:11AM +, Guenter Milde wrote: >> > Our ACM-Siggraph LyX template fails to compile (e.g. with pdflatex) >> > with the newest style/class files. ... >> If it indeed fails with one version and works with another, >> we may place that pattern also in "unreliable:erratic": >> # Tests depending on local configuration, OS, TeX distribution, >> # package versions, or the phase of the moon. >> Once the issue is solved, the second pattern should be removed. > How can the issue be solved if a minimum version is required? I'm > guessing the old version will never work. a) When the new version is on all developer's machines (at a minimum) or can be assumed to be the default of the average user. b) When support for the old version is officially ended. Here, we have b) Uwe decided that only the new version makes sense, as it is required for new submissions. I would have preferred a new layout for the new version, so that old documents can still be compiled with old versions of LaTeX-class file and layout. The transfer to the new version would then be done not automatically when opening the file but via change of documentclass by the user (and with "obsoletes" keywords in the layout file). Especially in this case, where the change is large and in any way still requires user interaction this is IMO the better choice. (It would also have spared us one file format change.) > Should the tests assume that the developer running the tests has the > newest version of the LaTeX files needed to run the tests? My opinion is > that we should assume the newest TeX Live update. Even here, I vote for diversity: Not all developers use tlmgr (I use the Debian packages, which are not allways on the newest state). Also, it is actually better if someone tests also with the oldest LyX-supported TeXLive. > but I'm not sure about non-TeX-Live dependencies. Does the > "unreliable:nonstandard" label handle that situation or do we indeed > need to add "unreliable:erratic" ? Thinking about it, I would say that "unreliable:nonstandard" suffices - it already says - "don't rely on this test" (in other words: "don't bother if this test fails") so it would be sufficient to state a required version in the comment explaining the extra requirements leading to the test beeing "nonstandard", e.g. # requires foo.sty 1.5 2016-01-28 (not on CTAN) Günter
Re: make distcheck: cannot remove '../../po/lyx.pot'
Am Donnerstag, 28. Januar 2016 um 12:08:20, schrieb Scott Kostyshak > On Tue, Jan 12, 2016 at 02:47:35PM +0100, Jean-Marc Lasgouttes wrote: > > Le 12/01/2016 03:51, Scott Kostyshak a écrit : > > >I wonder if the difference in behavior is due to: > > >http://lists.gnu.org/archive/html/automake/2012-07/msg00023.html > > > > > >That thread is linked to on the main page: > > >https://www.gnu.org/software/automake/ > > > > It is interesting but I fail to see how this could make a problem for us. > > The only difference in the fix is giving write permission to user instead of > > world. However, when we run distcheck, only one the current user counts. > > > > >It would be nice to know what happens with 1.15. Ubuntu 15.10 has 1.15 > > >so I will try to do a fresh install and check it out. Not sure when > > >though. > > > > I just tried it and it worked without problem. Actually, I suspect that > > there is some timing problem that creates wrong dependencies between files. > > If I do > > make -j4 > make check > make distcheck > > Does the 'make distcheck' know that I asked for 4 jobs in the make call? No > If so, could parallel building be a cause of the timing differences? > > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: make distcheck: cannot remove '../../po/lyx.pot'
I would say that parallel building can be a bad idea. The fact that we have added some dependencies in po/Rules-lyx is probably a factor too, but it is not new to 2.2. JMarc Le 28 janvier 2016 18:08:20 GMT+01:00, Scott Kostyshak a écrit : >On Tue, Jan 12, 2016 at 02:47:35PM +0100, Jean-Marc Lasgouttes wrote: >> Le 12/01/2016 03:51, Scott Kostyshak a écrit : >> >I wonder if the difference in behavior is due to: >> >http://lists.gnu.org/archive/html/automake/2012-07/msg00023.html >> > >> >That thread is linked to on the main page: >> >https://www.gnu.org/software/automake/ >> >> It is interesting but I fail to see how this could make a problem for >us. >> The only difference in the fix is giving write permission to user >instead of >> world. However, when we run distcheck, only one the current user >counts. >> >> >It would be nice to know what happens with 1.15. Ubuntu 15.10 has >1.15 >> >so I will try to do a fresh install and check it out. Not sure when >> >though. >> >> I just tried it and it worked without problem. Actually, I suspect >that >> there is some timing problem that creates wrong dependencies between >files. > >If I do > >make -j4 >make check >make distcheck > >Does the 'make distcheck' know that I asked for 4 jobs in the make >call? >If so, could parallel building be a cause of the timing differences? > >Scott
Re: make distcheck: cannot remove '../../po/lyx.pot'
On Tue, Jan 12, 2016 at 02:47:35PM +0100, Jean-Marc Lasgouttes wrote: > Le 12/01/2016 03:51, Scott Kostyshak a écrit : > >I wonder if the difference in behavior is due to: > >http://lists.gnu.org/archive/html/automake/2012-07/msg00023.html > > > >That thread is linked to on the main page: > >https://www.gnu.org/software/automake/ > > It is interesting but I fail to see how this could make a problem for us. > The only difference in the fix is giving write permission to user instead of > world. However, when we run distcheck, only one the current user counts. > > >It would be nice to know what happens with 1.15. Ubuntu 15.10 has 1.15 > >so I will try to do a fresh install and check it out. Not sure when > >though. > > I just tried it and it worked without problem. Actually, I suspect that > there is some timing problem that creates wrong dependencies between files. If I do make -j4 make check make distcheck Does the 'make distcheck' know that I asked for 4 jobs in the make call? If so, could parallel building be a cause of the timing differences? Scott signature.asc Description: PGP signature
Re: ACM-siggraph failing with newest class/style files
On Mon, Jan 25, 2016 at 09:39:11AM +, Guenter Milde wrote: > On 2016-01-24, Scott Kostyshak wrote: > > > Our ACM-Siggraph LyX template fails to compile (e.g. with pdflatex) > > with the newest style/class files. Note that these are not included in > > TeX Live and must be installed separately, as noted here: > > http://wiki.lyx.org/Examples/AcmSiggraph > > In this case, we need a pattern like > > # requires acmsiggraph.cls, not on CTAN > # see http://wiki.lyx.org/Examples/AcmSiggraph > export/templates/ACM-siggraph_(dvi|pdf).* > > in "unreliable:nonstandard". (So others running the tests will not get a > spurious failure for this extra dependency.) I think I added my +1 for this in the other thread I just responded to. > > Can anyone reproduce? It would be nice to know if we need to update our > > layout. > > If it indeed fails with one version and works with another, > we may place that pattern also in "unreliable:erratic": > > # Tests depending on local configuration, OS, TeX distribution, > # package versions, or the phase of the moon. > > Once the issue is solved, the second pattern should be removed. How can the issue be solved if a minimum version is required? I'm guessing the old version will never work. Should the tests assume that the developer running the tests has the newest version of the LaTeX files needed to run the tests? My opinion is that we should assume the newest TeX Live update, but I'm not sure about non-TeX-Live dependencies. Does the "unreliable:nonstandard" label handle that situation or do we indeed need to add "unreliable:erratic" ? Scott signature.asc Description: PGP signature
Re: why Babel with dvi3 (LuTeX)?
On Thu, Jan 28, 2016 at 08:17:59AM +, Guenter Milde wrote: > On 2016-01-18, Scott Kostyshak wrote: > > ... I'm not convinced that most developers think these export tests are > > that important. If that is indeed the case, then I'm not sure we should > > encourage anyone to run the tests. > > In any case, your and Kornel's work have gone a far way I hope > > for LyX developers believing that at least a *subset* of the export test > > are important enough to have some sort of policy. > > I think this is no clear important/unimportant decision, but a weighting of > cost/effort. > > It took me several months and lots of (partially frustrating but in the end > helpfull) mail-threads to get a basic understanding of the ctest machinery. > > I don't think we can really expect of all developers to > >• Understand how to interpret test failures. If your commit is found >to have broken a test, you should be able to interpret the test >results when made aware of them. > > unless the test system is made easier to understand and better documented. > (The documentation is already too long but still misses points.) I agree that the situation we have right now is not good. But I think it is improving. We are still figuring out the test labels. Once we do that, we can make the documentation more concise. In the long-run, I hope that we can arrive at a situation that is acceptable and understood by everyone. > We have to take the decision to either simplify the system or to keep the > current state that Kornel and you make the work. Well, I think you are doing much more work than I in regards to the tests (thank you to you and Kornel by the way). Scott signature.asc Description: PGP signature
Re: ACM-siggraph uncompilable
On Thu, Jan 28, 2016 at 07:07:43AM +, Guenter Milde wrote: > On 2016-01-27, Kornel Benko wrote: > > > The following tests FAILED: > > 772 - INVERTED.MANUALS.TODO_export/doc/es/Customization_dvi3_systemF > > (Failed) > > 777 - INVERTED.MANUALS.TODO_export/doc/es/Customization_pdf4_systemF > > (Failed) > > 779 - INVERTED.MANUALS.TODO_export/doc/es/Customization_pdf5_systemF > > (Failed) > > Good news, seems like the translation solved some issues. > See the comment in Suspici... > > # language nesting (may disappear after completed translation) > > We still have the failing dedicated sample. > > > 1228 - MANUALS_export/doc/ja/UserGuide_pdf3 (Failed) > > Not related to siggraph. > > > 3365 - TEMPLATES_export/templates/ACM-siggraph_dvi (Failed) > ... > > It works with the new version. However, as these templates are for a > not-on-CTAN class, I vote to add them to > unreliable:nonstandard > in any case. Fine with me. When you add the comment, to be consistent, should we say "not-on-TeXLive class" ? The documentation currently states: nonstandard: Documents with additional requirements, e.g. a class or package file not in TeXLive. They are probably closely related, but apparently not equivalent: http://tex.stackexchange.com/questions/185495/how-can-a-package-be-listed-on-ctan-but-not-be-available-in-tex-live I don't have a strong preference on this so if you think something else makes more sense, go ahead. Scott > The docs are docs, if using them directly as test samples makes problems, > we should use a copied version for the tests. We should write down the advantages and disadvantages of this. One advantage is that we are more likely to catch LyX bugs. For example, when Uwe added English to the Japanese docs, they started to fail (I think you refer to this above). This is probably a LyX bug that we would not catch if we just fixed the documents that we test. Some disadvantages are that there are more noise and frustration. My opinion is that we should not use fixed versions of the documentation to test. We should have unit tests that have fixed versions, and I hope that we simulataneously build up our unit tests. But for these export tests I think we will miss bugs if we only test the fixed versions. I think it is worth the extra noise and that in the long-run we will develop a policy that is agreed upon, not too invasive, and thus we will eventually improve the signal-to-noise ratio. Scott signature.asc Description: PGP signature
Re: [LyX/master] Always place the cursor before a separator inset when clicking
On Thu, Jan 28, 2016 at 02:14:20PM +0100, Enrico Forestieri wrote: > On Thu, Jan 28, 2016 at 09:47:58AM +0100, Guillaume Munch wrote: > > Le 28/01/2016 05:47, Scott Kostyshak a écrit : > > >On Wed, Jan 27, 2016 at 02:23:55AM +0100, Guillaume Munch wrote: > > > > > >>As far as I understand, in release mode, this bug results in an > > >>exception and emergency save, so I think it is best to solve this issue > > >>before beta. > > > > > >I am tempted to suggest we proceed towards beta despite this bug. I do > > >not understand the issue well though, so I would be interested in what > > >others think. > > > > > > > > > It looks pretty bad. Happened to me 4 times in about an hour, when > > moving math insets around. I see. Glad it was fixed then. > > If looking for a quick fix, Enrico (or anybody else) has my +1 for a > > patch along the following lines (I might not be around to commit it myself): > > I committed it. Thanks, Scott signature.asc Description: PGP signature
Re: [LyX/master] Always place the cursor before a separator inset when clicking
On Thu, Jan 28, 2016 at 09:47:58AM +0100, Guillaume Munch wrote: > Le 28/01/2016 05:47, Scott Kostyshak a écrit : > >On Wed, Jan 27, 2016 at 02:23:55AM +0100, Guillaume Munch wrote: > > > >>As far as I understand, in release mode, this bug results in an > >>exception and emergency save, so I think it is best to solve this issue > >>before beta. > > > >I am tempted to suggest we proceed towards beta despite this bug. I do > >not understand the issue well though, so I would be interested in what > >others think. > > > > > It looks pretty bad. Happened to me 4 times in about an hour, when > moving math insets around. > > If looking for a quick fix, Enrico (or anybody else) has my +1 for a > patch along the following lines (I might not be around to commit it myself): I committed it. -- Enrico
Re: [LyX/master] New LFUN tabular-feature (#9794)
Le 27/01/2016 18:53, Guillaume Munch a écrit : commit c9f7ce0a7a6d48b9b60af92828654aa7547286b4 Author: Guillaume Munch Date: Fri Dec 11 02:15:52 2015 + New LFUN tabular-feature (#9794) I re-read the patch rapidly and have a couple cleanup remarks. --- a/src/insets/Inset.cpp +++ b/src/insets/Inset.cpp @@ -391,8 +391,6 @@ bool Inset::getStatus(Cursor &, FuncRequest const & cmd, // FIXME: Why don't we let the insets determine whether this // should be enabled or not ? Now we need this check for // the tabular features. (vfr) - if (cmd.getArg(0) == "tabular") - return false; flag.setEnabled(true); return true; I would think that the FIXME comment can be removed now. +// function sets an object as defined in func_status.h: +// states OK, Unknown, Disabled, On, Off. +bool InsetTabular::getStatus(Cursor & cur, FuncRequest const & cmd, + FuncStatus & status) const The header is now FuncStatus.h JMarc
Re: #9794: inset-modify tabular commands are incorrectly disabled
Am Donnerstag, 28. Januar 2016 um 13:03:02, schrieb Jean-Marc Lasgouttes > Le 27/01/2016 18:55, Guillaume Munch a écrit : > > I have found the motivation to re-do the format increase and the patches > > are now committed. > > Congratulation for your persistence. +1 > JMarc Kornel signature.asc Description: This is a digitally signed message part.
Re: #9794: inset-modify tabular commands are incorrectly disabled
Le 27/01/2016 18:55, Guillaume Munch a écrit : I have found the motivation to re-do the format increase and the patches are now committed. Congratulation for your persistence. JMarc
Re: [LyX/master] Invert and document test for "longest labeling label" problem.
Am Donnerstag, 28. Januar 2016 um 08:48:48, schrieb Guenter Milde > Re: [LyX/master] Invert and document test for "longest labeling label" > problem. > Von: Guenter Milde > An: lyx-devel@lists.lyx.org > Datum:Heute 09:48:48 > On 2016-01-25, Kornel Benko wrote: > > Am 25. Januar 2016 um 21:07:23, schrieb Guenter Milde > >> On 2016-01-25, Kornel Benko wrote: > > > >> >> > Everything in autotests should compile (not inverted), if not ==> > >> >> > regression. > > >> >> Why should we treat "autotests" different from other directories? > > >> > I'd like to have a directory for regressions only. ¹ > > >> Could you move your example file to trac then? > > > Why should I copy it each time from trac when I want to check if the > > file compiles? I am not very fond of trac for testfiles. > > OK. For non-developers, trac is the only way to publish test files, for > developers there are alternatives... > > So, back to a place for failing test samples¹. > > Alternatives: > > a) keep them local (this is what most developers currently do). > >+1 simple, good if you work alone on an issue >-1 no collaboration > > b) put to autotests/export/ and add a commented inversion pattern > >+1 no need to move the sample once it works >+1 problem description can be seen without opening a lyx file, > at the same place like other todo issues (without dedicated test file) >-1 mix of working and failing files in the sample directory > > c) put in a new directory and move once it works > >-1 problem description canot be seen without opening the lyx sample >+1 no mix of working and failing files in the sample directory > We could combine b) + c) The mix of working and failing files would be still there, but clearly separated. > For c), also the entry > > # Probably language mess > export/export/ja/wrong_auto_encoding_(dvi|pdf(|3)) > > must be removed from suspiciousTests and the file moved. > Yes > We should also consider that there are already "autotest" files scattered > at several places: > > development/autotests/ Historical reasons. I confess that moving the export cmake files from there makes sense. This is not really difficult, I already separated the tasks for keytests and export tests. > autotests/ > Testing/ # Logs written to Testing/Temporary/ This is in the build-dir, no way to change the path. > Suggestions: > > * collect the autotest files under one of > > Testing/autotests/ or > development/autotests/ There are some mails from Georg explaining why the /autotests dir is created. > * rename (Testing|development)/autotests/export/ to > (Testing|development)/autotests/samples/ > > * eventually add .../autotests/failing-samples/ > or .../autotests/samples/failing/ +1 > Add a README in the samples/ and failing(-samples)? directory, explaining > for all to place working samples here and failing samples there. > > Günter > > > ¹ mind, that the "longest labeling label" problem is not a *regression* - > is is there from the beginning of LyX (well actually only since the > support for "longest label"). > Once it is corrected it will be part of regressions. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Invert and document test for "longest labeling label" problem.
On 2016-01-25, Kornel Benko wrote: > Am 25. Januar 2016 um 21:07:23, schrieb Guenter Milde >> On 2016-01-25, Kornel Benko wrote: >> >> > Everything in autotests should compile (not inverted), if not ==> >> >> > regression. >> >> Why should we treat "autotests" different from other directories? >> > I'd like to have a directory for regressions only. ¹ >> Could you move your example file to trac then? > Why should I copy it each time from trac when I want to check if the > file compiles? I am not very fond of trac for testfiles. OK. For non-developers, trac is the only way to publish test files, for developers there are alternatives... So, back to a place for failing test samples¹. Alternatives: a) keep them local (this is what most developers currently do). +1 simple, good if you work alone on an issue -1 no collaboration b) put to autotests/export/ and add a commented inversion pattern +1 no need to move the sample once it works +1 problem description can be seen without opening a lyx file, at the same place like other todo issues (without dedicated test file) -1 mix of working and failing files in the sample directory c) put in a new directory and move once it works -1 problem description canot be seen without opening the lyx sample +1 no mix of working and failing files in the sample directory For c), also the entry # Probably language mess export/export/ja/wrong_auto_encoding_(dvi|pdf(|3)) must be removed from suspiciousTests and the file moved. We should also consider that there are already "autotest" files scattered at several places: development/autotests/ autotests/ Testing/ # Logs written to Testing/Temporary/ Suggestions: * collect the autotest files under one of Testing/autotests/ or development/autotests/ * rename (Testing|development)/autotests/export/ to (Testing|development)/autotests/samples/ * eventually add .../autotests/failing-samples/ or .../autotests/samples/failing/ Add a README in the samples/ and failing(-samples)? directory, explaining for all to place working samples here and failing samples there. Günter ¹ mind, that the "longest labeling label" problem is not a *regression* - is is there from the beginning of LyX (well actually only since the support for "longest label").
Re: [LyX/master] Always place the cursor before a separator inset when clicking
Le 28/01/2016 05:47, Scott Kostyshak a écrit :
On Wed, Jan 27, 2016 at 02:23:55AM +0100, Guillaume Munch wrote:
As far as I understand, in release mode, this bug results in an
exception and emergency save, so I think it is best to solve this issue
before beta.
I am tempted to suggest we proceed towards beta despite this bug. I do
not understand the issue well though, so I would be interested in what
others think.
It looks pretty bad. Happened to me 4 times in about an hour, when
moving math insets around.
If looking for a quick fix, Enrico (or anybody else) has my +1 for a
patch along the following lines (I might not be around to commit it myself):
--- a/src/Cursor.cpp
+++ b/src/Cursor.cpp
@@ -1947,7 +1947,7 @@ bool Cursor::upDownInText(bool up, bool &
updateNeeded)
// Make sure that cur gets back whatever happened to dummy
(Lgb)
operator=(dummy);
}
-if (pos() && paragraph().isEnvSeparator(pos() - 1))
+if (inTexted() && pos() && paragraph().isEnvSeparator(pos() - 1))
posBackward();
} else {
// if there is a selection, we stay out of any inset,
Ideally this and all the similar lines should be factored into a
function, and I am also willing to review such a patch (cannot tell when
I'll have the time though).
Guillaume
Re: ACM-siggraph uncompilable
Am Donnerstag, 28. Januar 2016 um 07:07:43, schrieb Guenter Milde > On 2016-01-27, Kornel Benko wrote: > > > The following tests FAILED: > > 772 - INVERTED.MANUALS.TODO_export/doc/es/Customization_dvi3_systemF > > (Failed) > > 777 - INVERTED.MANUALS.TODO_export/doc/es/Customization_pdf4_systemF > > (Failed) > > 779 - INVERTED.MANUALS.TODO_export/doc/es/Customization_pdf5_systemF > > (Failed) > > Good news, seems like the translation solved some issues. > See the comment in Suspici... > > # language nesting (may disappear after completed translation) Yes, hiding the problem . > We still have the failing dedicated sample. > > > 1228 - MANUALS_export/doc/ja/UserGuide_pdf3 (Failed) > > Not related to siggraph. I know. > > 3365 - TEMPLATES_export/templates/ACM-siggraph_dvi (Failed) > ... > > It works with the new version. However, as these templates are for a > not-on-CTAN class, I vote to add them to > unreliable:nonstandard > in any case. Yes, sorry, I seem to have some blackouts. > > Could we please stop this rapid doc changes without test? > > The docs are docs, if using them directly as test samples makes problems, > we should use a copied version for the tests. > > Testing with non-default export should not hold up work on documentation. > > Code changes are another issue... > > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: why Babel with dvi3 (LuTeX)?
On 2016-01-18, Scott Kostyshak wrote: > On Mon, Jan 18, 2016 at 03:59:16PM +, Guenter Milde wrote: >> * they require cmake > I do not agree with this. It is easy to have a separate CMake build > directory. Ah, perhaps you mean literally that they require CMake, > meaning that a system has to have CMake installed and that such a > dependency is significant? It should at least be mentioned, e.g. in the Developer FAQ or in http://www.lyx.org/HowToUseGIT#toc6 (where there is also the right place to tell about the need for a separate build directory!). >> Could you life with the the current description of "expectations of LyX >> developers" (sec 3.3.1.1 in Develomplent.lyx): ... > ... I'm not convinced that most developers think these export tests are > that important. If that is indeed the case, then I'm not sure we should > encourage anyone to run the tests. > In any case, your and Kornel's work have gone a far way I hope > for LyX developers believing that at least a *subset* of the export test > are important enough to have some sort of policy. I think this is no clear important/unimportant decision, but a weighting of cost/effort. It took me several months and lots of (partially frustrating but in the end helpfull) mail-threads to get a basic understanding of the ctest machinery. I don't think we can really expect of all developers to • Understand how to interpret test failures. If your commit is found to have broken a test, you should be able to interpret the test results when made aware of them. unless the test system is made easier to understand and better documented. (The documentation is already too long but still misses points.) We have to take the decision to either simplify the system or to keep the current state that Kornel and you make the work. Thanks, Günter
Re: why Babel with dvi3 (LuTeX)?
On 2016-01-24, Georg Baum wrote: > Guenter Milde wrote: >> On 2016-01-21, Scott Kostyshak wrote: ... >> I agree that there >> should be coordination with the test suite maintainers but no requirement >> to ensure a failure-free test run after patches where there is a >> consensus that they do "the right thing". The developer fixing important >> shortcomings usually does not have the time and expertise to solve these >> test failures anyway. > If it turns out that the test failures fall into this category, then the > developer needs to ask for help. Even if his fix is 100% perfect, if it > causes many tests to fail, then the most effective approach is to first take > some other measures that would reduce the number of failing tests after > applying the patch, and only commit when the number is low or even zero. We > are talking about very few commits per year that fall into this category, so > if it means that some fix needs to wait two weeks until somebody else fixed > some other parts, then this is not a problem IMHO. This would mean to conserve a buggy state because a correct fix reveales problems with the test suite! IMO, in this case the right way would be to keep the patch, invert failing tests as as a stop-gap measure and then solve the follow-up issues. ... I'd still like to see a standard set of export tests that we can make highly recommend for any change which is suspected to change something in LaTeX export. >>> Yes this seems like a good idea. >> Actually, this very much depends on what changes were done and what needs >> testing. >> * There are "obscure" formats that are almost never really used (Lua/XeTeX >> with 8-bit fonts, say). >> * There are tests that replicate most parts: .lyx->.tex->.dvi for >> "dvi", "ps", "pdf", "pdf3" (usually it should suffice to test "dvi"). >> * Some changes only regard 8-bit TeX, others only Xe/LuaTeX. >> * It may suffice to test a simple document (splash.lyx or Intro.lyx) with >> every language, or >> * if may be OK to test with just English, >> * ... > Seems I need to explain what I expect from such a set of standard tests. If > you look at the export bugs we had in the past, it was quite rare they > showed only up in only one of the export tests. They usually triggered a lot > of the tests, and bug fixes did usually make lots of failures vanish. > Therefore, you can simply do some statistics on that and come up with a very > small set of tests which do still cover 90% of the coverage of the complete > set of several thousand test cases. This is nothing invented by me, I read a > paper about that some time go, can look it up if needed. > In our case we do not have enough statistical data yet to collect a good > small test set (because lots of buigs were fixed before we had tests), but > we can as well collect a good test set manually, based on our understanding > of the LaTeX export. > If we have such a set of standard tests, then we can recommend it to be run > before commit in many cases (because it would be fast), and it would find > many of the problems which have only been found by the full tests in the > past. The idea is that the developer who fixes something would not need to > think about what tests to run. > I see the procedure you describe more on top of that for ironing out the > last few percent of bugs. The number of tests is huge, because we test the full 3-dimensional matrix: sample documents * languages * output formats This can be reduced when we only test along the axes. Of course this misses some problems like a bug in Spanish babel math support for non-TeX fonts ... Depending on whether you want 80% coverage with 1% of the tests or 90% coverage with 10% of the tests I can propose two sets. Maybe we can even use both. My suggestion is to introduce the labels export:core # small subset export:standard # everything expect "exotic" cases With pattern files similar to SuspiciousTests, IgnoredTests, ..., this would also be easy to adapt and develop. The "expectation to developers" would then be run ctests -L export:core or ctests -L export:standard All export tests: ctsts -N -L "export|suspended" Total Tests: 3930 Suggestion for a start: CoreTests: # main packages and modules, math, indexing, ... # # English Manuals with default output (pdf2 = pdflatex) (11 Tests) export/doc/[A-CE-Z].*pdf2 # exclude Development and DummyDocument # Internationalization # # Intro.lyx in all languages (25 Tests) export/doc/.+/Intro.*pdf2 # All supported output formats # # Dedicated sample testing all supported graphic formats (to be written) export/export/image-conversion.* (14 Tests (if including ps)) # Total Tests 45 StandardTests: # Only "sensible" output formats without post-processors # (LaTeX, pdfLaTeX, XeTeX, LuaTeX) .*dvi|pdf2|pdf4_systemF|pdf5_systemF|xhtml|lyx21 # also lyx16? Total Tests: 2415 We should think about further exclusions for the st
