Exception (basic_string) when saving on OSX.
I've been experiencing several exceptions on OSX, using commit 96f64ac0. Sofar I've tracked down one of them: A (basic_string) exception occurs when saving a document with a sufficient long filename (more than about 18 characters without the extension). Take any .lyx file and add characters to the name. Then open and save it. As far as I can see this has been introduced with commit bb34445, which contains many changes, including some of the filetools. Regards, P. De Visschere
Re: Change tracking output issues
On Tue, Oct 20, 2015 at 10:03:27PM +, Paul A. Rubin wrote: > > I did not test (I assume I get the same result as Kornel since I have a > > similar system), but I suppose the next step is to send the .tex files. > > e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex). I do indeed have the same result as Kornel. > Scott: I exported both pdflatex and "plain" versions, and just for grins I > compiled the plain version in a shell. The DVI file contains no markup. > Comparing the two .tex files, all differences are in the header; the bodies > are identical. I've zipped up both .tex files and the .aux, .dvi and .log > files from the "plain" version here: > https://www.dropbox.com/s/xgv720xpzyt8hh2/change%20tracking%202.zip?dl=0. I think you do actually have dvipost. Your log file suggests that it is here: /home/paul/texmf/tex/latex/dvipost/dvipost.sty I wonder if this could be the critical difference between your setup and Kornel's/mine. If you are curious enough to take the risk of tweaking your system, you could try uninstalling dvipost and reconfiguring LyX and trying again. If it works for you after, then this might be a LyX bug. > Regarding XeTeX, it's installed, and I have the option to export to "LaTeX > (XeTeX)", but there's no option in Document > View (Other Formats) that > mentions XeTeX. I find this strange. I did not do anything special to set it up. I would be *slightly* worried that something is off for your LaTeX installation (note though that I know little about LaTeX installations). XeTeX is somewhat mature so it should be in TL 2013. On the command line can you run xelatex --version Scott
Re: LyX 2.2 OSX 10.11 - retina display test
On Wed, Oct 21, 2015 at 12:21:11AM +0200, "Mag. Georg Kö" wrote: > Dear all, > > let me start let me start by saying kudos to all of you! I is really > fantastic what Lyx provides especially as an application for scholars around > the world. As I quit doing development several years ago I won’t be any help > in this regard. Would be more than willing though to contribute by reporting > issues or help with translation stuff (German, Dutch and a little bit French > …). I’m working on a MBP Retina 13“ 2015 with 10.11 (15A282a). If I can be of > any help, just drop me a note, if not, thanks a bunch for the fab work and > good luck for the next release. Hi Georg K (there is another Georg active on the list so I will use your last initial just to make things easier. If you have a nickname or prefer to be referred to differently, let us know), You came along at an exciting time! We are just starting the release process for the next major LyX version, 2.2.0. You can see a list of the new features here: http://wiki.lyx.org/LyX.NewInLyX22 2.2.0 Alpha will be released soon. If you would like, testers are always useful. I could email you directly if you want to be notified of the alpha release. Well-written bug reports and enhancements are in my opinion the best way to contribute to open source. You can register at http://www.lyx.org/trac and start giving us feedback there for specific topics. Or drop us an email at lyx-devel if a certain piece of feedback or question doesn't fall under the bug/enhancement category. You might also be interested in hanging out on the lyx-users list, which has a good frequency I think. Depends on what you're looking for though. As for translations, our German and French are in pretty good condition I think, but our Dutch translation seems to be a bit neglected, as you can see here: http://www.lyx.org/I18n-trunk Translation work can be difficult, frustrating, and time-consuming in my opinion. But it is also one of the most important jobs as it brings LyX to more users and in their native language. If you think you're up for the challenge and would find it fun, let us know and someone who knows more about translations than I do can walk you through the beginning steps so you can get started. Welcome and thanks for the email! Scott
Re: LyX 2.2 testing OS X 10.11 / retina display
On Tue, Oct 20, 2015 at 02:43:39PM -0400, Ian Weiner wrote: > Hi, > > This is in response to a post by Scott Kosty on latex-community.org. > > I'd be interested in testing out an OS X build of LyX 2.2 when it's reached > the appropriate development stage. Drop me a line with more info when the > time comes. Great, I'll add you to the list of testers I have. Our alpha should be out soon. Be careful to back everything up, expect it to crash, and to not do serious work on it. Scott
Re: Moving towards a 2.2 release
On Tue, Oct 20, 2015 at 05:27:29PM +, Guenter Milde wrote: > On 2015-10-20, Scott Kostyshak wrote: > > On Mon, Oct 19, 2015 at 08:18:30PM +, Guenter Milde wrote: > > >> I realised that this not only applies to compilation with Xe/LuaTeX which > >> is a good thing -- it also catches cases like small letters missing in > >> most math-script fonts (To fix the description in lib/RELEASE-NOTES, just > >> trim the sentence.) > > > I made the change (although you are most welcome to edit the > > RELEASE-NOTES). > > It is the same change that I did here locally, thanks. OK good. > > Actually the tests are not that sophisticated. They just check whether > > the compilation runs without error (ie it checks the exit code from > > command-line export) > > Except for the tex2lyx tests. Yes true. > There are some more "easyfix" patches in the pipeline: > > #9770 unicodesymbols replacements for wasysym text symbols OK. > and a symbols-invdiameter.patch: > > diff --git a/lib/symbols b/lib/symbols > index 89fc41a..992f556 100644 > --- a/lib/symbols > +++ b/lib/symbols > @@ -695,8 +695,7 @@ hexstarwasy 65 0 x✶ > varhexstar wasy 66 0 x✶ > davidsstar wasy 67 0 x✡ > diameter wasy 31 0 x⌀ > -# Unicode is wrong, but a true alternate doesn't seem available. > -invdiameterwasy 21 0 x⌀ > +invdiameterwasy 21 0 x⍉ > varangle wasy 30 0 x∢ > wasylozengewasy 53 0 x⌑ > kreuz wasy 54 0 x✠ > > > Commit? Yes please.
Re: Translations and 2.2.alpha?
On Mon, Oct 19, 2015 at 07:30:07PM +0200, Jean-Marc Lasgouttes wrote: > Le 19/10/2015 19:14, Scott Kostyshak a écrit : > >Well we can adjust the timeframe if necessary (it is already delayed > >because of Qt 5.6 beta delay). If this is important or there is > >precedence then we can delay a couple of weeks. > > I would say it is only important before beta. OK, my plan is the following: - 3 weeks before the planned beta, send an email to Uwe to see if he has time to copy the translations from 2.1.x to master as he has done for previous major releases - After Uwe is done with that (or if he doesn't have time), send an email to lyx-docs and to the translators directly asking them to prepare translations. And then I will do the above for each subsequent beta (if necessary) and release candidate (perhaps not as long as 3 weeks before because they probably need less time because they already hopefully translated everything for the first beta). Does that seem reasonable? How do I email the translators directly? Do we have a script to pull the emails of the current translators from the po files? Scott
Re: Regression in lyx2lyx box alignment
On 10/20/2015 04:07 PM, Georg Baum wrote: ...I mainly use git for LyX development like "svn + stash", and keep two separate working trees for branch and master. I do the same, just because compiling is faster this way (and disk space is cheap). Many git features are confusing for me as well, and I always have the impression that the defaults are wrong (e.g. I always use git cherry-pick -n). Fortunately all this is configurable, It's particularly configurable via aliases. My own preference is for the options -e and -x, hence I have as a git alias: cp = cherry-pick -e -x In memory of svn: ci = commit -a One can do almost anything with aliases. But, more importantly: so if you find out a workflow once you can write it down and do not need to understand the details anymore for using it in the future. This is the important thing, and it could even be put on the wiki. Richard
LyX 2.2 OSX 10.11 - retina display test
Dear all, let me start let me start by saying kudos to all of you! I is really fantastic what Lyx provides especially as an application for scholars around the world. As I quit doing development several years ago I won’t be any help in this regard. Would be more than willing though to contribute by reporting issues or help with translation stuff (German, Dutch and a little bit French …). I’m working on a MBP Retina 13“ 2015 with 10.11 (15A282a). If I can be of any help, just drop me a note, if not, thanks a bunch for the fab work and good luck for the next release. Cheers, G.
Re: Change tracking output issues
Scott Kostyshak lyx.org> writes: > > On Tue, Oct 20, 2015 at 06:15:13PM +0200, Kornel Benko wrote: > > > > I tried your example, all available pdf formats are displaying the change here. > > (E.g. > > PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX) > > ) > > > > Exporting to dvi with 'DVI (LuaTex)' is wrong, but export to 'DVI' is OK. > > > > This is with TL2015 and lyx 2.2dev Kornel: Thanks for testing this. I'm using TL2013 and LyX 2.1.4. I wonder if either of the version differences could be the culprit? > > I did not test (I assume I get the same result as Kornel since I have a > similar system), but I suppose the next step is to send the .tex files. > e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex). > Scott: I exported both pdflatex and "plain" versions, and just for grins I compiled the plain version in a shell. The DVI file contains no markup. Comparing the two .tex files, all differences are in the header; the bodies are identical. I've zipped up both .tex files and the .aux, .dvi and .log files from the "plain" version here: https://www.dropbox.com/s/xgv720xpzyt8hh2/change%20tracking%202.zip?dl=0. Regarding XeTeX, it's installed, and I have the option to export to "LaTeX (XeTeX)", but there's no option in Document > View (Other Formats) that mentions XeTeX. Thanks for the attention. Paul
Re: Regression in lyx2lyx box alignment
Am 20.10.2015 um 04:39 schrieb Scott Kostyshak: I CC'ed you on the following emails (it hides that I CC'ed you but if you search for the message in your email client it should show it): Hm, now I see them. There were automatically moved into the spam folder where also all the commit report mails are placed. This is strange but it is then no wonder that I overlooked them. (I cannot not follow all commits.) And you responded to one here: https://www.mail-archive.com/search?l=mid&q=55872177.2040708%40web.de This was months ago and the stress is still the same. it sucks that I cannot plan much. E.g I was just informed that I have to work abroad again. And again I can most probably not do anything for LyX the next days... Which email address is best? uwestoehr-at-web.de or uwestoehr-at-lyx.org ? I tried both. Both should work. I don't understand how it is useful. Why can't use you use the paragraph alignment? Please respond to Georg's email on this matter. Since I have to get up in 5 hours and will be off then, I CCed him. Georg, attached are 2 documents, one created with LyX 2.1. where I used the paragraph settings to center, one created with LyX 2.2. You see the difference: The Paragraph-alignment added a paragraph of course leading to whitespace one doesn't want in boxes. That's why I implemented the alignment in LyX 2.2. as non-paragraph via \raggedleft etc because a parbox or minibox is already its own paragraph. I feel a lot of aggression against me in todays' posts. I see what you mean, but I would say if anything there is aggression towards your *work flow*. LyX developers are a team and we want to be on the same page as much as possible. Everyone will work differently and that is fine, but when those differences affect other people that is when frustration happens. Just to take the recent example of the tex2lyx tests failing. Because of your commit, I spent time tracking down the problem, Kornel spent time running the tests and reporting the failure, Georg spent time confirming your commit was the issue, Guillaume spent time trying to fix the issue, and Gűnter had finally fixed the tests that he broke but there was confusion because at the same time you broke the tests so it wasn't clear whether it was his commit or your commit. I see. Any you are totally right that it is not OK to steal time from others knowing what a high value time is. Nevertheless one must discuss how useful the tests are if they make so many troubled what anybody just changed a layout file without touching tex2lyx. I still think that the main purpose of the tex2lyx tests should be to test tex2lyx capabilities. The point is that every new rule increases the barrier to attract new developer and to hold developers active. In my case I knew I would have maximal 2 days not knowing when I will be able to LyX again. And I of course knew that the first LyX 2.2 cannot be far away and then a fileformat change for simple things like layout changes are then no longer possible. So sometimes just putting things in is sensible. (I know Georg hates me for statements like that.) However, now I have the situation I feared but my feature is in and there is time to fix possible issues in the alpha/beta cycle. I don't see the big problems despite that I stole your time with the tex2lyx test issue. I know that I am very controversial and that I sometimes just can't resist. The good point is that It made so much fun that I wanted to re-join the development despite I know that it will be a hard task with the real-life stress. So finally apologies to Georg, Guillaume, Kornel and Günter that you need to spend time for tex2lyx. I hope we will find a solution soon that I can do things right also on Windows too. regards Uwe Box21.lyx Description: application/lyx Box22.lyx Description: application/lyx
Re: When to court Qt 5.6?
Op 15 okt. 2015 08:37 schreef "Jean-Marc Lasgouttes" : > > Le 15/10/15 01:06, Scott Kostyshak a écrit : > >> LyX 2.2.0 and the following 2.2.x releases will still continue to work >> well with Qt 4.8.6 but will also support Qt 5.6, which brings some >> advantages most notably for users with HiDPI displays. Note that if you >> compile LyX with a Qt 5 release before 5.6 you are likely to run into >> several regressions with respect to Qt 4.8.6. See #9215 for a list of >> bugs related to compiling LyX with different versions of Qt. > > > The minimum Qt version is actually 4.5, although I do not know who is able to check that. I could try to test it in a virtual machine, though. > > JMarc > I use Qt 4.8.? but I have problems with the code to read icons. I cannot read svgz pixmaps, and GuiApplication::iconName only looks whether a file exists but does not take into account whether a certain file is readable. I want to fix this soon. Vincent
Re: When to court Qt 5.6?
Op 20 okt. 2015 20:35 schreef "Georg Baum" : > > Uwe Stöhr wrote: > > > Besides this I am still using MSVC 2010. I need to update to MSVC 2012 > > or newer and this is another challenge. I already tested MSVC 2012 with > > Qt 5.5 with success. Let's see what Qt 5.6 supports and if I can then > > still compile LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC. > > I would suggest to use the newest stable version, with is currently MSVC > 2015. Then you need to update and adjust to changes look and feel less > often. > > In general, installing two MSVC versions in parallel is no problem, the same > is true for qt. The only thing you need to make sure is that none of these > versions is listed in the PATH or other environment variables. Then you can > use two build.bat files for the two versions, and set all needed environment > variables (e.g. adding the qt bin dir to PATH for moc etc) separate in these > two files. > > Furthermore, a new MSVC version requires a new dependency package. As I > already wrote to David Hyde (who wants to compile LyX with a newer MSVC), I > think that the current procedure of providing the binaries for a sepcific > MSVC version produces too much work in the long run. Instead, a python or > cmake script to download the sources of the dependencies and compile them > should be written. This is more effort initially, but pays off in the long > term, and also removes some pressure from you, since others can then create > the dependencies they need without manual work for you. > > > Georg > First, it looks like that the 2010 libraries can work with at least MSVC 2012. Is that because MSVC 2010 is or was also installed on the same machine? If so, releasing such a hybrid might give troubles that won't be foreseen. So, better to warn Uwe as he claims to have tested with MSVC 2012 and Qt 5.5. Second, I guess it's up to me to figure out compiling the dependencies. I remember that Joost had manually changed gettext to be able to make suitable libraries. Did we get rid of gettext libs completely or do we still need it (besides the msgmerge and friends applications) ? It's a good idea to update cmake to download the sources. Vincent
Re: When to court Qt 5.6?
Op 20 okt. 2015 02:32 schreef "Uwe Stöhr" : > > Am 15.10.2015 um 01:18 schrieb Scott Kostyshak: > >> Uwe can you confirm that shipping our alpha with Qt 5.6 beta is >> feasible for you? > > > Hi Scott, > > I am open for anything. I think that i will need in any case some help from Vincent - in the past some Win-only changes were required to be able to compile with new Qt versions. > > Besides this I am still using MSVC 2010. I need to update to MSVC 2012 or newer and this is another challenge. I already tested MSVC 2012 with Qt 5.5 with success. Let's see what Qt 5.6 supports and if I can then still compile LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC. > > regards Uwe Why do you need to update to MSVC 2012 ? Qt 5.5 was still released with 2010 libraries. Given the fact that some of our dependencies are also built with 2010, it looks safest not to switch versions right now. Vincent
Re: back to LyX and therefore questions concerning LyX 2.2
Am 19.10.2015 um 16:42 schrieb Jean-Marc Lasgouttes: Welcome back! Thanks JMarc for the info. PS: and of course my idea of replacing ugly tables with nice formal tables and remove all the spacing hacks you had to do is still waiting for your answer ;) What do you mean? Apparently I missed your mail too. regards Uwe
Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
On 2015-10-20, Scott Kostyshak wrote:
> On Tue, Oct 20, 2015 at 07:16:44PM +0200, Günter Milde wrote:
>> commit 1523fc6023440f10ca0d82a681ded5c060d8fd33
>> Author: Günter Milde
>> Date: Tue Oct 20 19:14:39 2015 +0200
>> Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
>> Fixes output for 3 of the 4 test lyx-files.
>> Includes "FIXME"s at places where further action is required to get the
>> XeTeX
>> export right but I don't know how.
>> ...
>> +&&!runparams.isFullUnicode()) { // FIXME: check must be done for
>> useNonTeXFonts!
>> os << "\\inputencoding{utf8}\n"
>> << setEncoding("UTF-8");
> So to make sure I understand what you want with this FIXME is you would
> like to do something like params().useNonTeXFonts as you do in
> Buffer.cpp but in PDFOptions.cpp it's not clear how to access that?
It may also be that I misunderstand what is done there, but basically, yes:
I believe that the test at these places must be for "useNonTeXFonts" instead
of "isFullUnicode", because XeTeX/LuaTeX with TeX fonts behave more similar
to 8-bit TeX regarding the in- and output encodings.
Günter
Re: Regression in lyx2lyx box alignment
Uwe Stöhr wrote: > ( I see now in mail-archive.com this thread. It would have been nice to > send me at least a direct mail to assure that I am informed. In the past > I could read the list via NNTP but my ISP dropped that feature. When I > am abroad I don't read mail-archive.com .) Do you mean that your ISP does not provide an NNTP server anymore, or that it actively blocks the NNTP ports? The former would not be any problem (just use news.gmane.org, which I am doing btw as well). The latter would be a strange ISP. > It would be nice if you give me the chance to fix this in lyx2lyx > instead of removing the feature. I already did that for you: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg189325.html However, I still think that the paragraph alignment can be used instead, and would like to have an explanation what is wrong with the paragraph version. If the box alignment is kept, then we need a considerable amount of work to finish it (see the other messages in this thread), and the question is who would do that. > I feel a lot of aggression against me in todays' posts. Maybe it was > wrong to do again something for LyX. LyX is no longer the project I > liked. There are now many rules making it hard for people like me, who > don't program in their job, to follow. IIRC the rules in the past were more strict. Anybody remembering the old changelogs which had much more detailed descriptions of the changes, and the requirement to send all patches to the list first? The only exception is the rule about the tex2lyx tests, but it has already proven to be very useful, because the tests have already detected many bugs which would have gone unnoticed for a long time otherwise. The last such case was the wrong symbol for 0x0320 in lib/unicodesymbols, which was detected after a recent addition by Günter because a) you created a test case with this symbol a long time ago and b) we require that the tests do always pass. The other rules listed in Development.lyx have basically always been there, but never explicitly documented. > I see that I won't be able to > follow LyX's development in future since even Git is too hard for me to > handle. I never need a console in my life or work and therefore cannot > remember all these commands. (E.g. I spent 2 hours to get cherry-picking > to work before I gave up. - Some months ago I could use this feature but > forgot it.) For those who use a commit system daily it is not easy to > understand. You are not the only one who has trouble using git: https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg187328.html For example, I mainly use git for LyX development like "svn + stash", and keep two separate working trees for branch and master. I would recommend a similar worflow for you as well, this would also avoid rebasing problems as those which were fixed with 741e5267131. Many git features are confusing for me as well, and I always have the impression that the defaults are wrong (e.g. I always use git cherry-pick -n). Fortunately all this is configurable, so if you find out a workflow once you can write it down and do not need to understand the details anymore for using it in the future. > The idea was to document everything to make it possible for people like > me to follow the development but obviously I am still the only Win > developer so that the LyX coding docs only reflect how it works on Unix. > Since my coding abilities are very limited I fear I will sooner or later > loose track how to compile LyX - which will then also be the end of a > Windows installer release. It all depends on you. Many people are willing to help (me included). If you don't know how to do something, please ask, and we will find a solution. I do however expect that once a solution has been found, you will remember it (by whatever method that works for you) and not ask the same question again. I also expect all developers to learn from mistakes. It is no problem if something goes wrong, but if the reasons for a mistake have been identified, then I expect that they will be avoided in the future. > Sorry for changing the topic. If I am nevertheless welcome you should > know that I will also in future be off completely for weeks (I hope no > longer for months). In these periods I tried at least to keep the > installer running. We all have times when real life interferes for a shorter or longer period. Sometimes there are also emergencies, so somebody needs to stop all work completely for an unforseeable amount of time. IMHO the LyX developers can cope well with such cases, and nobody needs to justify if he needs to stop. However, if such a period ends, and there is time again for LyX development, then I expect that no new fun stuff is started until all leftover stuff from previous work is addressed. It is important that there is some balance between developers for fun and non-fun work, otherwise those who do most of the non-fun stuff will s
Re: Many tex2lyx failing now on master
Am Dienstag, 20. Oktober 2015 um 20:18:33, schrieb Georg Baum > Guenter Milde wrote: > > > On 2015-10-19, Uwe Stöhr wrote: > > > >> I don't understand what I made wrong. I only changed something in a > >> module and added a fileformat change for lyx2lyx. I did not change any > >> tex2lxy test file nor did I change tex2lyx code. > > It is all documented in Development.lyx. > > >> I also followed lib/doc/Development.lyx sec. 2.3. This references sec. > >> 3.2.2 and I tried that too, but this is not possible on my PC: > > If a procedure that is documented to be required for certain changes does > not work, then I would expect every developer to ask on the list for help > _before submitting_ instead of ignoring the issue. > > > If the hint that a fileformat change requires adapting the test examples > > is missing there, this is a documentation bug. > > The hint is there, in section 2.3. > > > In addition, adding the "change the fileformat numer for tests" > > requirement to Development.lyx would help prevent others to fall in this > > trap and frustration by others frentically trying to get the tests in > > shape before a release. > > It is already in. The only thing which is indeed missing is a description > how running the tests and updating the test references works with MSVC. > Unfortunately I don't know that, otherwise I would have documented it. > Vincent, maybe you can find that out? This is easy, because it is not platform specific. The command 'ctest' comes together with cmake, so everyone using cmake has it too. > If you think that anything else is missing in the documentation of file > format changes or concerning the tex2lyx tests, then please tell what you'd > expect, and we can improve the docs. > > > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: Form is function
On Tue, Oct 20, 2015 at 8:52 PM, Scott Kostyshak wrote:
> On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote:
>> Scott asked not long ago what could be done to make it easier for
>> newcomers. It is now clear to me that having a clearer bug tracker
>> is an aspect that can be improved. In addition, the initial question
>> was to know what to do with tickets with an unmet milestone.
>>
>>
>> Taking into account what has been said, here are three proposition:
>>
>>
>> 1. Milestones remain the main recipient of triaging information
>> + Unmet milestones are reverted to ".x", which are given more
>> visibility.
>> + Severity is the secondary information used to order the lists.
>> + Color is supposed to distinguish enhancements from defects, though
>> it is not really observed currently (indeed this colour code was
>> kept secret!).
>> - As I see it, it leads to an information which is fragmented between
>> three different milestones, which is maybe why it did not work in
>> the past.
>>
>>
>> or:
>>
>>
>> 2. Priority (colour) becomes the main recipient of the triaging
>>information.
>>+ A list of all "important" defects regardless of milestone is
>> given visbility in addition to what we have already.
>>+ "Important" enhancement are shown as well in a list separate from
>> the previous one; the colour do not means the same for
>> enhancements and defects.
>>+ An unmet milestone can be removed safely: bump the priority if
>> necessary.
>>- While colouring is attractive, it is against pre-existing
>> conventions. The colour code should be similar for defects
>> (yellow/red) but would differ for enhancements (essentially all
>> light blue enhancements would become untriaged).
>>- Also, severity was already used to rate tickets on a scale.
>>
>>
>> or a new proposition:
>>
>>
>> 3. Severity becomes the main recipient of the triaging information.
>> + A list of all important defects regardless of milestone
>> (major/critical/blocker) is given the visibility.
>> + A list of all consensual enhancements regardless of milestone is
>> found at the end of the front page (e.g. major/critical).
>> + An unmet milestone can be removed safely; bump the severity if
>> necessary.
>> + Does not invalidate the color convention which we can explain
>> separately, and is consistent with the previous use of severity.
>
> From what I understand there has been no preference expressed by anyone
> besides Guillaume on this. Does anyone else prefer one of the three
> options (or a different one)? Liviu since you have been involved earlier
> in the discussion, can you summarize your opinion with respect to the
> propositions Guillaume outlined (or a new proposition) ?
>
I think #1 is more or less what we have now, slightly simplifying the
way we roll milestones (into the .x stack) or drop milestones
altogether ("very" old .x reports can be safely decommissioned).
#2 will allow to much better keep track of "important" tickets, across
major releases, but it will also require some change in bugtracker
habits as well as more or less constant supervision (at least at
first). It will require from devels a conscious triaging effort to
assess importance, but it will allow to not forget important issues or
missing features even when they're very old.
#3 seems to be like the above while keeping our current color
conventions on bugtracker.
In truth, I have only but a small voice in this. Best would be for our
release managers and active developers to signal which scheme they
would be most comfortable with. And as Pavel has already mentioned,
the crucial part for either of Guillaume's proposals---since they
involve more departure from what we are currently doing---would be for
him to become actively involved in the triaging efforts on Bugtracker
for "some" time, so that the new habits stick with the old-timers;
otherwise devels will probably simply revert to what they've been used
to before.
If Guillaume does assume this role, I think either of the proposed
schemes could work just nicely, and maybe we really do need a more
sensible and nuanced way to prioritize the importance of incoming
reports and keep track of them across major releases (as long as it is
indeed the devel team that decides on the priorities, not the
reporters)... And since Guillaume is clearly motivated, I think a
change in bugtracker practices could ultimately prove a positive a
change for the team in terms of moving the project forward.
Regards,
Liviu
> Guillaume (and others), I would like to go through the bugs with
> milestone 2.2 soon. My only goal will be to figure out which tickets
> should keep 2.2 as a milestone and which should not. I'll make some
> decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on
> thinking carefully about the severity or importance. I will assume that
> anyone who cares about the particular ticket wi
Re: LyX's master is now uncompilable
Op 20-10-2015 om 20:06 schreef Georg Baum: Guillaume Munch wrote: I'll let Vincent decide whether he wants to make this change. Sure, our messages crossed each other, I would not have suggested that if I knew that he had time to test. The compilation error could btw easily be fixed by moving the implementation of the methods in a .cpp file (I would suggest to use src/support/docstream.cpp where id is already implemented, since adding a new .cpp would not be trivial: It would not need to be compiled on unix for example). Ok, that's what I did. Vincent
Re: Regression in lyx2lyx box alignment
Scott Kostyshak wrote: > After rereading the below email I just realized I often use the term > "we" and "us". Sorry about that. I do not mean to pretend like I am > speaking on behalf of everyone (I do not forget that I am a relative > newcommer here!). Instead of taking the time to correct all the "we" and > "us" I am just issuing this apology in advance. As far as I am concerned, the "we" is fine. I could not have expressed the reasons for my frustration in a better way. > You are very valuable to the development of LyX, Uwe. I don't think > there is any doubt about that. Without you, I sincerely think LyX would > suffer in many dimensions. I hope that development of LyX will become > fun again for you as I think it once was. Let me know if there's > anything I can do to help with that. Let me second that. I would not want to loose you. Georg
Re: Form is function
On Wed, Oct 14, 2015 at 07:50:54AM +0100, Guillaume Munch wrote: > Scott asked not long ago what could be done to make it easier for > newcomers. It is now clear to me that having a clearer bug tracker > is an aspect that can be improved. In addition, the initial question > was to know what to do with tickets with an unmet milestone. > > > Taking into account what has been said, here are three proposition: > > > 1. Milestones remain the main recipient of triaging information > + Unmet milestones are reverted to ".x", which are given more > visibility. > + Severity is the secondary information used to order the lists. > + Color is supposed to distinguish enhancements from defects, though > it is not really observed currently (indeed this colour code was > kept secret!). > - As I see it, it leads to an information which is fragmented between > three different milestones, which is maybe why it did not work in > the past. > > > or: > > > 2. Priority (colour) becomes the main recipient of the triaging >information. >+ A list of all "important" defects regardless of milestone is > given visbility in addition to what we have already. >+ "Important" enhancement are shown as well in a list separate from > the previous one; the colour do not means the same for > enhancements and defects. >+ An unmet milestone can be removed safely: bump the priority if > necessary. >- While colouring is attractive, it is against pre-existing > conventions. The colour code should be similar for defects > (yellow/red) but would differ for enhancements (essentially all > light blue enhancements would become untriaged). >- Also, severity was already used to rate tickets on a scale. > > > or a new proposition: > > > 3. Severity becomes the main recipient of the triaging information. > + A list of all important defects regardless of milestone > (major/critical/blocker) is given the visibility. > + A list of all consensual enhancements regardless of milestone is > found at the end of the front page (e.g. major/critical). > + An unmet milestone can be removed safely; bump the severity if > necessary. > + Does not invalidate the color convention which we can explain > separately, and is consistent with the previous use of severity. >From what I understand there has been no preference expressed by anyone besides Guillaume on this. Does anyone else prefer one of the three options (or a different one)? Liviu since you have been involved earlier in the discussion, can you summarize your opinion with respect to the propositions Guillaume outlined (or a new proposition) ? Guillaume (and others), I would like to go through the bugs with milestone 2.2 soon. My only goal will be to figure out which tickets should keep 2.2 as a milestone and which should not. I'll make some decisions about moving some tickets to 2.3 or 2.2.x but I do not plan on thinking carefully about the severity or importance. I will assume that anyone who cares about the particular ticket will modify it accordingly. If someone prefers a different plan, please let me know. Scott
LyX 2.2 testing OS X 10.11 / retina display
Hi, This is in response to a post by Scott Kosty on latex-community.org. I'd be interested in testing out an OS X build of LyX 2.2 when it's reached the appropriate development stage. Drop me a line with more info when the time comes. Thanks, Ian
Re: When to court Qt 5.6?
Uwe Stöhr wrote: > Besides this I am still using MSVC 2010. I need to update to MSVC 2012 > or newer and this is another challenge. I already tested MSVC 2012 with > Qt 5.5 with success. Let's see what Qt 5.6 supports and if I can then > still compile LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC. I would suggest to use the newest stable version, with is currently MSVC 2015. Then you need to update and adjust to changes look and feel less often. In general, installing two MSVC versions in parallel is no problem, the same is true for qt. The only thing you need to make sure is that none of these versions is listed in the PATH or other environment variables. Then you can use two build.bat files for the two versions, and set all needed environment variables (e.g. adding the qt bin dir to PATH for moc etc) separate in these two files. Furthermore, a new MSVC version requires a new dependency package. As I already wrote to David Hyde (who wants to compile LyX with a newer MSVC), I think that the current procedure of providing the binaries for a sepcific MSVC version produces too much work in the long run. Instead, a python or cmake script to download the sources of the dependencies and compile them should be written. This is more effort initially, but pays off in the long term, and also removes some pressure from you, since others can then create the dependencies they need without manual work for you. Georg
Re: [LyX/master] Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
On Tue, Oct 20, 2015 at 07:16:44PM +0200, Günter Milde wrote:
> commit 1523fc6023440f10ca0d82a681ded5c060d8fd33
> Author: Günter Milde
> Date: Tue Oct 20 19:14:39 2015 +0200
>
> Partial fix for #9740 "XeTeX/LuaTeX with TeX fonts problems".
>
> Fixes output for 3 of the 4 test lyx-files.
>
> Includes "FIXME"s at places where further action is required to get the
> XeTeX
> export right but I don't know how.
> ...
> + &&!runparams.isFullUnicode()) { // FIXME: check must be done for
> useNonTeXFonts!
> os << "\\inputencoding{utf8}\n"
> << setEncoding("UTF-8");
So to make sure I understand what you want with this FIXME is you would
like to do something like params().useNonTeXFonts as you do in
Buffer.cpp but in PDFOptions.cpp it's not clear how to access that?
Scott
Re: Many tex2lyx failing now on master
Guenter Milde wrote: > On 2015-10-19, Uwe Stöhr wrote: > >> I don't understand what I made wrong. I only changed something in a >> module and added a fileformat change for lyx2lyx. I did not change any >> tex2lxy test file nor did I change tex2lyx code. It is all documented in Development.lyx. >> I also followed lib/doc/Development.lyx sec. 2.3. This references sec. >> 3.2.2 and I tried that too, but this is not possible on my PC: If a procedure that is documented to be required for certain changes does not work, then I would expect every developer to ask on the list for help _before submitting_ instead of ignoring the issue. > If the hint that a fileformat change requires adapting the test examples > is missing there, this is a documentation bug. The hint is there, in section 2.3. > In addition, adding the "change the fileformat numer for tests" > requirement to Development.lyx would help prevent others to fall in this > trap and frustration by others frentically trying to get the tests in > shape before a release. It is already in. The only thing which is indeed missing is a description how running the tests and updating the test references works with MSVC. Unfortunately I don't know that, otherwise I would have documented it. Vincent, maybe you can find that out? If you think that anything else is missing in the documentation of file format changes or concerning the tex2lyx tests, then please tell what you'd expect, and we can improve the docs. Georg
Re: LyX's master is now uncompilable
Guillaume Munch wrote: > I'll let Vincent decide whether he wants to make this change. Sure, our messages crossed each other, I would not have suggested that if I knew that he had time to test. The compilation error could btw easily be fixed by moving the implementation of the methods in a .cpp file (I would suggest to use src/support/docstream.cpp where id is already implemented, since adding a new .cpp would not be trivial: It would not need to be compiled on unix for example). Georg
Re: Many tex2lyx failing now on master
Guenter Milde wrote: > I updated the lyxformat number in the src/tex2lyx/test/*.lyx.lyx files and > now all tex2lyx tests pass here. Very good. Just to avoid future errors: I assume that you did check before that a simple update of the format number is OK, and that no tex2lyx source code changes are needed? How to do such checks in described in section 2.3 of Development.lyx, item 5. Georg
Re: LyX's master is now uncompilable
Op 19-10-2015 om 23:36 schreef Guillaume Munch: Le 19/10/2015 21:59, Vincent van Ravesteijn a écrit : Op 19 okt. 2015 22:51 schreef "Guillaume Munch" mailto:g...@lyx.org>>: > > Le 19/10/2015 21:34, Georg Baum a écrit : >> >> >> The message on the list is related to commit e948caf6, which is supposed to >> fix exactly this issue. What I do not understand it why the fix does not >> work for your recent changes. Maybe you forgot to include docstream.h >> somewhere or got the include order wrong? > > > The former. If we are supposed to include support/docstream.h to use odocstringstream, shouldn't the latter be defined in docstream.h instead of strfwd.h? (or the fix be moved to strfwd.h which is already included by docstream.h via docstring.h?) > > I am tempted to do the proper fix, but since I do not own MSVC, people would have to bear with me if this breaks compilation temporarily. > If you post the fix to the list here, I will try it tomorrow, and if it works, I will commit. Unfortunately, the patch doesn't work. "docstring.h" includes "strfwd.h", which now includes "numpunct_lyx_char_type.h", which uses "from_ascii", which is defined in "docstring.h". Vincent
Re: Moving towards a 2.2 release
On 2015-10-20, Scott Kostyshak wrote: > On Mon, Oct 19, 2015 at 08:18:30PM +, Guenter Milde wrote: >> I realised that this not only applies to compilation with Xe/LuaTeX which >> is a good thing -- it also catches cases like small letters missing in >> most math-script fonts (To fix the description in lib/RELEASE-NOTES, just >> trim the sentence.) > I made the change (although you are most welcome to edit the > RELEASE-NOTES). It is the same change that I did here locally, thanks. ... > Actually the tests are not that sophisticated. They just check whether > the compilation runs without error (ie it checks the exit code from > command-line export) Except for the tex2lyx tests. >> I have a partial fix for the "Xe/LuaTeX with TeX-fonts" problem. The fix >> prevents compilation errors with luatex and improves he situation a bit >> for xetex (the difference is, that there is "luainputenc" but no >> "xetexinputenc" in TeXLive and the standard "inputenc" package currently >> refuses to work with xetex unless the encoding is utf8). >> Should I commit the patch or wait? > Please commit. Done. tex2lyx test still pass. There are some more "easyfix" patches in the pipeline: #9770 unicodesymbols replacements for wasysym text symbols and a symbols-invdiameter.patch: diff --git a/lib/symbols b/lib/symbols index 89fc41a..992f556 100644 --- a/lib/symbols +++ b/lib/symbols @@ -695,8 +695,7 @@ hexstarwasy 65 0 x✶ varhexstar wasy 66 0 x✶ davidsstar wasy 67 0 x✡ diameter wasy 31 0 x⌀ -# Unicode is wrong, but a true alternate doesn't seem available. -invdiameterwasy 21 0 x⌀ +invdiameterwasy 21 0 x⍉ varangle wasy 30 0 x∢ wasylozengewasy 53 0 x⌑ kreuz wasy 54 0 x✠ Commit? Günter
Re: Update on the patches
Le 09/10/2015 22:07, Jean-Marc Lasgouttes a écrit : Le 09/10/2015 22:06, Georg Baum a écrit : Even more interesting. I always thought that LyX uses the "use tabs for logical indentation, and spaces for visual alignment" model for C++ code. This way, it does not matter at all whether you display a tab as 4 or 8 spaces wide or anything else, and this is IMHO a good thing (I have first hand knowledge for preferenes of 2, 3, 4, and 8 spaces wide). I would be interested by an emacs configuration that respects this. I have to do it by hand every time... JMarc http://www.emacswiki.org/emacs/SmartTabs
Re: Change tracking output issues
On Tue, Oct 20, 2015 at 03:49:40PM +, Paul A. Rubin wrote: > Scott Kostyshak lyx.org> writes: > > > > > > Hi Paul, can you send a minimal example to the list so we can see if we > > see the changes in other formats? So to confirm, if you compile with > > XeTeX or LuaTeX you do not see the changes? > > Scott, > > I'm not set up to use LuaTeX (and don't know how to use XeTeX); I'm just > testing the "old school" formats. I don't actually know how to use XeTeX either, but LyX takes care of the necessary XeTeX-specific things so it just works for me. If it doesn't work for you then it is probably because of a non-trivial preamble. I'm not suggesting you switch to XeTeX. I also use pdfTeX. I just say the above in case anyone out there is curious. Scott
Re: Change tracking output issues
On Tue, Oct 20, 2015 at 06:15:13PM +0200, Kornel Benko wrote: > Am Montag, 19. Oktober 2015 um 14:27:54, schrieb Paul A. Rubin > > Hi all, > > > > I couldn't find an open bug report on either of these, so I thought I'd > > ask for input here. The following apply to LyX 2.1.4. > > > > Issue #1: In the User Guide, section 6.16, the last paragraph says that > > dvipost must be installed to show changes in the output. I've been > > showing changes in output (pdflatex) just fine without it. Is this > > advice out of date? > > > > Issue #2: The /only/ format that lets me show changes as changes is > > pdflatex. All other formats compile the document but give no indication > > where the changes are. Am I missing something? > > > > Thanks, > > Paul > > I tried your example, all available pdf formats are displaying the change > here. > (E.g. > PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX) > ) > > Exporting to dvi with 'DVI (LuaTex)' is wrong, but export to 'DVI' is OK. > > This is with TL2015 and lyx 2.2dev I did not test (I assume I get the same result as Kornel since I have a similar system), but I suppose the next step is to send the .tex files. e.g. instead of exporting to PDF (pdflatex) export to LaTeX (pdflatex). Scott
Re: Change tracking output issues
Am Montag, 19. Oktober 2015 um 14:27:54, schrieb Paul A. Rubin > Hi all, > > I couldn't find an open bug report on either of these, so I thought I'd > ask for input here. The following apply to LyX 2.1.4. > > Issue #1: In the User Guide, section 6.16, the last paragraph says that > dvipost must be installed to show changes in the output. I've been > showing changes in output (pdflatex) just fine without it. Is this > advice out of date? > > Issue #2: The /only/ format that lets me show changes as changes is > pdflatex. All other formats compile the document but give no indication > where the changes are. Am I missing something? > > Thanks, > Paul I tried your example, all available pdf formats are displaying the change here. (E.g. PDF (ps2pdf), PDF (pdflatex), PDF (dvipdfm), PDF (XeTeX), PDF (LuaTeX) ) Exporting to dvi with 'DVI (LuaTex)' is wrong, but export to 'DVI' is OK. This is with TL2015 and lyx 2.2dev Kornel signature.asc Description: This is a digitally signed message part.
Re: Change tracking output issues
Scott Kostyshak lyx.org> writes: > > Hi Paul, can you send a minimal example to the list so we can see if we > see the changes in other formats? So to confirm, if you compile with > XeTeX or LuaTeX you do not see the changes? Scott, I'm not set up to use LuaTeX (and don't know how to use XeTeX); I'm just testing the "old school" formats. I'm accessing the list through GMANE, so I can't attach files. Instead, I zipped up a minimal example and parked it in my public Dropbox folder: https://www.dropbox.com/s/m84n1te4n2n6c3j/change%20tracking.zip?dl=0. I included three PDF output files (generated via pdflatex, ps2pdf and dvipdfm) and one DVI file. They all contain the changes, but only the first one shows them properly formatted. Paul
Re: Many tex2lyx failing now on master
On 2015-10-19, Scott Kostyshak wrote: > On Mon, Oct 19, 2015 at 07:38:12PM +0100, Guillaume Munch wrote: >> Le 19/10/2015 19:12, Scott Kostyshak a écrit : >> >Many tex2lyx tests have started to fail (before it was just 4 and we >> >knew why and I think Günter's recent commit might have fixed them?). Now >> >14 are failing. ... >> I see lots of diffs of the form >> #LyX file created by tex2lyx 2.2 >> -\lyxformat 497 >> +\lyxformat 498 >> \begin_document >> \begin_header >> \origin roundtrip >> and the commit ce933b1e14 has incremented the format to 498. Could that >> alone make the tests fail? > It could be. Please do not spend any time on this right now though. > Let's first see if Uwe has an idea of how to fix them. I updated the lyxformat number in the src/tex2lyx/test/*.lyx.lyx files and now all tex2lyx tests pass here. Commited at a0e2d48a569510dce6f3f288ee7a14e239cd4de2/lyxgit Hope this helps, Günter
Re: [LyX/master] Refine lang nesting fix
On Mon, Oct 19, 2015 at 07:59:59PM -0400, Scott Kostyshak wrote:
> On Mon, Oct 19, 2015 at 09:24:45PM +0200, Georg Baum wrote:
> > Scott Kostyshak wrote:
> >
> > > http://www.lyx.org/trac/ticket/9633
> >
> > I am a bit confused. I thought my fix which I just submitted would address
> > this?
>
> Ah that is great then. I was focused only on regressions caused by
> 46aed6d2 but it seems you fixed much more than I thought. Thank you!
>
> If I remember correctly many of the failing tests after edd37de8 were
> due to babel-specific code in the preamble. I will take a look to see if
> any failures are due to the nested language issue.
I think I found a few more. I do not know enough to say whether it is
worth your time to look into them. You have already explained that this
part of the code needs to be redesigned from the ground up. In any case,
here are the others I found:
These two have errors of the type you've been fixing
(e.g. "\begin{otherlanguage} on input line 377 ended by \end{itemize}")
They both compile well when "always babel" is selected.
export/doc/nb/Intro_pdf5_systemF
export/doc/sk/Intro_pdf5_systemF
The following seems like a different case:
export/doc/fr/UserGuide_pdf5_systemF
It compiles fine with "Always babel". With polyglossia it gives the following
error:
! Undefined control sequence.
\in@ #1#2->\begingroup \def \in@@
##1#1{}\toks@ \expandafter {\in@@ #2{}{}#1...
I don't know if that is related to the type of bugs you've been fixing.
Let me know if you want me to look for more.
Scott
Re: Many tex2lyx failing now on master
On 2015-10-19, Uwe Stöhr wrote: > Am 19.10.2015 um 20:55 schrieb Scott Kostyshak: >> There is some at lib/doc/Development.lyx >>> I see lots of diffs of the form >>> #LyX file created by tex2lyx 2.2 >>> -\lyxformat 497 >>> +\lyxformat 498 >>> and the commit ce933b1e14 has incremented the format to 498. Could that >>> alone make the tests fail? > I don't understand what I made wrong. I only changed something in a > module and added a fileformat change for lyx2lyx. I did not change any > tex2lxy test file nor did I change tex2lyx code. A fileformat change is IMO a "big" change that should be agreed with the release manage so short before an alpha release. As the tex2lyx tests compare the result of converting a *.tex file with a stored example of the expected LyX file, they need updating with every change to the default settings and bits in these LyX files, including the fileformat number. > I also followed lib/doc/Development.lyx sec. 2.3. This references sec. > 3.2.2 and I tried that too, but this is not possible on my PC: If the hint that a fileformat change requires adapting the test examples is missing there, this is a documentation bug. > So if anybody could please tell me what I should do I will do this and > also update lib/doc/Development.lyx accordingly. If there is agreement to the fileformat change, replacing the fileformat number in the *.lyx and *.lyx.lyx files in the tex2lyx tests would (hopefully) solve the issue. I can confirm that before these changes but applying my patches for "combining lines below", tests passed. In addition, adding the "change the fileformat numer for tests" requirement to Development.lyx would help prevent others to fall in this trap and frustration by others frentically trying to get the tests in shape before a release. Günter
Re: Many tex2lyx failing now on master
Am Dienstag, 20. Oktober 2015 um 01:04:36, schrieb Uwe Stöhr > Am 19.10.2015 um 20:55 schrieb Scott Kostyshak: > > > There is some at lib/doc/Development.lyx > >> I see lots of diffs of the form > >> > >> #LyX file created by tex2lyx 2.2 > >> -\lyxformat 497 > >> +\lyxformat 498 > >> and the commit ce933b1e14 has incremented the format to 498. Could that > >> alone make the tests fail? > > I don't understand what I made wrong. I only changed something in a > module and added a fileformat change for lyx2lyx. It is this 'fileformat change'. The files (*.lyx.lyx) created now by tex2lyx are now different (the first 2 lines of a created file reads #LyX file created by tex2lyx 2.2 \lyxformat 497 ) > I did not change any > tex2lxy test file nor did I change tex2lyx code. > > I also followed lib/doc/Development.lyx sec. 2.3. This references sec. > 3.2.2 and I tried that too, but this is not possible on my PC: > > I use CMake. So I opened a MSVC console with all build commands loaded. > The result is: > > D:\LyXGit\Master\src\tex2lyx\test>make updatetex2lyxtests > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > Fatal: Unable to open makefile You should use the correct target for your platform. This 'make updatetex2lyxtests' is meant for linux. For Windows it may be something with appropriate solution, e.g. 'msbuild updatetex2lyxtests.sln' (I am guessing here, Vincent will know) > So if anybody could please tell me what I should do I will do this and > also update lib/doc/Development.lyx accordingly. > > thanks and regards > Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: Regression in lyx2lyx box alignment
Le 20/10/2015 04:39, Scott Kostyshak a écrit : Many developers pop in and out. I think JMarc is the only developer who is consistent. It is a wonder how he has not gone insane yet (or maybe he is pushing his commits from the inside of an insane asylum?). Am I supposed to resent this? (don't worry, I don't :) Indeed, I can confirm that working long-term with LyX (like any project, I guess) leads to intermittent frustration. It can only be balanced by a personal satisfaction given by what you create by your work. Or the satisfaction of seeing that your work is helpful to others. However, the team is an ecosystem and keeping this ecosystem alive and well is a necessity to be able to be able to do your own creation. This is why it is so important to care this interaction. JMarc
