On Thu, Jun 04, 2015 at 01:42:51AM +0100, Guillaume M-M wrote: > Le 02/06/2015 23:50, Enrico Forestieri a écrit : > > > >Try using gdb for getting a backtrace after setting a breakpoint at > >lassert.cpp:53. If this is due to some recent change, you could try > >bisetting for finding the relevant commit. > > The assert failure went away after recompiling. If I remember correctly when > I had the problem I had been playing with the configure options (for the > sake of trying), notably --enable-monolithic-build. Would you like me to try > to reproduce the issue, or am I expected to run into such troubles if I play > with the build options?
This should not depend on the build options, unless you use the --enable-concept-checks and --enable-stdlib-debug options, I think. It is hard to tell the cause if it is not reproducible. It could be due to some race condition or whatever. > >>For me the bug is still here at cb201027. Try again my file > >>lyx-bug-renewcommandx.lyx attached to my first message. > > > >Strange, I don't see it anymore after 83a9ed4e. > > > > With lyx-bug-renewcommandx.lyx from my initial message, although the preview > now works on opening, it fails if one enters the math inset and leaves it. > Because then we get the following erroneous code (missing \newcommandx): > > """ > \begin{preview} > $\A$ > \end{preview} > """ Yes, I can reproduce in master. It does not occur in stable, where a different strategy is used, only involving the instant preview scripts. If I am not mistaken, it goes like this. When you enter and then leave a math inset, the generated preview snippet is compared with the cached ones. If it matches one of them, no further action is taken and the corresponding image is used. It is the way duplicated macros are avoided in master that causes this glitch, because the macro definitions are also cached. When the document is loaded, that snippet contains the macro definition because it was not appearing before. However, when you enter and then leave the math inset, the code thinks that the macro was already defined previously and does not include it anymore. Now the snippet does not match any of the cached ones because the macro is not there anymore. Hence, a new preview is attempted but it fails because of the missing macro definition. Fixing this requires a bit more work in master. First of all, the cached macros should be cleared after a preview cycle completed, such that next previews involving the same macro can succeed. However, given that the produced snippet would now be different from when it was generated the first time (no macro present at that time), the already cached image would not be used and a new one will be generated. This risks to be highly inefficient, of course, so something should be thought for avoiding it. > Here is another file that doesn't work for me (lyx-bug-renewcommandx2.lyx). > With it we get the erroneous latex code: > > """ > \begin{preview} > \renewcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1} > > $\A$ > \end{preview} > > \begin{preview} > \newcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1} > $\A$ > \end{preview} > """ Actually, I cannot reproduce this. Even entering and then leaving the math inset works for me. But I can make it fail by changing the macro parameter. The reason of the failure is the same as for the previous case, though. > Lastly, with lyx-bug-renewcommandx3.lyx (attached) we get the following > erroneous code for the first preview after opening: > > """ > \begin{preview} > \global\long\def\A{A} > $\A$ > \end{preview} > > \begin{preview} > \newcommandx\A[1][usedefault, addprefix=\global, 1=B]{A#1} > $\A$ > \end{preview} > """ The reason is similar. Given that the whole macro snippet is cached, the first definition does not match the second one. In this case, for avoiding the problem, the names of the macros should be also cached and \renewcommandx used in case a macro turns out to be already defined by the \def primitive. I just fixed this in the preview scripts for stable. The fix for master may require some further thinking about how the caching should be performed, though. -- Enrico