Am Sonntag, 1. November 2015 um 15:00:25, schrieb Scott Kostyshak <skost...@lyx.org> > On Sun, Nov 01, 2015 at 07:37:41PM +0000, Guenter Milde wrote: > > On 2015-10-30, Kornel Benko wrote: > > > Am Freitag, 30. Oktober 2015 um 19:23:02, schrieb Scott Kostyshak > > > <skost...@lyx.org> > > > Besides we have ATM about 200 failing export test cases. > > > > Too many to be helpfull. > > I don't understand this logic. > > > > The summary contains lines like: > > > Label Time Summary: > > > export = 59316.83 sec (3753 tests) > > > key = 0.26 sec (1 test) > > > reverted = 5631.52 sec (312 tests) > > > > > Even if we label some tests, the summary does not specify > > > how mane tests went wrong for a specified label. > > > > How many of these are for the obscure combination of Xetex and Tex fonts? > > While there is a use case for LuaTeX and TeX fonts, I can't see a reason to > > use Xetex instead of pdflatex with TeX fonts! > > The use case that I have in mind is simply that I expect our users might > use such a combination. If we don't want to support the combination, we > should output a useful error message explaining why, or just disable the > combination. If not, users will use it. Many LyX users do not have the > understanding that you do. They do not even understand what it means to > use non-TeX fonts. They might just read something about XeTeX and start > using it by clicking on our button that says PDF (XeTeX). The purpose of > the tests is just to prevent regressions. Sure, maybe it is true that > something was working by luck before, but I still think it is reasonable > to try to preserve it. So I defend the tests in general. The current > situation is a special case. You fixed a bug (the missing characters > bug) and that is why so many tests are failing. I do not imagine such a > situation coming up often. > > > Solving all issues that arise from this combination is diverting attention > > and ressources from more important tasks. > > Agreed. > > > Also, we identified some generic problems with this combination that are > > not solvable in the short term: third party packages well as documents > > not prepared for this use case. > > > > Just reverting failing Xetex export tests for the moment would allow us to > > concentrfate on the remaining failing test and get the test suite in a > > usable state again. > > Fine with me. Kornel, OK with you? We could create a bug report so that > we do not forget about the tests. Then we could just invert all of the > pdf4_texF tests that are failing. I have in mind just pasting the long > list of individual tests, rather than using regexes.
I have to be convinced. It is not OK with me, see my other post.
Remark to regexes:
1.) it is easier for us to read such a file
2.) but is takes longer time to interpret.
#ctest -j12 -R 'export/.*(pdf|dvi)' -N | wc
3085
ATM, we have 59 lines to identify 300 inverted tests.
Adding the new 200 we have 500 individual lines.
That means we have to check (500/2) * 3085 combinations
to determine which test is inverted and which not.
ATM, we have 59 lines to identify 300 inverted tests.
> Scott
Kornel
signature.asc
Description: This is a digitally signed message part.
