Re: Index made by texindy: log available?
Am Donnerstag, den 03.12.2015, 02:23 +0100 schrieb Jürgen Lange: > log.idx is not very informative (No error report). So implementing > this is > not useful. It can be implemented with some effort, see http://www.lyx.org/trac/ticket/2569 Jürgen > > Regards
Re: [patch] origin again
On Sun, Jan 10, 2016 at 12:44:12AM +0100, Enrico Forestieri wrote: > On Thu, Dec 31, 2015 at 09:13:02PM +0100, Georg Baum wrote: > > > Sorry for opening a new thread, but gmane did already expire the old thread > > in the nntp interface, and I do not keep lyx-devel mails. > > > > The attached patch implements the third option I described in the starting > > message of the original thread: > > > > > - Do not change the paths in general if the files can be found using the > > > relative paths. Has the additional benefit that this is also the wanted > > > behaviour if I copy a whole directory of LyX files (including referenced > > > graphics) to a new location. Disadvantage would be that the machinery does > > > now depend on the presence of external files, and it is not guaranteed > > > that the file that is found is the correct one. > > I am fine with this and you have a +1 from me. However, note that the origin > handling is currently broken. Indeed, allowing to save the document directory > in the preferences, after creating a new file and saving it, the path in the > origin tag is missing the trailing slash and thus it will not work. > This was working fine until not so long ago, hence it must have been broken > recently, most probably by the patches for dealing with symlinks. The attached patch fixes the above issue. BTW, your patch works very well :) -- Enrico diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp index fe47c05..8024d4a 100644 --- a/src/BufferParams.cpp +++ b/src/BufferParams.cpp @@ -1015,11 +1015,11 @@ void BufferParams::writeFile(ostream & os, Buffer const * buf) const // The top of the file is written by the buffer. // Prints out the buffer info into the .lyx file given by file - // the document directory - // use realPath() instead of absFileName() for comparing - // so we can catch also eventually used symbolic parts of the path. - string filepath = buf->fileName().onlyPath().realPath(); - string const sysdir = package().system_support().realPath(); + // the document directory (must end with a path separator) + // realPath() is used to resolve symlinks, while addPath(..., "") + // ensures a trailing path separator. + string filepath = addPath(buf->fileName().onlyPath().realPath(), ""); + string const sysdir = addPath(package().system_support().realPath(), ""); string const relpath = to_utf8(makeRelPath(from_utf8(filepath), from_utf8(sysdir))); if (!prefixIs(relpath, "../") && !FileName::isAbsolute(relpath))
Re: [patch] origin again
On Thu, Dec 31, 2015 at 09:13:02PM +0100, Georg Baum wrote: > Sorry for opening a new thread, but gmane did already expire the old thread > in the nntp interface, and I do not keep lyx-devel mails. > > The attached patch implements the third option I described in the starting > message of the original thread: > > > - Do not change the paths in general if the files can be found using the > > relative paths. Has the additional benefit that this is also the wanted > > behaviour if I copy a whole directory of LyX files (including referenced > > graphics) to a new location. Disadvantage would be that the machinery does > > now depend on the presence of external files, and it is not guaranteed > > that the file that is found is the correct one. I am fine with this and you have a +1 from me. However, note that the origin handling is currently broken. Indeed, allowing to save the document directory in the preferences, after creating a new file and saving it, the path in the origin tag is missing the trailing slash and thus it will not work. This was working fine until not so long ago, hence it must have been broken recently, most probably by the patches for dealing with symlinks. -- Enrico
Re: "Splitting of consecutive environments has been reworked and enhanced"
On Sat, Jan 09, 2016 at 05:32:17PM -0500, Richard Heck wrote: > On 01/09/2016 05:29 PM, Enrico Forestieri wrote: > > On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote: > >> I also have another bug to report (very subtle and better seen in > >> combination with the view source panel). There seems to be two cursor > >> positions before and after the separator, both being displayed before > >> the separator. One cannot access the second position with ← and →, but > >> it is possible to do so with ↑ and ↓, and in that case using ← is as if > >> it does nothing, but in the source we see that it goes from after the \n > >> character to before it. Also, this means that we never know whether we > >> must use delete or backspace to remove a separator. I think the > >> intension was to hide the "after" position entirely. > > The attached patch avoids the "after" position when moving with ↑ and ↓. > > Also looks good to commit. Thanks. Committed at bbb5a1a2. -- Enrico
Re: "Splitting of consecutive environments has been reworked and enhanced"
On Sat, Jan 09, 2016 at 05:31:37PM -0500, Richard Heck wrote: > On 01/09/2016 05:24 PM, Enrico Forestieri wrote: > > On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote: > >> Le 11/12/2015 22:47, Enrico Forestieri a écrit : > >>> On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote: > > [...] > • Defect: They tend to accumulate and they are redundant because there > is only one additional '\n' in the LaTeX source. The problem is the > one can add one before another. Thus, two such consecutive chars > should be merged as a single one, like it is done for spaces in LyX. > >>> There were a lot of problems to be solved and this one was escaping me. > >>> Thank you for pointing it out. I will try to address it when I will find > >>> time (and motivation) to work again on LyX. Unfortunately, I will be > >>> unavailable the next weeks. > >> Thanks. > > The attached patch avoids the proliferation of parbreak seaparators. > > Yes, this looks fine to me. Officially: +1. Thanks. Committed at c8aaaff1. -- Enrico
Re: Questions for Uwe?
On Sat, Jan 09, 2016 at 11:58:16AM +0100, Peter Kümmel wrote: > > > Am 09.01.2016 um 01:32 schrieb Scott Kostyshak: > >S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1 > >and 5.6.0beta1? > > There will be no downloadable msvc2010 builds for 5.6. ATM only 5.5.1: > > http://www.qt.io/download-open-source/#section-2 I see, good to know. I will remove this question then. > >G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also > >build > >the prerequisite from the sources Peter added, using exactly the same > >compiler as is used to build LyX. > > If Uwe tries to build the installer with the mingw build from the build bot, > and it makes no problems, then a mingw > based installer isn't far away. This is great news! Let's replace my S1 question with the following question then: S1 Can you build beta1 installers with both your original way and also using the mingw build from Peter's build bot? From what I understand, this involves downloading the zip from: https://github.com/syntheticpp/LyX-bleeding-edge/archive/LyX-master-win32.zip Scott signature.asc Description: PGP signature
Re: "Splitting of consecutive environments has been reworked and enhanced"
On 01/09/2016 05:29 PM, Enrico Forestieri wrote: > On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote: >> I also have another bug to report (very subtle and better seen in >> combination with the view source panel). There seems to be two cursor >> positions before and after the separator, both being displayed before >> the separator. One cannot access the second position with ← and →, but >> it is possible to do so with ↑ and ↓, and in that case using ← is as if >> it does nothing, but in the source we see that it goes from after the \n >> character to before it. Also, this means that we never know whether we >> must use delete or backspace to remove a separator. I think the >> intension was to hide the "after" position entirely. > The attached patch avoids the "after" position when moving with ↑ and ↓. Also looks good to commit. Richard
Re: "Splitting of consecutive environments has been reworked and enhanced"
On 01/09/2016 05:24 PM, Enrico Forestieri wrote: > On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote: >> Le 11/12/2015 22:47, Enrico Forestieri a écrit : >>> On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote: > [...] • Defect: They tend to accumulate and they are redundant because there is only one additional '\n' in the LaTeX source. The problem is the one can add one before another. Thus, two such consecutive chars should be merged as a single one, like it is done for spaces in LyX. >>> There were a lot of problems to be solved and this one was escaping me. >>> Thank you for pointing it out. I will try to address it when I will find >>> time (and motivation) to work again on LyX. Unfortunately, I will be >>> unavailable the next weeks. >> Thanks. > The attached patch avoids the proliferation of parbreak seaparators. Yes, this looks fine to me. Officially: +1. Richard
Re: "Splitting of consecutive environments has been reworked and enhanced"
On Thu, Dec 17, 2015 at 06:57:23PM +, Guillaume Munch wrote: > > I also have another bug to report (very subtle and better seen in > combination with the view source panel). There seems to be two cursor > positions before and after the separator, both being displayed before > the separator. One cannot access the second position with ← and →, but > it is possible to do so with ↑ and ↓, and in that case using ← is as if > it does nothing, but in the source we see that it goes from after the \n > character to before it. Also, this means that we never know whether we > must use delete or backspace to remove a separator. I think the > intension was to hide the "after" position entirely. The attached patch avoids the "after" position when moving with ↑ and ↓. -- Enrico diff --git a/src/Cursor.cpp b/src/Cursor.cpp index c1eb32f..bf667e9 100644 --- a/src/Cursor.cpp +++ b/src/Cursor.cpp @@ -1947,6 +1947,8 @@ 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)) + posBackward(); } else { // if there is a selection, we stay out of any inset, // and just jump to the right position:
Re: "Splitting of consecutive environments has been reworked and enhanced"
On Sat, Dec 12, 2015 at 12:34:47AM +, Guillaume Munch wrote: > Le 11/12/2015 22:47, Enrico Forestieri a écrit : > >On Fri, Dec 11, 2015 at 06:52:19PM +, Guillaume Munch wrote: [...] > >>• Defect: They tend to accumulate and they are redundant because there > >> is only one additional '\n' in the LaTeX source. The problem is the > >> one can add one before another. Thus, two such consecutive chars > >> should be merged as a single one, like it is done for spaces in LyX. > > > >There were a lot of problems to be solved and this one was escaping me. > >Thank you for pointing it out. I will try to address it when I will find > >time (and motivation) to work again on LyX. Unfortunately, I will be > >unavailable the next weeks. > > Thanks. The attached patch avoids the proliferation of parbreak seaparators. -- Enrico diff --git a/src/Text3.cpp b/src/Text3.cpp index 9edda1b..ca6ec5b 100644 --- a/src/Text3.cpp +++ b/src/Text3.cpp @@ -1097,6 +1097,8 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd) cap::replaceSelection(cur); pit_type pit = cur.pit(); Paragraph const & par = pars_[pit]; + bool lastpar = (pit == pit_type(pars_.size() - 1)); + Paragraph const & nextpar = lastpar ? par : pars_[pit + 1]; pit_type prev = pit; if (pit > 0) { if (!pars_[pit - 1].layout().isEnvironment()) @@ -1105,10 +1107,13 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd) prev = pit - 1; } if (prev < pit && cur.pos() == par.beginOfBody() - && !par.isEnvSeparator(cur.pos()) + && !par.isEnvSeparator(par.size() ? par.size() - 1 : 0) && !par.layout().isCommand() && pars_[prev].layout() != par.layout() - && pars_[prev].layout().isEnvironment()) { + && pars_[prev].layout().isEnvironment() + && (!nextpar.isEnvSeparator(nextpar.size() ? nextpar.size() - 1 : 0) + || nextpar.layout().isCommand() + || nextpar.layout().isEnvironment())) { if (par.layout().isEnvironment() && pars_[prev].getDepth() == par.getDepth()) { docstring const layout = par.layout().name(); @@ -1124,6 +1129,8 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd) Font const f(inherit_font, cur.current_font.language()); pars_[cur.pit() - 1].resetFonts(f); } else { + if (par.isEnvSeparator(cur.pos())) +cur.posForward(); breakParagraph(cur, cmd.argument() == "inverse"); } cur.resetAnchor();
Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)
On Sat, Jan 09, 2016 at 09:23:43PM +, Guenter Milde wrote: > On 2016-01-09, Kornel Benko wrote: > > Am Samstag, 9. Januar 2016 um 17:51:06, schrieb Guenter Milde > > > >> On 2016-01-08, Scott Kostyshak wrote: > ... > > > for the tests to do the best job they can at testing the use of system > >> > fonts. > ... > >> However, "the best job they can" (for me) does not imply using a sans > >> serif font for all three:, serif, sans serif, and monospaced. > > > I wonder what makes you think that the test uses sans serif only? (Yes, > > there is one condition which does it that way, but other cases do not) > > The linked discussion on the luatex list had a Hebrew example with "Free > Sans" for serif, sans and mono. As my trials with several serif fonts all > triggered the spurious error described in #8035 but Scott reported a > successfull compilation of our test, I assume that this is due to the > same font settings (hidden to the non-initiated). > > Thanks to the recent addition of the test-samples directory, non-hackish > testing of Hebrew with system fonts can now be done with a dedicated > sample document requiring only sans serif fonts (and mentioning this > current limitation). Would you suggest testing Hebrew documents with FreeSerif for Roman, FreeSans for sans, and FreeMono for typewriter? I think the reason why I supported using FreeSans for all three was because I wanted to simplify things as much as possible. In particular, I was worried about the case where Freesans contains a glyph but FreeMono does not. I do not have a preference though and using the other Free variants is indeed more realistic, and I think this is what Kornel wanted to do before anyway. Scott signature.asc Description: PGP signature
Re: beta release
On Sat, Jan 09, 2016 at 11:03:53PM +0100, Enrico Forestieri wrote: > On Sat, Jan 09, 2016 at 03:36:52PM -0500, Richard Heck wrote: > > > On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote: > > > Le 09/01/2016 01:15, Scott Kostyshak a écrit : > > >> Georg's patch still needs a final +1: > > >> https://www.mail-archive.com/search?l=mid&q=n6have%24b5i%244%40ger.gmane.org > > >> > > >> JMarc did you have any other concerns with it? Does anyone else? > > > > > > Unfortunately I do not know much about this origin business. My > > > comment was about the fact that hardcoding the origin at install time > > > feel wrong and I proposed an alternate solution. For later of course. > > > > I'm afraid I'm in the same boat. Enrico may be the only other person who > > really understands it. > > That would be really unfortunate, but I think that at least Georg understands > it. > Anyway, I agree with whatever is decided and, FWIW, he has a +1 from me. > I have to say that I regret having introduced that parameter. Just to make it clear, a +1 is worth a lot. It means "commit". Our current policy is that a developer who posts a patch and gets a "+1" can commit to master. Scott signature.asc Description: PGP signature
Re: beta release
On Sat, Jan 09, 2016 at 03:36:52PM -0500, Richard Heck wrote: > On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote: > > Le 09/01/2016 01:15, Scott Kostyshak a écrit : > >> Georg's patch still needs a final +1: > >> https://www.mail-archive.com/search?l=mid&q=n6have%24b5i%244%40ger.gmane.org > >> > >> JMarc did you have any other concerns with it? Does anyone else? > > > > Unfortunately I do not know much about this origin business. My > > comment was about the fact that hardcoding the origin at install time > > feel wrong and I proposed an alternate solution. For later of course. > > I'm afraid I'm in the same boat. Enrico may be the only other person who > really understands it. Makes sense. I appreciate your hesitancy. I'm CC'ing Enrico. Scott signature.asc Description: PGP signature
Please be explicit if giving a +1
Since we now require a +1 from another developer before a patch goes in, I have seen some confusion because some reviewers have written something like "looks OK" or "I have tested and nothing broke" and the author of the patch is understandably not sure if what was written was a +1 or not. If these statements were intended to be safe and to not give a +1 then good, I think they did their job and I see no problem with continuing to use such phrases. They provide good feedback for the daring LyX developer that does want to give a +1 so they still serve a purpose. But if you want to give a +1, either write "+1" or "please commit" to make it clear that you support the author to push the patch for 2.2.0. Scott signature.asc Description: PGP signature
Re: beta release
On Sat, Jan 09, 2016 at 03:36:52PM -0500, Richard Heck wrote: > On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote: > > Le 09/01/2016 01:15, Scott Kostyshak a écrit : > >> Georg's patch still needs a final +1: > >> https://www.mail-archive.com/search?l=mid&q=n6have%24b5i%244%40ger.gmane.org > >> > >> JMarc did you have any other concerns with it? Does anyone else? > > > > Unfortunately I do not know much about this origin business. My > > comment was about the fact that hardcoding the origin at install time > > feel wrong and I proposed an alternate solution. For later of course. > > I'm afraid I'm in the same boat. Enrico may be the only other person who > really understands it. That would be really unfortunate, but I think that at least Georg understands it. Anyway, I agree with whatever is decided and, FWIW, he has a +1 from me. I have to say that I regret having introduced that parameter. -- Enrico
Re: Status on Mac with El Capitan
On Sat, Jan 09, 2016 at 02:27:46PM +0100, Stephan Witt wrote: > Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > > > Le 08/01/2016 10:08, Stephan Witt a écrit : > >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : > >>> Yes, unless somone has a different brilliant idea. > >> > >> Am I right that it makes explicit what is otherwise implicit? So it is > >> safe to commit? > > > > Yes, I think so. The question is only maintainability. Guillaume complained > > that the is fragile because new code can forget to add this explicit lyx::. > > Scott, > > I’d like to commit the patch (attached again). Is this ok? I do not understand it. I'm fine as long as another developer gives an explicit +1. Scott signature.asc Description: PGP signature
Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)
On 2016-01-09, Kornel Benko wrote: > Am Samstag, 9. Januar 2016 um 17:51:06, schrieb Guenter Milde > >> On 2016-01-08, Scott Kostyshak wrote: ... > for the tests to do the best job they can at testing the use of system >> > fonts. ... >> However, "the best job they can" (for me) does not imply using a sans >> serif font for all three:, serif, sans serif, and monospaced. > I wonder what makes you think that the test uses sans serif only? (Yes, > there is one condition which does it that way, but other cases do not) The linked discussion on the luatex list had a Hebrew example with "Free Sans" for serif, sans and mono. As my trials with several serif fonts all triggered the spurious error described in #8035 but Scott reported a successfull compilation of our test, I assume that this is due to the same font settings (hidden to the non-initiated). Thanks to the recent addition of the test-samples directory, non-hackish testing of Hebrew with system fonts can now be done with a dedicated sample document requiring only sans serif fonts (and mentioning this current limitation). Günter
Re: beta release
On 01/09/2016 03:01 PM, Jean-Marc Lasgouttes wrote: > Le 09/01/2016 01:15, Scott Kostyshak a écrit : >> Georg's patch still needs a final +1: >> https://www.mail-archive.com/search?l=mid&q=n6have%24b5i%244%40ger.gmane.org >> >> JMarc did you have any other concerns with it? Does anyone else? > > Unfortunately I do not know much about this origin business. My > comment was about the fact that hardcoding the origin at install time > feel wrong and I proposed an alternate solution. For later of course. I'm afraid I'm in the same boat. Enrico may be the only other person who really understands it. Richard
Re: beta release
Le 09/01/2016 01:15, Scott Kostyshak a écrit : Georg's patch still needs a final +1: https://www.mail-archive.com/search?l=mid&q=n6have%24b5i%244%40ger.gmane.org JMarc did you have any other concerns with it? Does anyone else? Unfortunately I do not know much about this origin business. My comment was about the fact that hardcoding the origin at install time feel wrong and I proposed an alternate solution. For later of course. Beside the fact that I tend to trust Georg, I do not have much useful input here. JMarc
Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)
Am Samstag, 9. Januar 2016 um 17:51:06, schrieb Guenter Milde > On 2016-01-08, Scott Kostyshak wrote: > > > [-- Type: text/plain, Encoding: quoted-printable --] > > > On Fri, Jan 08, 2016 at 08:11:19PM +0100, Kornel Benko wrote: > >> Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak > >> > >> > On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote: > > >> > > * FreeSans seems to provide the correct script-support info not to > >> > > trigger the false-positive error > >> > > http://www.lyx.org/trac/ticket/8035 > >> > > > >> > > However, setting all of "mainfont", "sansfont", and "monofont" > >> > > to FreeSans seems "hackish" to me. > > >> No it is not hackish IMHO. The test should show, that with a suitable > >> font this file is compilable. It is a remnant from the times we had > >> defined fonts for texF only. If the non-tex font is defined in the > >> document, it will be used. > > > I agree with Kornel that it is not hackish of the tests. > > I agree, that testing with system fonts is not bad. As long as this > requires a hack (like changing fonts or the "useNonTeXfonts" setting > "secretly" in a test script, this is not bad either. > > However, it remains a hack and could/should be replaced if a better way of > operating is available. > > Currently, if I want to check a failure with .*systemF, I have to > > a) change it to use non-TeX fonts, > b) eventually set alternative system fonts >(which may or may not be the same as the "secretly" used ones by the test >machinery). > > Since 2.2, step b) is no longer necessary, we can store alternative system > fonts in the source. > > > > I think what Günter's main underlying point (please correct me if I'm > > wrong) is to make it clear that *LyX* (not the tests) should have a > > better framework for encouraging system fonts by default for XeTeX and > > LuaTeX. > > This is a different point. With a new config value "automatic" for "use > non-TeX fonts" (second part of ticket #9744), also step a) would no longer > be required. > > > But since LyX does not do that, my opinion is that it is a great idea > > for the tests to do the best job they can at testing the use of system > > fonts. > > Yes, as long as LyX cannot do that, we need the workaround. > > However, "the best job they can" (for me) does not imply using a sans > serif font for all three:, serif, sans serif, and monospaced. I wonder what makes you think that the test uses sans serif only? (Yes, there is one condition which does it that way, but other cases do not) > I agree that I have a personal interest, as these replacements vitiate > one of the use cases in #8035 (while there are alternative serif fonts > that would work if #8035 were solved). > > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: why Babel with dvi3 (LuTeX)?
On 2016-01-09, Kornel Benko wrote: > Am Samstag, 9. Januar 2016 um 15:07:32, schrieb Guenter Milde > >> On 2016-01-09, Kornel Benko wrote: >> > After the last commit, this tests fail: >> >1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed) >> >1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed) >> >1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed) >> They work here. Can you establish the cause for failure and eventually add a >> patter to unreliable? > Manually it works. Compiling the changed file used by test I get > Missing character: There is no ☞ (U+261E) in font > "FreeSans:mode=node;script=l > This was because of error in test-suite. In contrast to what I said > that the font would be replaced only if set to default, it was replaced > unconditionally. Works now. I will wait for your commit before > committing the correction. >> > and also >> >579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 >> > (Failed) >> >580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF >> > (Failed) >> >581 - >> > SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed) >> This was a mistake in the pattern, I'll upload a fix soon. Done (710f284f1/lyxgit) Now it is your turn. Thanks, Günter
Re: Questions for Uwe?
On 2016-01-09, Scott Kostyshak wrote: > I have gone through this thread and tried to make a summary of the questions > and discussion for Uwe. Please add more questions if you have any or edit my > misinterpretation of the question/comment. > The following letters refer to the person that asked the question. > G=Georg > R=Richard > S=Scott > S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1 > and 5.6.0beta1? > S2. Can you make the installers from *only* the tar ball (and not use the > git directory at all)? Note that if there is a technical reason why this is > difficult if you ask on the list I am guessing someone can help. > S3. Richard has been committing updates to po files. Can you confirm that all > translation updates we have received have been merged? Has anyone emailed > updates to you privately? > R4. Do we also want to try releasing an installer built with mingw? > (G response: IMO, we only need to release one installer. The mingw and MSVC > builds behave exactly the same (modulo bugs). So the question is rather > whether > we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be > MSVC, otherwise it will probably be mingw. > G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also > build > the prerequisite from the sources Peter added, using exactly the same > compiler as is used to build LyX. > S6. Can you still reproduce these two tickets? > http://www.lyx.org/trac/ticket/9892 > http://www.lyx.org/trac/ticket/9900 > If so, do you think they are beta blockers? > That is part of the reason why I am curious about Qt 5.6.0beta1 (see question > S1). Maybe it makes those issues go away somehow. GM1: could we add a line \@ifpackageloaded{fontspec}{\unaccentedoperators}{} to the user-preamble of doc/es/UserGuide.lyx? This would work around a bug in babel-spanish preventing compilation with non-TeX fonts without affecting the default pdflatex output. GM2: may we define alternative "non-TeX fonts" in the manuals containing characters missing in the default LatinModern Unicode fonts? Again, this would help compilation with non-TeX fonts without affecting the default output. Günter
Re: ctests failed tests (was: [PATCH] Use \AA and \aa for "latin letter A with ring above".)
On 2016-01-08, Scott Kostyshak wrote: > [-- Type: text/plain, Encoding: quoted-printable --] > On Fri, Jan 08, 2016 at 08:11:19PM +0100, Kornel Benko wrote: >> Am Freitag, 8. Januar 2016 um 12:21:44, schrieb Scott Kostyshak >> >> > On Fri, Jan 08, 2016 at 07:09:44AM +, Guenter Milde wrote: >> > > * FreeSans seems to provide the correct script-support info not to >> > > trigger the false-positive error >> > > http://www.lyx.org/trac/ticket/8035 >> > > >> > > However, setting all of "mainfont", "sansfont", and "monofont" >> > > to FreeSans seems "hackish" to me. >> No it is not hackish IMHO. The test should show, that with a suitable >> font this file is compilable. It is a remnant from the times we had >> defined fonts for texF only. If the non-tex font is defined in the >> document, it will be used. > I agree with Kornel that it is not hackish of the tests. I agree, that testing with system fonts is not bad. As long as this requires a hack (like changing fonts or the "useNonTeXfonts" setting "secretly" in a test script, this is not bad either. However, it remains a hack and could/should be replaced if a better way of operating is available. Currently, if I want to check a failure with .*systemF, I have to a) change it to use non-TeX fonts, b) eventually set alternative system fonts (which may or may not be the same as the "secretly" used ones by the test machinery). Since 2.2, step b) is no longer necessary, we can store alternative system fonts in the source. > I think what Günter's main underlying point (please correct me if I'm > wrong) is to make it clear that *LyX* (not the tests) should have a > better framework for encouraging system fonts by default for XeTeX and > LuaTeX. This is a different point. With a new config value "automatic" for "use non-TeX fonts" (second part of ticket #9744), also step a) would no longer be required. > But since LyX does not do that, my opinion is that it is a great idea > for the tests to do the best job they can at testing the use of system > fonts. Yes, as long as LyX cannot do that, we need the workaround. However, "the best job they can" (for me) does not imply using a sans serif font for all three:, serif, sans serif, and monospaced. I agree that I have a personal interest, as these replacements vitiate one of the use cases in #8035 (while there are alternative serif fonts that would work if #8035 were solved). Günter
Re: why Babel with dvi3 (LuTeX)?
Am Samstag, 9. Januar 2016 um 15:07:32, schrieb Guenter Milde > Dear Kornel, > > thank you for the quick test report. > > On 2016-01-09, Kornel Benko wrote: > > > After the last commit, this tests fail: > > 1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed) > > 1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed) > > 1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed) > > They work here. Can you establish the cause for failure and eventually add a > patter to unreliable? Manually it works. Compiling the changed file used by test I get Missing character: There is no ☞ (U+261E) in font "FreeSans:mode=node;script=l This was because of error in test-suite. In contrast to what I said that the font would be replaced only if set to default, it was replaced unconditionally. Works now. I will wait for your commit before committing the correction. > > and also > > 579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 > > (Failed) > > 580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF > > (Failed) > > 581 - > > SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed) > > This was a mistake in the pattern, I'll upload a fix soon. > > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: why Babel with dvi3 (LuTeX)?
Dear Kornel, thank you for the quick test report. On 2016-01-09, Kornel Benko wrote: > After the last commit, this tests fail: > 1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed) > 1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed) > 1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed) They work here. Can you establish the cause for failure and eventually add a patter to unreliable? > and also > 579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 > (Failed) > 580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF > (Failed) > 581 - > SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed) This was a mistake in the pattern, I'll upload a fix soon. Günter
Re: Status on Mac with El Capitan
Am Samstag, 9. Januar 2016 um 14:27:46, schrieb Stephan Witt > Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > > > Le 08/01/2016 10:08, Stephan Witt a écrit : > >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : > >>> Yes, unless somone has a different brilliant idea. > >> > >> Am I right that it makes explicit what is otherwise implicit? So it is > >> safe to commit? > > > > Yes, I think so. The question is only maintainability. Guillaume complained > > that the is fragile because new code can forget to add this explicit lyx::. > > Scott, > > I’d like to commit the patch (attached again). Is this ok? It applies cleanly, compiles on linux. First tests are OK. > Stephan Kornel > > > >>> The problem is that libc++ provides std::next even when not in C++11 mode. > >> > >> Is the implementation of std::next compatible to the e.g. > >> ParagraphList::iterator or not? > > > > It should. The problem is only that we provide boost::next when not in > > C++11 mode, but clang already provides the real std::next. > > > > The proper fix would be to check at configure time whether std::next exists > > and react on that. But it is extra work :) > > > >>> This problem will go away in 2.3. > >> > >> How? With your fix? Does it fix wrong LyX code or is it some work around? > > > > Because support for c++98 will go away, together with many of our lyx:: > > wrappers. > > > > Georg, do you have a thought on that? signature.asc Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes : > > Le 08/01/2016 10:08, Stephan Witt a écrit : >> Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes : >>> Yes, unless somone has a different brilliant idea. >> >> Am I right that it makes explicit what is otherwise implicit? So it is safe >> to commit? > > Yes, I think so. The question is only maintainability. Guillaume complained > that the is fragile because new code can forget to add this explicit lyx::. Scott, I’d like to commit the patch (attached again). Is this ok? Stephan > >>> The problem is that libc++ provides std::next even when not in C++11 mode. >> >> Is the implementation of std::next compatible to the e.g. >> ParagraphList::iterator or not? > > It should. The problem is only that we provide boost::next when not in C++11 > mode, but clang already provides the real std::next. > > The proper fix would be to check at configure time whether std::next exists > and react on that. But it is extra work :) > >>> This problem will go away in 2.3. >> >> How? With your fix? Does it fix wrong LyX code or is it some work around? > > Because support for c++98 will go away, together with many of our lyx:: > wrappers. > > Georg, do you have a thought on that? lyx-iter-next-prev.patch Description: Binary data
Re: Status on Mac with El Capitan
Am 08.01.2016 um 10:26 schrieb Jean-Marc Lasgouttes :Le 08/01/2016 10:08, Stephan Witt a écrit :Am 08.01.2016 um 09:28 schrieb Jean-Marc Lasgouttes :Yes, unless somone has a different brilliant idea.Am I right that it makes explicit what is otherwise implicit? So it is safe to commit?Yes, I think so. The question is only maintainability. Guillaume complained that the is fragile because new code can forget to add this explicit lyx::.Scott,I’d like to commit the patch (attached again). Is this ok?StephanThe problem is that libc++ provides std::next even when not in C++11 mode.Is the implementation of std::next compatible to the e.g. ParagraphList::iterator or not?It should. The problem is only that we provide boost::next when not in C++11 mode, but clang already provides the real std::next.The proper fix would be to check at configure time whether std::next exists and react on that. But it is extra work :)This problem will go away in 2.3.How? With your fix? Does it fix wrong LyX code or is it some work around?Because support for c++98 will go away, together with many of our lyx:: wrappers.Georg, do you have a thought on that? lyx-iter-next-prev.patch Description: Binary data
Re: Status on Mac with El Capitan
Am 09.01.2016 um 13:12 schrieb Stephan Witt: Am 08.01.2016 um 13:15 schrieb Kornel Benko : Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt Am 08.01.2016 um 11:53 schrieb Kornel Benko : Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt OR (maybe) include_directories((BEFORE ${TOP_SRC_DIR}/src/tex2lyx ${TOP_SRC_DIR}/src/support/minizip) include_directories(${ZLIB_INCLUDE_DIR}) Yes, this works too. BTW, what is "src/support/minizip“ for? It doesn’t exist in the master checkout. Why should "src/tex2lyx“ come before other includes? Stephan I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“. Yes, but what’s the gain of having "src/tex2lyx“ before other includes? Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing it. Peter, is the attached patch ok? Removing the minizip should make no problems. Stephan I wanted to change as little as possible. The removal of the BEFORE keyword did the job too. Sure.
Re: why Babel with dvi3 (LuTeX)?
Am Freitag, 8. Januar 2016 um 21:47:21, schrieb Guenter Milde > On 2016-01-08, Scott Kostyshak wrote: > > On Fri, Jan 08, 2016 at 06:31:37AM +, Guenter Milde wrote: > >> On 2016-01-08, Scott Kostyshak wrote: > > > Here is the diff: > > > $ diff ctests_d7ff8c6e/LastTestsFailed.log > > ctests_d7ff8c6e_with_patch/LastTestsFailed.log > > 0a1,2 > > > 218:AUTOTESTS_export/export/TableErrorIfSlovakTextInserted_dvi3_texF > > > > > 219:INVERTED.AUTOTESTS.MULTILINGUAL_export/export/TableErrorIfSlovakTextInserted_dvi3_systemF > > A typo in the filter pattern. > > > > 3718:UNRELIABLE.NONSTANDARD_export/templates/kluwer_dvi3_systemF > > This is tagged "unreliable" because it is known to fail st at some places or > sometimes. > > Summary: There is no real regression due to the changes introduced by the > patch. All changes in test results highlighted existing problems with either > polyglossia or babel. > > My suggestion is to commit the patch and do test filter adaption in a > cleanup. > > There is a tailback of patches fixing other issues now because of this one > and I am running out of time. > > Günter After the last commit, this tests fail: 1770 - EXAMPLES_export/examples/linguistics_dvi3_systemF (Failed) 1775 - EXAMPLES_export/examples/linguistics_pdf4_systemF (Failed) 1777 - EXAMPLES_export/examples/linguistics_pdf5_systemF (Failed) and also 579 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf3 (Failed) 580 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_texF (Failed) 581 - SUSPENDED.MANUALS.ATTIC_export/doc/attic/eu_UserGuide_pdf4_systemF (Failed) Kornel signature.asc Description: This is a digitally signed message part.
Re: Status on Mac with El Capitan
Am 08.01.2016 um 13:15 schrieb Kornel Benko : > > Am Freitag, 8. Januar 2016 um 13:09:38, schrieb Stephan Witt >> Am 08.01.2016 um 11:53 schrieb Kornel Benko : >>> >>> Am Freitag, 8. Januar 2016 um 09:10:00, schrieb Stephan Witt >>> > OR (maybe) > include_directories((BEFORE > ${TOP_SRC_DIR}/src/tex2lyx > ${TOP_SRC_DIR}/src/support/minizip) > include_directories(${ZLIB_INCLUDE_DIR}) Yes, this works too. BTW, what is "src/support/minizip“ for? It doesn’t exist in the master checkout. Why should "src/tex2lyx“ come before other includes? Stephan >>> >>> I suspected that ${ZLIB_INCLUDE_DIR} includes "/opt/local/include“. >> >> Yes, but what’s the gain of having "src/tex2lyx“ before other includes? > > Don't know. Not my doing, ask Peter. I suspected, he had a reason introducing > it. Peter, is the attached patch ok? Stephan > I wanted to change as little as possible. > >> The removal of the BEFORE keyword did the job too. > > Sure. tex2lyx-cmake.patch Description: Binary data
Re: Questions for Uwe?
Am 09.01.2016 um 01:32 schrieb Scott Kostyshak: On Mon, Jan 04, 2016 at 10:58:13AM -0500, Scott Kostyshak wrote: On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote: On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote: Scott Kostyshak wrote: I don't understand how installers work for 32-bit vs 64-bit. Normally does our Windows installer contain both 32-bit and 64-bit binaries? Or we just release 32-bit and 64-bit systems are fine with it? Same for Mac? So far we have never released any 64bit windows binary. This is fine, since 64bit windows can execute 32bit binaries, and nobody complained yet about LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not switch to 64bit at this time, since this can introduce subtle bugs (unfortunately the 64 C++ memory model differs on linux and windows, e.g. long is 64bit on linux but 32bit on windows, so the fact that we have working 64bit linux builds does not guarantee us working windows 64bit builds). I see. Thanks for the explanation. I agree we should not switch now. Scott Another question for Uwe. Can you still reproduce these two tickets? http://www.lyx.org/trac/ticket/9892 http://www.lyx.org/trac/ticket/9900 That is part of the reason why I am curious about Qt 5.6.0beta1. Maybe it makes those issues go away. Scott I have gone through this thread and tried to make a summary of the questions and discussion for Uwe. Please add more questions if you have any or edit my misinterpretation of the question/comment. The following letters refer to the person that asked the question. G=Georg R=Richard S=Scott S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1 and 5.6.0beta1? There will be no downloadable msvc2010 builds for 5.6. ATM only 5.5.1: http://www.qt.io/download-open-source/#section-2 S2. Can you make the installers from *only* the tar ball (and not use the git directory at all)? Note that if there is a technical reason why this is difficult if you ask on the list I am guessing someone can help. S3. Richard has been committing updates to po files. Can you confirm that all translation updates we have received have been merged? Has anyone emailed updates to you privately? R4. Do we also want to try releasing an installer built with mingw? (G response: IMO, we only need to release one installer. The mingw and MSVC builds behave exactly the same (modulo bugs). So the question is rather whether we do trust MSVC or mingw, and who does the build: If it is Uwe, it will be MSVC, otherwise it will probably be mingw. G5. Not a question but a prerequisite IMHO: The 2.2.0 release should also build the prerequisite from the sources Peter added, using exactly the same compiler as is used to build LyX. If Uwe tries to build the installer with the mingw build from the build bot, and it makes no problems, then a mingw based installer isn't far away. S6. Can you still reproduce these two tickets? http://www.lyx.org/trac/ticket/9892 http://www.lyx.org/trac/ticket/9900 If so, do you think they are beta blockers? That is part of the reason why I am curious about Qt 5.6.0beta1 (see question S1). Maybe it makes those issues go away somehow. Scott