Re: LyX 2.3.0 Regression Inquiry
Am Freitag, den 11.05.2018, 21:44 -0600 schrieb Joel Kulesza: > LyX Developers, > > As I'm writing my dissertation, I've been using LyX 2.2.3 but today > decided to try migrating it to 2.3.0. Upon doing so, I encountered > what appears to be a regression (or else I've been doing something > invalid all along that 2.2.3 accepts without complaint). I get the same problem with 2.2.3. It is a mystery to me why this works for you. > I cannot make the document available but I have a not-quite-MWE > available that I hope you could work with to see if you can reproduce > what I'm seeing with LyX 2.2.3/2.3.0 on two separate computers (macOS > 10.13.4 and OS X 10.11.6). If this can be reproduced and someone can > help me characterize this, I'm happy to file an item in the tracker. > > Steps to reproduce: > Clone https://github.com/jkulesza/UMich_Dissertation_LyX and checkout > the "lyx_mwe" branch. > Open dissertation.lyx in LyX 2.2.3. Render. This should succeed. > Right-click chapter_01.lyx -> Edit. Render. This should succeed. > Exit. > Open dissertation.lyx in LyX 2.3.0. Render. This should succeed. > Right-click chapter_01.lyx -> Edit. Render. This should fail with > the attached regarding being unable to find my .bst file. > At this point, I'm unsure where the problem lies (if it is indeed a > problem) so anything I'd file in the tracker is no more help that > what I'm filing here. > > As always, your help and time is appreciated! The story is long and complex. If you are not interested in the background but only in what I think the bug here is, jump to the last paragraph. The problem is as follows: bibliography.lyx is included both in dissertation.lyx and chapter_01.lyx (which is also a child of dissertation.lyx). This leads to bibliography.lyx claiming two "parent buffers", one of which at the same time is its grandparent, a setting which LyX is not (yet) prepared for (you also get a warning on the console because of that). Since only one parent is currently allowed, the last allocated one is the effective parent (in your case, it happens to be chapter_01.lyx, but read on...). This "effective" parent is used for inheriting specific settings and data to the children (e.g. for instant preview, source preview, labels for cross-referencing, bibliography data for citing, etc.). I call this type of parent "workarea parent" in what follows. The situation that chapter_01.lyx is the "workarea parent" is most probably not what you want, since I suppose you want to inherit settings and data from dissertation.lyx. We could (try to) always use the uppermost buffer in the hierarchy as "workarea parent" (if this can be determined), but ideally, we should allow for multiple parents and provide a way to select the "main" one that is used for workarea purposes (sometimes uppermost parents are just portmanteaus for specific purposes; think beamer handouts). However, this is a different bug ... But next to the "workarea parent", the is another (and sometimes different) kind of parent, namely the master document (henceforth called "output parent"). If you compile your MWE from dissertation.lyx, this file is the master document (output parent) and chapter_01.lyx and bibliography.lyx are its children. If you compile from chapter_01.lyx, however, this one is the master, with bibliography.lyx as child. In order to account for that, we try to completely cut the links from chapter_01.lyx to dissertation.lyx in that latter scenario (via the ignore_parent bool that is set on latex export). This makes chapter_01.lyx "output parent" of bibliography, or at least it is supposed to be so. Over the weekend, I tried to understand why this is not fully the case, i.e., why the BibTeX inset in bibliography.lyx, when compiled from chapter_01.lyx, has dissertation.lyx as its "output parent" (effecting in the wrong tmp dir location determined via masterBuffer()- >temppath()), even though we have explicitly cut the link from chapter_01.lyx upwards. I first thought that the "workarea parent" chimes in here, but that's not true, since as we saw above, "workarea parent" is (erroneously) set to chapter_01.lyx as well! And here is what I think to be the problem: a bug in the the buffer cloning logic. Buffer cloning is done for exporting buffers; all involved buffers are copied and then used for the export (this allows for editing the real buffers during export). When we do that cloning, the parents are newly assigned to the clones. And here's the problem: this is always done from the effective "workarea parent" of the buffer that is about to be processed (asyncBufferProcessing() calls cloneFromMaster(), which starts processing at masterBuffer()). So while exporting, which starts from the real "output parent", chapter_01.lyx, the parents are newly assigned to the whole family, and since dissertation.lyx is the workarea parent of chapter_01.lyx, dissertation.lyx is (wrongly) declared as (output!) parent of chapter_01.lyx _and_ biblio
Re: Update on 2.3.0 situation and Windows-specific issues
On 05/13/2018 01:34 PM, Uwe Stöhr wrote: > Am 12.05.2018 um 05:13 schrieb Richard Kimberly Heck: >>> Please make your decision and tell me. >> >> Others can speak up if they wish, but I believe we have made ourselves >> clear. We will not release an official Windows installer that updates >> people's MikTeX installations without asking their permission. > > OK, this was clear since about 2 months. Why haven't we discussed at > all? I made some arguments, see below and haven't heard a good reason > against them. We discussed it endlessly. You gave your reasons, we gave ours, and we seem to be at a stalemate. > It is also interesting that non-Win developers state they have better > arguments without contesting the arguments from the Win developer. As JMarc mentioned, he uses Windows all the time, and yet he agrees with the rest of the development team. I used Windows for years before switching to Linux, and I've installed Windows 10 both in a virtual machine and separately just to be able to check out these kinds of issues (as well as to explore Windows-specific bugs). There are tons of users who have now expressed their opinions on this. Do none of us count? Why not? I am sorry that the relevant issues here have gotten mixed up with more general issues about the Windows installer. As I said, I (and I think many others) wonder about whether it is a good idea to try to package all of LyX's dependencies the way you are. I am sorry that my use of the English idiom "I wonder whether it's wise..." misled you. That simply means: I wonder whether it's the best course It's a very ordinary phrase. But that's not what's at issue now. The ONLY question at the moment is about a warning dialog at the outset: One that would tell users that the installer will update MikTeX, direct them to a wiki page with more information, and give them the opportunity to cancel. That's it. No one is suggesting that you should change the installer in any other way, and if I manage to build the installer myself, then that is exactly what it would be like: The same as yours, with that dialog. I understand that you think this would confuse 'ordinary users'. But even if you are right, and it seems to me that you are underestimating the intelligence of 'ordinary users', then (a) we can figure out some way to help them and (b) that is out-weighed by the fact that updating MikTeX can cause serious problems for some users. That is the 'harm' we've been talking about. Breaking people's systems is not a trivial matter, as José and many others have said. > Average user can misunderstand it with a probability of 50%. Those who > misunderstood it and denied the update can end up with an unusable LyX. I think this is the issue that most matters. As I see it, this **cannot happen**. If the user cancels the install, then NOTHING HAPPENS. The proposal I and others have been making is that we have a dialog *at the very beginning*. If the user cancels, then NOTHING HAPPENS. Their system is left exactly the same as if they had never run the installer at all. There is therefore no possible way that running the installer and denying can have a bad effect. It's a NO-OP if the user cancels. I also understand that there are other things that could happen, that have nothing to do with the LyX installer, that would break people's MikTeX installations. That is unfortunate, but not our problem, and not something for which we should risk breaking other users' installations. It seems to me that your worry is that, if we don't update MikTeX on the update to 2.3.0, then there are users whose MikTeX will never get updated, and then their systems will be broken. Maybe so. But that, again, is not our problem. It's a bug in MikTeX that causes this, and the problem should be fixed there. I know that we sometimes 'work around' bugs in other programs, but not when it will break stuff for other users. Even if, as 'experts', they can (maybe) fix it. >> If you refuse to include such a dialog, then I guess you should build >> your installer separately. > > I refuse because this doesn't fit with Windows behavior as a service. > [...] So I will now set up a new OpenSource project besides LyX for > the installer. OK. But please do not expect this *fork* to be advertised on the LyX download page once we have a new installer. Especially since, after not very long, this whole update issue will cease to be an issue. > Since Windows changes e.g. registry things, programs like MiKTeX must > change the way they work from time to time - if they like it or not. > So must do LyX! Even *the MikTeX maintainer* has made it clear that we should not update MikTeX without asking permission from the user. Isn't that good enough? Riki
Re: Update on 2.3.0 situation and Windows-specific issues
On 05/13/2018 01:34 PM, Uwe Stöhr wrote: > Am 12.05.2018 um 05:13 schrieb Richard Kimberly Heck: >>> Please make your decision and tell me. >> >> Others can speak up if they wish, but I believe we have made ourselves >> clear. We will not release an official Windows installer that updates >> people's MikTeX installations without asking their permission. > > OK, this was clear since about 2 months. Why haven't we discussed at > all? I made some arguments, see below and haven't heard a good reason > against them. We discussed it endlessly. You gave your reasons, we gave ours, and we seem to be at a stalemate. > It is also interesting that non-Win developers state they have better > arguments without contesting the arguments from the Win developer. As JMarc mentioned, he uses Windows all the time, and yet he agrees with the rest of the development team. I used Windows for years before switching to Linux, and I've installed Windows 10 both in a virtual machine and separately just to be able to check out these kinds of issues (as well as to explore Windows-specific bugs). There are tons of users who have now expressed their opinions on this. Do none of us count? Why not? I am sorry that the relevant issues here have gotten mixed up with more general issues about the Windows installer. As I said, I (and I think many others) wonder about whether it is a good idea to try to package all of LyX's dependencies the way you are. I am sorry that my use of the English idiom "I wonder whether it's wise..." misled you. That simply means: I wonder whether it's the best course It's a very ordinary phrase. But that's not what's at issue now. The ONLY question at the moment is about a warning dialog at the outset: One that would tell users that the installer will update MikTeX, direct them to a wiki page with more information, and give them the opportunity to cancel. That's it. No one is suggesting that you should change the installer in any other way, and if I manage to build the installer myself, then that is exactly what it would be like: The same as yours, with that dialog. I understand that you think this would confuse 'ordinary users'. But even if you are right, then (a) we can figure out some way to help them and (b) that is out-weighed by the fact that updating MikTeX can cause serious problems for some users. That is the 'harm' we've been talking about. Breaking people's systems is not a triival matter, as I have José, and many others have said. Even *the MikTeX maintainer* has made it clear that we should not update MikTeX without asking permission from the user. Isn't that good enough? >> where Jim Rockford suggests "a simple warning message" as a solution, >> exactly what we have been suggesting all along. > > Why is my proposal not taken into account: Not having MiKTeX updated > is an expert thing. Therefore only experts should be bothered with > this. experts can read the announcement. Because no one reads ANNOUNCE, even expert users. And by the time the update is done, the damage is done. > Average user can misunderstand it with a probability of 50%. Those who > misunderstood it and denied the update can end up with an unusable LyX. No, they do not. If they deny, then NOTHING HAPPENS. The proposal is that we give this dialog at the very beginning, and if the user cancels, then NOTHING HAPPENS. Their system is left exactly the same as if they had never run the installer at all. There is therefore no possible way that running the installer and denying can have a bad effect. It's a NO-OP. > >> If you refuse to include such a dialog, then I guess you should build >> your installer separately. > > I refuse because this doesn't fit with Windows behavior as a service. > Windows will bring you every half a year new features and change > settings and registry entries. If you don't like this you cannot use > Windows. Since Windows changes e.g. registry things, programs like > MiKTeX must change the way they work from time to time - if they like > it or not. So must do LyX! > But you think you can do different. Then start your Win 10 with the > recent update that came out few days ago and try if you can work with > MiKTeX and its old package management. > > I think it is senseless to discuss any longer since I can argue > whatever I want and you will insist on your opinion you had from the > first day on. > > So I will now set up a new OpenSource project besides LyX for the > installer. > > regards Uwe
Re: Update on 2.3.0 situation and Windows-specific issues
On 05/13/2018 01:34 PM, Uwe Stöhr wrote: > Am 12.05.2018 um 05:13 schrieb Richard Kimberly Heck: >>> Please make your decision and tell me. >> >> Others can speak up if they wish, but I believe we have made ourselves >> clear. We will not release an official Windows installer that updates >> people's MikTeX installations without asking their permission. > > OK, this was clear since about 2 months. Why haven't we discussed at > all? I made some arguments, see below and haven't heard a good reason > against them. We discussed it endlessly. You gave your reasons, we gave ours, and we seem to be at a stalemate. > It is also interesting that non-Win developers state they have better > arguments without contesting the arguments from the Win developer. As JMarc mentioned, he uses Windows all the time, and yet he agrees with the rest of the development team. I used Windows for years before switching to Linux, and I've installed Windows 10 both in a virtual machine and separately just to be able to check out these kinds of issues (as well as to explore Windows-specific bugs). There are tons of users who have now expressed their opinions on this. Do none of us count? Why not? I am sorry that the relevant issues here have gotten mixed up with more general issues about the Windows installer. As I said, I (and I think many others) wonder about whether it is a good idea to try to package all of LyX's dependencies the way you are. I am sorry that my use of the English idiom "I wonder whether it's wise..." misled you. That simply means: I wonder whether it's the best course It's a very ordinary phrase. But that's not what's at issue now. The ONLY question at the moment is about a warning dialog at the outset: One that would tell users that the installer will update MikTeX, direct them to a wiki page with more information, and give them the opportunity to cancel. That's it. No one is suggesting that you should change the installer in any other way, and if I manage to build the installer myself, then that is exactly what it would be like: The same as yours, with that dialog. I understand that you think this would confuse 'ordinary users'. But even if you are right, then (a) we can figure out some way to help them and (b) that is out-weighed by the fact that updating MikTeX can cause serious problems for some users. That is the 'harm' we've been talking about. Breaking people's systems is not a triival matter, as I have José, and many others have said. Even *the MikTeX maintainer* has made it clear that we should not update MikTeX without asking permission from the user. Isn't that good enough? >> where Jim Rockford suggests "a simple warning message" as a solution, >> exactly what we have been suggesting all along. > > Why is my proposal not taken into account: Not having MiKTeX updated > is an expert thing. Therefore only experts should be bothered with > this. experts can read the announcement. Because no one reads ANNOUNCE, even expert users. And by the time the update is done, the damage is done. > Average user can misunderstand it with a probability of 50%. Those who > misunderstood it and denied the update can end up with an unusable LyX. No, they do not. If they deny, then NOTHING HAPPENS. The proposal is that we give this dialog at the very beginning, and if the user cancels, then NOTHING HAPPENS. Their system is left exactly the same as if they had never run the installer at all. There is therefore no possible way that running the installer and denying can have a bad effect. It's a NO-OP. > >> If you refuse to include such a dialog, then I guess you should build >> your installer separately. > > I refuse because this doesn't fit with Windows behavior as a service. > Windows will bring you every half a year new features and change > settings and registry entries. If you don't like this you cannot use > Windows. Since Windows changes e.g. registry things, programs like > MiKTeX must change the way they work from time to time - if they like > it or not. So must do LyX! > But you think you can do different. Then start your Win 10 with the > recent update that came out few days ago and try if you can work with > MiKTeX and its old package management. > > I think it is senseless to discuss any longer since I can argue > whatever I want and you will insist on your opinion you had from the > first day on. > > So I will now set up a new OpenSource project besides LyX for the > installer. > > regards Uwe
Re: Update on 2.3.0 situation and Windows-specific issues
Am 12.05.2018 um 05:13 schrieb Richard Kimberly Heck: No, I may wish to make use of it. I am in the process of figuring out how to build the Windows installer myself, as you suggested. The code belongs to LyX, not to you. I never said that it belongs to me. Please make your decision and tell me. Others can speak up if they wish, but I believe we have made ourselves clear. We will not release an official Windows installer that updates people's MikTeX installations without asking their permission. OK, this was clear since about 2 months. Why haven't we discussed at all? I made some arguments, see below and haven't heard a good reason against them. It is also interesting that non-Win developers state they have better arguments without contesting the arguments from the Win developer. understand that you think Windows users would be confused by a simple dialog asking their permission to update MikTeX. I explained a dozen times why, and again below. I have spoken to several Windows users over the last few days who think otherwise. For a public example, see https://www.mail-archive.com/lyx-users@lists.lyx.org/msg107175.html That doesn't help much. Jim know what MiKTeX is, my mother not. Jim will do the right thing in the dialog, my mother maybe not. Jim can google in our mailing list to find a solution, my mother not. So what people do we need to take care of the most - users like my mother. users like jim will find their way no matter if there is a dialog. where Jim Rockford suggests "a simple warning message" as a solution, exactly what we have been suggesting all along. Why is my proposal not taken into account: Not having MiKTeX updated is an expert thing. Therefore only experts should be bothered with this. experts can read the announcement. Average user can misunderstand it with a probability of 50%. Those who misunderstood it and denied the update can end up with an unusable LyX. Therefore I am against such a dialog. If you refuse to include such a dialog, then I guess you should build your installer separately. I refuse because this doesn't fit with Windows behavior as a service. Windows will bring you every half a year new features and change settings and registry entries. If you don't like this you cannot use Windows. Since Windows changes e.g. registry things, programs like MiKTeX must change the way they work from time to time - if they like it or not. So must do LyX! But you think you can do different. Then start your Win 10 with the recent update that came out few days ago and try if you can work with MiKTeX and its old package management. I think it is senseless to discuss any longer since I can argue whatever I want and you will insist on your opinion you had from the first day on. So I will now set up a new OpenSource project besides LyX for the installer. regards Uwe
