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
