from:"Guillaume M\-M"


Dear list,


I got an assertion in stable (1b596e92) for the second time today. It 
happened while selecting text (first time with Shift+Arrows and second 
time with the mouse).


I don't remember seeing it before: if it wasn't introduced recently then 
maybe it was hidden by the fact that I did not use instant preview 
before. I cannot think of anything particular in my settings apart from 
instant preview on, only one document displayed.


I opened gdb after the first crash just in case. I don't know how to 
reproduce it, the second crash happened when I was no longer paying 
attention. I am keeping my gdb session open for a while if you would 
like me to extract more relevant informations than the trace below, just 
ask.



Messages:

CursorSlice.cpp (207): can't compare cursor and anchor in different insets
p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558
q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079
lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209
Assertion triggered in void lyx::doAssert(const char*, const char*, long 
int) by failing check false in file lassert.cpp:44



thread apply all backtrace:


Thread 7 (Thread 0x7fffe4ee3700 (LWP 22870)):
#0  0x75aac8dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x754e7ebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x754e8242 in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fffed806ae6 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0

#4  0x7550e955 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x752876aa in start_thread (arg=0x7fffe4ee3700)
at pthread_create.c:333
#6  0x75ab7eed in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 6 (Thread 0x7fffdf97b700 (LWP 22871)):
#0  0x75aac8dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x754e7ebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x754e7fcc in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x754e8009 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7550e955 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x752876aa in start_thread (arg=0x7fffdf97b700)
at pthread_create.c:333
#6  0x75ab7eed in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7fffdf17a700 (LWP 22884)):
#0  0x75aae743 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x7670ac0f in ?? () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x766246ff in ?? () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4

#3  0x752876aa in start_thread (arg=0x7fffdf17a700)
at pthread_create.c:333
#4  0x75ab7eed in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7fffde979700 (LWP 27221)):
#0  0x759e6267 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x759e7eca in __GI_abort () at abort.c:89
#2  0x0059418d in ?? ()
#3  0x04df8db0 in ?? ()
#4  0x005139a1 in ?? ()
#5  0x0a007fffde977c68 in ?? ()
#6  0x2ede86bc847dcc00 in ?? ()
#7  0x01d3b608 in ?? ()
#8  0x in ?? ()

Thread 1 (Thread 0x77fbe780 (LWP 22866)):
#0  0x76ea37b0 in QFontMetricsF::QFontMetricsF(QFont const) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#1  0x76db8b3e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x76dc06ef in QPainter::drawText(QRect const, int, QString 
const, QRect*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

#3  0x770d820a in QStatusBar::paintEvent(QPaintEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4  0x76cb4dc8 in QWidget::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x770d87be in QStatusBar::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x76c619bc in QApplicationPrivate::notify_helper(QObject*, 
QEvent*)

() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7  0x76c684d8 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8  0x0091ae46 in ?? ()
#9  0x0038 in ?? ()
#10 0x7fffc6d0 in ?? ()
#11 0x7fffc7b0 in ?? ()
#12 0x7fffc7a0 in ?? ()
#13 0x01a0faa0 in ?? ()
#14 0x75a3550e in __GI___libc_malloc (bytes=140737488341008)
at malloc.c:2895
#15 0x7661ada5 in 
QInternal::activateCallbacks(QInternal::Callback, void**) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x7672f1cd in QCoreApplication::notifyInternal(QObject*, 
QEvent*)

() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x76caf49d in QWidgetPrivate::drawWidget(QPaintDevice*, 
QRegion const, QPoint const, int, QPainter*, QWidgetBackingStore*) ()

   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#18

Re: assert in CursorSlice.cpp


Le 30/06/2015 19:20, Enrico Forestieri a écrit :

On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote:

Dear list,


I got an assertion in stable (1b596e92) for the second time today. It
happened while selecting text (first time with Shift+Arrows and second time
with the mouse).

I don't remember seeing it before: if it wasn't introduced recently then
maybe it was hidden by the fact that I did not use instant preview before. I
cannot think of anything particular in my settings apart from instant
preview on, only one document displayed.

I opened gdb after the first crash just in case. I don't know how to
reproduce it, the second crash happened when I was no longer paying
attention. I am keeping my gdb session open for a while if you would like me
to extract more relevant informations than the trace below, just ask.


Messages:

CursorSlice.cpp (207): can't compare cursor and anchor in different insets
p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558
q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079
lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check false in file lassert.cpp:44


The interesting thread seems to be Thread 4 but it was truncated too early.


Thread 4 (Thread 0x7fffde979700 (LWP 27221)):
#0  0x759e6267 in __GI_raise (sig=sig@entry=6)
 at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x759e7eca in __GI_abort () at abort.c:89
#2  0x0059418d in ?? ()
#3  0x04df8db0 in ?? ()
#4  0x005139a1 in ?? ()
#5  0x0a007fffde977c68 in ?? ()
#6  0x2ede86bc847dcc00 in ?? ()
#7  0x01d3b608 in ?? ()
#8  0x in ?? ()


Try running under gdb after setting a breakpoint at CursorSlice.cpp:206
(before the LASSERT line) and take a backtrace when it triggers.

I have no idea why it happens and wonder how many bugs are still lurking
there when instant preview for math is on...

In any case, it would greatly help if you can provide a reproducer.
However, note that this does not seem to be a fatal bug and LyX would
simply continue running when compiled in release mode.



Good to see that it's nevertheless taken seriously. Unfortunately I 
cannot manage to reproduce it on purpose.

assert in CursorSlice.cpp


Dear list,


I got an assertion in stable (1b596e92) for the second time today. It 
happened while selecting text (first time with Shift+Arrows and second 
time with the mouse).


I don't remember seeing it before: if it wasn't introduced recently then 
maybe it was hidden by the fact that I did not use instant preview 
before. I cannot think of anything particular in my settings apart from 
instant preview on, only one document displayed.


I opened gdb after the first crash just in case. I don't know how to 
reproduce it, the second crash happened when I was no longer paying 
attention. I am keeping my gdb session open for a while if you would 
like me to extract more relevant informations than the trace below, just 
ask.



Messages:

CursorSlice.cpp (207): can't compare cursor and anchor in different insets
p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558
q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079
lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209
Assertion triggered in void lyx::doAssert(const char*, const char*, long 
int) by failing check "false" in file lassert.cpp:44



thread apply all backtrace:


Thread 7 (Thread 0x7fffe4ee3700 (LWP 22870)):
#0  0x75aac8dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x754e7ebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x754e8242 in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fffed806ae6 in ?? () from 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0

#4  0x7550e955 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x752876aa in start_thread (arg=0x7fffe4ee3700)
at pthread_create.c:333
#6  0x75ab7eed in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 6 (Thread 0x7fffdf97b700 (LWP 22871)):
#0  0x75aac8dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x754e7ebc in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x754e7fcc in g_main_context_iteration ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x754e8009 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7550e955 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x752876aa in start_thread (arg=0x7fffdf97b700)
at pthread_create.c:333
#6  0x75ab7eed in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7fffdf17a700 (LWP 22884)):
#0  0x75aae743 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x7670ac0f in ?? () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2  0x766246ff in ?? () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4

#3  0x752876aa in start_thread (arg=0x7fffdf17a700)
at pthread_create.c:333
#4  0x75ab7eed in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7fffde979700 (LWP 27221)):
#0  0x759e6267 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x759e7eca in __GI_abort () at abort.c:89
#2  0x0059418d in ?? ()
#3  0x04df8db0 in ?? ()
#4  0x005139a1 in ?? ()
#5  0x0a007fffde977c68 in ?? ()
#6  0x2ede86bc847dcc00 in ?? ()
#7  0x01d3b608 in ?? ()
#8  0x in ?? ()

Thread 1 (Thread 0x77fbe780 (LWP 22866)):
#0  0x76ea37b0 in QFontMetricsF::QFontMetricsF(QFont const&) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#1  0x76db8b3e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x76dc06ef in QPainter::drawText(QRect const&, int, QString 
const&, QRect*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

#3  0x770d820a in QStatusBar::paintEvent(QPaintEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4  0x76cb4dc8 in QWidget::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x770d87be in QStatusBar::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x76c619bc in QApplicationPrivate::notify_helper(QObject*, 
QEvent*)

() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7  0x76c684d8 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8  0x0091ae46 in ?? ()
#9  0x0038 in ?? ()
#10 0x7fffc6d0 in ?? ()
#11 0x7fffc7b0 in ?? ()
#12 0x7fffc7a0 in ?? ()
#13 0x01a0faa0 in ?? ()
#14 0x75a3550e in __GI___libc_malloc (bytes=140737488341008)
at malloc.c:2895
#15 0x7661ada5 in 
QInternal::activateCallbacks(QInternal::Callback, void**) () from 
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x7672f1cd in QCoreApplication::notifyInternal(QObject*, 
QEvent*)

() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x76caf49d in QWidgetPrivate::drawWidget(QPaintDevice*, 
QRegion const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()

   from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

Re: assert in CursorSlice.cpp


Le 30/06/2015 19:20, Enrico Forestieri a écrit :

On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote:

Dear list,


I got an assertion in stable (1b596e92) for the second time today. It
happened while selecting text (first time with Shift+Arrows and second time
with the mouse).

I don't remember seeing it before: if it wasn't introduced recently then
maybe it was hidden by the fact that I did not use instant preview before. I
cannot think of anything particular in my settings apart from instant
preview on, only one document displayed.

I opened gdb after the first crash just in case. I don't know how to
reproduce it, the second crash happened when I was no longer paying
attention. I am keeping my gdb session open for a while if you would like me
to extract more relevant informations than the trace below, just ask.


Messages:

CursorSlice.cpp (207): can't compare cursor and anchor in different insets
p: inset: 0x414e320 idx: 8 par: 4294967295 pos: 7308604897068083558
q: inset: 0x2efa670 idx: 2 par: 4294967295 pos: 12079
lassert.cpp (42): ASSERTION false VIOLATED IN CursorSlice.cpp:209
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:44


The interesting thread seems to be Thread 4 but it was truncated too early.


Thread 4 (Thread 0x7fffde979700 (LWP 27221)):
#0  0x759e6267 in __GI_raise (sig=sig@entry=6)
 at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x759e7eca in __GI_abort () at abort.c:89
#2  0x0059418d in ?? ()
#3  0x04df8db0 in ?? ()
#4  0x005139a1 in ?? ()
#5  0x0a007fffde977c68 in ?? ()
#6  0x2ede86bc847dcc00 in ?? ()
#7  0x01d3b608 in ?? ()
#8  0x in ?? ()


Try running under gdb after setting a breakpoint at CursorSlice.cpp:206
(before the LASSERT line) and take a backtrace when it triggers.

I have no idea why it happens and wonder how many bugs are still lurking
there when instant preview for math is on...

In any case, it would greatly help if you can provide a reproducer.
However, note that this does not seem to be a fatal bug and LyX would
simply continue running when compiled in release mode.



Good to see that it's nevertheless taken seriously. Unfortunately I 
cannot manage to reproduce it on purpose.

Re: test of math previews

2015-06-25 Thread Guillaume M-M


Le 25/06/2015 23:45, Richard Heck a écrit :

On 06/25/2015 02:58 PM, Enrico Forestieri wrote:

On Thu, Jun 25, 2015 at 02:16:19PM -0400, Richard Heck wrote:

This more or less completes this work?

I think so. The most important glitches were identified and solved.


(For which thanks very much, to you
and Guillaume.)

The credit goes mainly to Guillaume for his accurate testing.


Somebody had to write the code

rh




This is also what I believe. Thank you!

By the way will f3b03699 be backported as well? It seems that segfaults 
are almost guaranteed for people with previews on during Ctrl+C...

Re: test of math previews

2015-06-25 Thread Guillaume M-M


Le 25/06/2015 23:45, Richard Heck a écrit :

On 06/25/2015 02:58 PM, Enrico Forestieri wrote:

On Thu, Jun 25, 2015 at 02:16:19PM -0400, Richard Heck wrote:

This more or less completes this work?

I think so. The most important glitches were identified and solved.


(For which thanks very much, to you
and Guillaume.)

The credit goes mainly to Guillaume for his accurate testing.


Somebody had to write the code

rh




This is also what I believe. Thank you!

By the way will f3b03699 be backported as well? It seems that segfaults 
are almost guaranteed for people with previews on during Ctrl+C...

Re: test of math previews

2015-06-24 Thread Guillaume M-M


Le 25/06/2015 00:44, Enrico Forestieri a écrit :

On Mon, Jun 22, 2015 at 11:32:17PM +0100, Guillaume M-M wrote:


3) Previews have the incorrect size with layouts that offer font sizes other
than 1[0-2]pt (lyx-preview-fontsize.lyx). The legacy method offers a
function that retrieves the actual font size and calculates the actual dpi.
Attached is a patch (extract_resolution.diff) that imports this function in
the new script.


Thank you, this is much better than trying to catch all possible cases.
I have applied the patch to master at 0751f96d.



Thank you for applying it.

Here's a trivial patch for stable, if you are not ready to backport 
0751f96d. Both were tested in stable.


Guillaume
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 9775b0e..8cd3c09 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,7 +159,7 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
+documentclass_re = re.compile((documentclass\[)([0-9]+pt,?)(.+))
 def_re = re.compile(r(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z]+))
 
 tmp = mkstemp()

Re: test of math previews

2015-06-24 Thread Guillaume M-M


Le 25/06/2015 00:44, Enrico Forestieri a écrit :

On Mon, Jun 22, 2015 at 11:32:17PM +0100, Guillaume M-M wrote:


3) Previews have the incorrect size with layouts that offer font sizes other
than 1[0-2]pt (lyx-preview-fontsize.lyx). The legacy method offers a
function that retrieves the actual font size and calculates the actual dpi.
Attached is a patch (extract_resolution.diff) that imports this function in
the new script.


Thank you, this is much better than trying to catch all possible cases.
I have applied the patch to master at 0751f96d.



Thank you for applying it.

Here's a trivial patch for stable, if you are not ready to backport 
0751f96d. Both were tested in stable.


Guillaume
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 9775b0e..8cd3c09 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,7 +159,7 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
+documentclass_re = re.compile("(documentclass\[)([0-9]+pt,?)(.+)")
 def_re = re.compile(r"(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z]+)")
 
 tmp = mkstemp()

Re: test of math previews

2015-06-23 Thread Guillaume M-M


Le 23/06/2015 10:46, Enrico Forestieri a écrit :

On Tue, Jun 23, 2015 at 11:18:56AM +0200, Enrico Forestieri wrote:

On Tue, Jun 23, 2015 at 02:44:00AM +0100, Guillaume M-M wrote:


Still there at cd046f0e (master). But here's the trace I get when it crashes
right at the first Ctrl+C:


I doubt this has anything to do with the recent changes as I can also
reproduce the crash with 2.1.3.

BTW, the backtrace you show is what lyx spits out automatically. I don't
know from which thread that backtrace is taken (I also am very skeptical
about this kde-ish automatic bt thingie), but if you directly run lyx
with gdb, you would get the following (more appropriate) backtrace:


Thank you for the info (the above one-line traces came from gdb).



Indeed, this has to do with the general problem of copying macros and
how the various structures are carried on when copying.


OK for the fact that this is not a regression, but why should it be 
different depending on whether preview is on or off?




The attached patch avoids the crash for me (at least I don't get any
crash even after hitting Ctrl+C one hundred times).



Yes, I confirm, thank you.

Re: test of math previews

2015-06-23 Thread Guillaume M-M


Le 23/06/2015 10:46, Enrico Forestieri a écrit :

On Tue, Jun 23, 2015 at 11:18:56AM +0200, Enrico Forestieri wrote:

On Tue, Jun 23, 2015 at 02:44:00AM +0100, Guillaume M-M wrote:


Still there at cd046f0e (master). But here's the trace I get when it crashes
right at the first Ctrl+C:


I doubt this has anything to do with the recent changes as I can also
reproduce the crash with 2.1.3.

BTW, the backtrace you show is what lyx spits out automatically. I don't
know from which thread that backtrace is taken (I also am very skeptical
about this kde-ish automatic bt thingie), but if you directly run lyx
with gdb, you would get the following (more appropriate) backtrace:


Thank you for the info (the above one-line traces came from gdb).



Indeed, this has to do with the general problem of copying macros and
how the various structures are carried on when copying.


OK for the fact that this is not a regression, but why should it be 
different depending on whether preview is on or off?




The attached patch avoids the crash for me (at least I don't get any
crash even after hitting Ctrl+C one hundred times).



Yes, I confirm, thank you.

Re: test of math previews

Three bugs in the current stable (93c0512b). The third one has an easy 
fix (and also a very trivial partial fix if you want to move forward 
with the release). The first two could be postponed after the release, 
or maybe they are trivial as well to Enrico. Found the first two while 
testing my solution to the third one.


1) SIGSEGV with previews (no math macros involved). I believe this is 
the one I mentioned in a previous message. See the attached 
lyx-preview-sigsegv.lyx for instructions.



2) Closing a file whose previews are being generated results in an error 
dialog Could not remove the temporary directory 
/tmp/lyx_tmpdir.LXSnBrW17125 and the following output on the terminal:


Warning: Could not remove temporary directory

Could not remove the temporary directory 
/tmp/lyx_tmpdir.LXSnBrW17125/lyx_tmpbuf0
Warning: Warning in extract_resolution! Unable to open 
lyxpreviewQ17125_legacy.log

Warning: type 'exceptions.IOError',IOError(2, 'No such file or directory')
Warning: check_latex_log: Unable to open lyxpreviewQ17125_legacy.log
Warning: type 'exceptions.IOError',IOError(2, 'No such file or directory')
Warning: Warning in legacy_extract_metrics_info! Unable to open 
lyxpreviewQ17125_legacy.log

Warning: type 'exceptions.IOError',IOError(2, 'No such file or directory')
Error: Failed to extract metrics info from lyxpreviewQ17125_legacy.log

So there's some additional cleanup to do now when closing a file.


3) Previews have the incorrect size with layouts that offer font sizes 
other than 1[0-2]pt (lyx-preview-fontsize.lyx). The legacy method offers 
a function that retrieves the actual font size and calculates the actual 
dpi. Attached is a patch (extract_resolution.diff) that imports this 
function in the new script.


(It's possible to just replace:
documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
with:
documentclass_re = re.compile((documentclass\[)([0-9]+pt,?)(.+))
but this does not take into account custom classes, options, preambles, 
etc. If this path is retained, here's the result of $grep FontSize 
*.layout:


achemso.layout: FontSize10|11|12
acmsiggraph.layout:  FontSize   9|10|11|12
agutex.layout:  FontSize10|11|12
amsart.layout:  FontSize   8|9|10|11|12
amsbook.layout: FontSize   8|9|10|11|12
apa6.layout:FontSize  10|11|12
apa.layout: FontSize  6|8|10|12
broadway.layout:FontSize12
dtk.layout: FontSize  default # only 10pt in fact of A5
elsarticle.layout:  FontSize10|11|12
elsart.layout:#  FontSize default   # controlled by class
entcs.layout:   FontSize   11
extarticle.layout:  FontSize  8|9|10|11|12|14|17|20
extbook.layout: FontSize  8|9|10|11|12|14|17|20
extletter.layout:   FontSize  8|9|10|11|12|14|17|20
extreport.layout:   FontSize  8|9|10|11|12|14|17|20
foils.layout:   FontSize  17|20|25|30
hollywood.layout:   FontSize  12
IEEEtran-CompSoc.layout:  FontSize  12
IEEEtran.layout:  FontSize  9|10|11|12
iopart.layout:  FontSize10|12
jasatex.layout: FontSize10|11|12
latex8.layout:   FontSize 10
ltugboat.layout:FontSize  default # only 11pt
memoir.layout:  FontSize 9|10|11|12|14|17
powerdot.layout:  FontSize 
size=8|size=9|size=10|size=11|size=12|size=14|size=17|size=20

sciposter.layout:   FontSize  14|17|20|25|30|36
seminar.layout: FontSize8|9|10|11|12|14|17
siamltex.layout:FontSize   8|9|10|11|12
sigplanconf.layout:  FontSize   9|10|11
slides.layout:  FontSize   |
svmono.layout:  FontSize10
svmult.layout:  FontSize

In particular, Powerdot has a special syntax, but the default font size 
is too big anyways (magnification=2000) so it's better to compute the 
font size from the log file, and this is precisely what 
extract_resolution already does.)


lyx-preview-sigsegv.lyx
Description: application/lyx


lyx-preview-fontsize.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 9775b0e..f9ee3b3 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -77,7 +77,7 @@
 
 import getopt, glob, os, re, shutil, string, sys
 
-from legacy_lyxpreview2ppm import legacy_conversion_step1
+from legacy_lyxpreview2ppm import legacy_conversion_step1, extract_resolution
 
 from lyxpreview_tools import bibtex_commands, check_latex_log, copyfileobj, \
  error, filter_pages, find_exe, find_exe_or_terminate, \
@@ -159,7 +159,6 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
 def_re = re.compile(r(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z]+))
 
 tmp = mkstemp()
@@ -167,14

Re: test of math previews


Le 23/06/2015 02:34, Guillaume M-M a écrit :

Another segfault in the stable branch involving previews (and master as
well). When Instant preview is on and one copies a formula, it randomly
crashes. In the attached, select the math inset and hold Ctrl+C until it
segfaults. Sometimes it happens on the first press. This is pretty
annoying because it's not a corner case at all. There is a very simple
math macro, but it does not crash with preview off.

The positive side is that I am getting a glimpse that having instant
previews that actually work is very pleasing :)


Stack trace:

Stable:

0x76360a48 in std::basic_stringwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t
 ::basic_string(std::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t  const) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6

Master:

0x0044e2e2 in ?? ()


Does not take cd046f0e into account. Let me test again.

Re: test of math previews

Another segfault in the stable branch involving previews (and master as 
well). When Instant preview is on and one copies a formula, it randomly 
crashes. In the attached, select the math inset and hold Ctrl+C until it 
segfaults. Sometimes it happens on the first press. This is pretty 
annoying because it's not a corner case at all. There is a very simple 
math macro, but it does not crash with preview off.


The positive side is that I am getting a glimpse that having instant 
previews that actually work is very pleasing :)



Stack trace:

Stable:

0x76360a48 in std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t 
::basic_string(std::basic_stringwchar_t, std::char_traitswchar_t, 
std::allocatorwchar_t  const) () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6


Master:

0x0044e2e2 in ?? ()


lyx-preview-sigsegv3.lyx
Description: application/lyx

Re: test of math previews


Le 23/06/2015 02:36, Guillaume M-M a écrit :

Le 23/06/2015 02:34, Guillaume M-M a écrit :

Another segfault in the stable branch involving previews (and master as
well). When Instant preview is on and one copies a formula, it randomly
crashes. In the attached, select the math inset and hold Ctrl+C until it
segfaults. Sometimes it happens on the first press. This is pretty
annoying because it's not a corner case at all. There is a very simple
math macro, but it does not crash with preview off.

The positive side is that I am getting a glimpse that having instant
previews that actually work is very pleasing :)


Stack trace:

Stable:

0x76360a48 in std::basic_stringwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t
 ::basic_string(std::basic_stringwchar_t, std::char_traitswchar_t,
std::allocatorwchar_t  const) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6

Master:

0x0044e2e2 in ?? ()


Does not take cd046f0e into account. Let me test again.





Still there at cd046f0e (master). But here's the trace I get when it 
crashes right at the first Ctrl+C:



(  1) src/lyx: src/lyx() [0x9c14e8]
(  2) src/lyx: src/lyx() [0x9c257b]
(  3) src/lyx: src/lyx() [0x9c2fc3]
(  4) src/lyx: src/lyx() [0xa2c091]
(  5) src/lyx: src/lyx() [0x9bfe57]
(  6) src/lyx: src/lyx() [0x5ef49a]
(  7) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(+0x352f0) [0x7f15240122f0]
(  8) src/lyx: std::basic_stringwchar_t, std::char_traitswchar_t, 
std::allocatorwchar_t ::basic_string(std::basic_stringwchar_t, 
std::char_traitswchar_t, std::allocatorwchar_t  const)

(  9) src/lyx: src/lyx() [0x7fb7da]
( 10) src/lyx: src/lyx() [0x7f1f9e]
( 11) src/lyx: src/lyx() [0x819460]
( 12) src/lyx: src/lyx() [0x7e25e0]
( 13) src/lyx: src/lyx() [0x819474]
( 14) src/lyx: src/lyx() [0x79d36c]
( 15) src/lyx: src/lyx() [0x7acfd1]
( 16) src/lyx: src/lyx() [0x65e239]
( 17) src/lyx: src/lyx() [0x644f58]
( 18) src/lyx: src/lyx() [0x647093]
( 19) src/lyx: src/lyx() [0x4b07c4]
( 20) src/lyx: src/lyx() [0x54e75e]
( 21) src/lyx: src/lyx() [0x54f840]
( 22) src/lyx: src/lyx() [0x54f929]
( 23) src/lyx: src/lyx() [0x6b0cda]
( 24) src/lyx: src/lyx() [0x993d06]
( 25) src/lyx: src/lyx() [0x872032]
( 26) src/lyx: src/lyx() [0x53fd7e]
( 27) src/lyx: src/lyx() [0x9f260e]
( 28) src/lyx: src/lyx() [0xa0a048]
( 29) src/lyx: src/lyx() [0x9d603f]
( 30) src/lyx: src/lyx() [0x9c5eb5]
( 31) src/lyx: src/lyx() [0x5edd5a]
( 32) src/lyx: src/lyx() [0x9c83d3]
( 33) src/lyx: src/lyx() [0xa1dd25]
( 34) src/lyx: src/lyx() [0xa2073c]
( 35) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 36) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*)
( 37) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractScrollArea::event(QEvent*)

( 38) src/lyx: src/lyx() [0xa20f14]
( 39) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 40) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::notify(QObject*, QEvent*)

( 41) src/lyx: src/lyx() [0x9d760a]
( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x26e023) [0x7f1525333023]
( 44) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x26e4c2) [0x7f15253334c2]
( 45) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 46) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f1525335ba2]
( 47) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d) 
[0x7f1523b13c3d]
( 48) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f1523b13f20]
( 49) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) 
[0x7f1523b13fcc]
( 50) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
( 51) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270c66) [0x7f1525335c66]
( 52) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
( 53) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag)

( 54) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec()
( 55) src/lyx: src/lyx() [0x9c33a9]
( 56) src/lyx: src/lyx() [0x5f7e85]
( 57) src/lyx: src/lyx() [0x43a64e]
( 58) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f1523ffda40]

( 59) src/lyx: src/lyx() [0x43a539]

Re: test of math previews

Three bugs in the current stable (93c0512b). The third one has an easy 
fix (and also a very trivial partial fix if you want to move forward 
with the release). The first two could be postponed after the release, 
or maybe they are trivial as well to Enrico. Found the first two while 
testing my solution to the third one.


1) SIGSEGV with previews (no math macros involved). I believe this is 
the one I mentioned in a previous message. See the attached 
lyx-preview-sigsegv.lyx for instructions.



2) Closing a file whose previews are being generated results in an error 
dialog "Could not remove the temporary directory 
/tmp/lyx_tmpdir.LXSnBrW17125" and the following output on the terminal:


Warning: Could not remove temporary directory

Could not remove the temporary directory 
/tmp/lyx_tmpdir.LXSnBrW17125/lyx_tmpbuf0
Warning: Warning in extract_resolution! Unable to open 
"lyxpreviewQ17125_legacy.log"

Warning: ,IOError(2, 'No such file or directory')
Warning: check_latex_log: Unable to open "lyxpreviewQ17125_legacy.log"
Warning: ,IOError(2, 'No such file or directory')
Warning: Warning in legacy_extract_metrics_info! Unable to open 
"lyxpreviewQ17125_legacy.log"

Warning: ,IOError(2, 'No such file or directory')
Error: Failed to extract metrics info from lyxpreviewQ17125_legacy.log

So there's some additional cleanup to do now when closing a file.


3) Previews have the incorrect size with layouts that offer font sizes 
other than 1[0-2]pt (lyx-preview-fontsize.lyx). The legacy method offers 
a function that retrieves the actual font size and calculates the actual 
dpi. Attached is a patch (extract_resolution.diff) that imports this 
function in the new script.


(It's possible to just replace:
documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
with:
documentclass_re = re.compile("(documentclass\[)([0-9]+pt,?)(.+)")
but this does not take into account custom classes, options, preambles, 
etc. If this path is retained, here's the result of $grep FontSize 
*.layout:


achemso.layout: FontSize10|11|12
acmsiggraph.layout:  FontSize   9|10|11|12
agutex.layout:  FontSize10|11|12
amsart.layout:  FontSize   8|9|10|11|12
amsbook.layout: FontSize   8|9|10|11|12
apa6.layout:FontSize  10|11|12
apa.layout: FontSize  6|8|10|12
broadway.layout:FontSize12
dtk.layout: FontSize  default # only 10pt in fact of A5
elsarticle.layout:  FontSize10|11|12
elsart.layout:#  FontSize "default"   # controlled by class
entcs.layout:   FontSize   11
extarticle.layout:  FontSize  8|9|10|11|12|14|17|20
extbook.layout: FontSize  8|9|10|11|12|14|17|20
extletter.layout:   FontSize  8|9|10|11|12|14|17|20
extreport.layout:   FontSize  8|9|10|11|12|14|17|20
foils.layout:   FontSize  17|20|25|30
hollywood.layout:   FontSize  12
IEEEtran-CompSoc.layout:  FontSize  12
IEEEtran.layout:  FontSize  9|10|11|12
iopart.layout:  FontSize10|12
jasatex.layout: FontSize10|11|12
latex8.layout:   FontSize 10
ltugboat.layout:FontSize  default # only 11pt
memoir.layout:  FontSize 9|10|11|12|14|17
powerdot.layout:  FontSize 
size=8|size=9|size=10|size=11|size=12|size=14|size=17|size=20

sciposter.layout:   FontSize  14|17|20|25|30|36
seminar.layout: FontSize8|9|10|11|12|14|17
siamltex.layout:FontSize   8|9|10|11|12
sigplanconf.layout:  FontSize   9|10|11
slides.layout:  FontSize   |
svmono.layout:  FontSize10
svmult.layout:  FontSize""

In particular, Powerdot has a special syntax, but the default font size 
is too big anyways (magnification=2000) so it's better to compute the 
font size from the log file, and this is precisely what 
extract_resolution already does.)


lyx-preview-sigsegv.lyx
Description: application/lyx


lyx-preview-fontsize.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index 9775b0e..f9ee3b3 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -77,7 +77,7 @@
 
 import getopt, glob, os, re, shutil, string, sys
 
-from legacy_lyxpreview2ppm import legacy_conversion_step1
+from legacy_lyxpreview2ppm import legacy_conversion_step1, extract_resolution
 
 from lyxpreview_tools import bibtex_commands, check_latex_log, copyfileobj, \
  error, filter_pages, find_exe, find_exe_or_terminate, \
@@ -159,7 +159,6 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
 def_re = re.compile(r"(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z]+)")
 
 tmp = mkstemp()
@@ -167,14 +166,9 @@ def fix_latex_file(latex_file, pdf_output):

Re: test of math previews

Another segfault in the stable branch involving previews (and master as 
well). When Instant preview is on and one copies a formula, it randomly 
crashes. In the attached, select the math inset and hold Ctrl+C until it 
segfaults. Sometimes it happens on the first press. This is pretty 
annoying because it's not a corner case at all. There is a very simple 
math macro, but it does not crash with preview off.


The positive side is that I am getting a glimpse that having instant 
previews that actually work is very pleasing :)



Stack trace:

Stable:

0x76360a48 in std::basic_string::basic_string(std::basic_string const&) () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6


Master:

0x0044e2e2 in ?? ()


lyx-preview-sigsegv3.lyx
Description: application/lyx

Re: test of math previews


Le 23/06/2015 02:34, Guillaume M-M a écrit :

Another segfault in the stable branch involving previews (and master as
well). When Instant preview is on and one copies a formula, it randomly
crashes. In the attached, select the math inset and hold Ctrl+C until it
segfaults. Sometimes it happens on the first press. This is pretty
annoying because it's not a corner case at all. There is a very simple
math macro, but it does not crash with preview off.

The positive side is that I am getting a glimpse that having instant
previews that actually work is very pleasing :)


Stack trace:

Stable:

0x76360a48 in std::basic_string<wchar_t,
std::char_traits, std::allocator
 >::basic_string(std::basic_string<wchar_t, std::char_traits,
std::allocator > const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6

Master:

0x0044e2e2 in ?? ()


Does not take cd046f0e into account. Let me test again.

Re: test of math previews


Le 23/06/2015 02:36, Guillaume M-M a écrit :

Le 23/06/2015 02:34, Guillaume M-M a écrit :

Another segfault in the stable branch involving previews (and master as
well). When Instant preview is on and one copies a formula, it randomly
crashes. In the attached, select the math inset and hold Ctrl+C until it
segfaults. Sometimes it happens on the first press. This is pretty
annoying because it's not a corner case at all. There is a very simple
math macro, but it does not crash with preview off.

The positive side is that I am getting a glimpse that having instant
previews that actually work is very pleasing :)


Stack trace:

Stable:

0x76360a48 in std::basic_string<wchar_t,
std::char_traits, std::allocator
 >::basic_string(std::basic_string<wchar_t, std::char_traits,
std::allocator > const&) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6

Master:

0x0044e2e2 in ?? ()


Does not take cd046f0e into account. Let me test again.





Still there at cd046f0e (master). But here's the trace I get when it 
crashes right at the first Ctrl+C:



(  1) src/lyx: src/lyx() [0x9c14e8]
(  2) src/lyx: src/lyx() [0x9c257b]
(  3) src/lyx: src/lyx() [0x9c2fc3]
(  4) src/lyx: src/lyx() [0xa2c091]
(  5) src/lyx: src/lyx() [0x9bfe57]
(  6) src/lyx: src/lyx() [0x5ef49a]
(  7) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(+0x352f0) [0x7f15240122f0]
(  8) src/lyx: std::basic_string<wchar_t, std::char_traits, 
std::allocator >::basic_string(std::basic_string<wchar_t, 
std::char_traits, std::allocator > const&)

(  9) src/lyx: src/lyx() [0x7fb7da]
( 10) src/lyx: src/lyx() [0x7f1f9e]
( 11) src/lyx: src/lyx() [0x819460]
( 12) src/lyx: src/lyx() [0x7e25e0]
( 13) src/lyx: src/lyx() [0x819474]
( 14) src/lyx: src/lyx() [0x79d36c]
( 15) src/lyx: src/lyx() [0x7acfd1]
( 16) src/lyx: src/lyx() [0x65e239]
( 17) src/lyx: src/lyx() [0x644f58]
( 18) src/lyx: src/lyx() [0x647093]
( 19) src/lyx: src/lyx() [0x4b07c4]
( 20) src/lyx: src/lyx() [0x54e75e]
( 21) src/lyx: src/lyx() [0x54f840]
( 22) src/lyx: src/lyx() [0x54f929]
( 23) src/lyx: src/lyx() [0x6b0cda]
( 24) src/lyx: src/lyx() [0x993d06]
( 25) src/lyx: src/lyx() [0x872032]
( 26) src/lyx: src/lyx() [0x53fd7e]
( 27) src/lyx: src/lyx() [0x9f260e]
( 28) src/lyx: src/lyx() [0xa0a048]
( 29) src/lyx: src/lyx() [0x9d603f]
( 30) src/lyx: src/lyx() [0x9c5eb5]
( 31) src/lyx: src/lyx() [0x5edd5a]
( 32) src/lyx: src/lyx() [0x9c83d3]
( 33) src/lyx: src/lyx() [0xa1dd25]
( 34) src/lyx: src/lyx() [0xa2073c]
( 35) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 36) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*)
( 37) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractScrollArea::event(QEvent*)

( 38) src/lyx: src/lyx() [0xa20f14]
( 39) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 40) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::notify(QObject*, QEvent*)

( 41) src/lyx: src/lyx() [0x9d760a]
( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x26e023) [0x7f1525333023]
( 44) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x26e4c2) [0x7f15253334c2]
( 45) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 46) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f1525335ba2]
( 47) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d) 
[0x7f1523b13c3d]
( 48) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f1523b13f20]
( 49) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) 
[0x7f1523b13fcc]
( 50) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventDispatcherGlib::processEvents(QFlags)
( 51) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270c66) [0x7f1525335c66]
( 52) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventLoop::processEvents(QFlags)
( 53) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QEventLoop::exec(QFlags)

( 54) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec()
( 55) src/lyx: src/lyx() [0x9c33a9]
( 56) src/lyx: src/lyx() [0x5f7e85]
( 57) src/lyx: src/lyx() [0x43a64e]
( 58) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f1523ffda40]

( 59) src/lyx: src/lyx() [0x43a539]

Re: test of math previews


Le 20/06/2015 01:11, Enrico Forestieri a écrit :

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:


Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten

from the list. The third inset works and is meant as a control. All 3 work

without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my thourough test is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


Hi Guillaume,


I tested the latest stable that seems to include the patches. As I already
told Enrico, sorry for the delay as I did not have much free time until now.

Thank you very much, this is really quick now. Thanks also for the timer for
generating previews. Also I only had 1 segmentation error, which I could not
reproduce unfortunately. It happened after changing from Instant preview:
On to No maths and zooming. But probably it's part of the bigger issues
with math macros, and again I could not reproduce.


Yes, I also think this is not specifically related to previews.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro is
not defined. I had many bugs of this style, so let's hope that this one is
representative, otherwise I'll come back with more errors.


Yes, I think it is. I was not taking into account that macros could also
occur in the arguments of other macros. Should be fixed in master now.


lyx-bug-renewcommandx4.lyx: here we have again an error where renewcommandx
is used while the macro is not defined beforehand. If it is really too error
prone to keep track of what has already been defined then it is easy to work
around by using \definecommandx:
   \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx previews
(but maybe you have other reasons for distinguishing the cases newcommandx
and renewcommandx that I don't understand).


This was due to a stupid typo and should also be fixed in master.
As regards your proposal, I don't like defining commands only to immediately
redefining them. And the fix was quite straightforward.


Good. We are down to 14 failing previews. (examples at the end)




Lastly I see that you prevent loading the microtype package by redefining
\usepackage as you described earlier in the thread. While your redefinition
of \usepackage seems to be very careful, I still think that passing the
option draft to microtype is more reliable in case the user actually uses
macros from microtype (in addition there's no need to test whether the user
loads microtype).


I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.


Yes, and the draft option disables the microtype features completely 
according to the manual. That's also why I mentioned it. But it's your call.





I don't want to be too much of a PITA so here's a patch to
lyxpreview2bitmap.py that integrates my above two suggestions and solves the
above two problems. (The bug in lyx-bug-undefined.lyx has to be addressed
separately.) Parsing a file using regexps is always delicate so I think it's
good that with my patch there are fewer of these. I do not think that I
missed any subtlety in the existing code, but in any case you don't need to
accept it as is.


In this particular case the regexp was simply wrong.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening the
preview is not generated because \Coloneqq is not defined. This looks like
the bug that you are referring to in your message where packages for symbols
are not properly loaded. But, notice that the preview is correctly generated
on a second time, when entering and leaving the math inset. So maybe it's
easier to fix than it seemed. But indeed it's not a regression.


Yes, this has always been

Re: test of math previews


Le 20/06/2015 15:58, Enrico Forestieri a écrit :

On Sat, Jun 20, 2015 at 08:14:03AM +0100, Guillaume M-M wrote:

Le 20/06/2015 01:11, Enrico Forestieri a écrit :

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:


Lastly I see that you prevent loading the microtype package by redefining
\usepackage as you described earlier in the thread. While your redefinition
of \usepackage seems to be very careful, I still think that passing the
option draft to microtype is more reliable in case the user actually uses
macros from microtype (in addition there's no need to test whether the user
loads microtype).


I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.


Yes, and the draft option disables the microtype features completely
according to the manual. That's also why I mentioned it. But it's your call.


In this case I will reconsider. Please, let me perform some checks first.


Please, try again with master and report back. The required changes to
address these glitches are straightforward and maybe Richard will allow
backporting them to stable.



I simply applied your patch 98a5072a to stable directly (quicker to
recompile).


You were missing the amendment at b610c13f that solves the issue with
lyx-bug-undefined5.lyx.


Well yes unfortunately b610c13f did not exist when I pulled and 
recompiled. But I think I should also test master when I have more time.





lyx-bug-undefined3.lyx: macros inside nested macro definitions (!) are not
taken into account.


I knew you would have been able to spot another corner case :)
This should also be solved at cabc7c4b.


lyx-bug-undefined4.lyx: a combination of two bugs I think. In particular,
our friend \renewcommandx again. More detailed comments in the files.


Here it was going as follows. The script detected a postscript special
in the second preview snippet and thus decided to use the legacy route
through dvips for obtaining the preview instead of directly using dvipng.
In order to do that, the affected snippets are extracted from the original
latex file. Now, in the original file the second snippet was correctly
using \renewcommandx because the macro was already defined in the first
snippet, but now it was incorrect, of course. Also solved at cabc7c4b.


lyx-bug-undefined5.lyx: the arguments are only scanned on the first
occurrence of a macro.


This had already been taken into account at b610c13f.

For your convenience I am attaching the overall set of patches for
the stable branch. Please, let me know if you are able to find some
other remaining glitches :)



Thank you for the convenience.

I have no other issue to report for stable, Enrico wins :)

Re: test of math previews


Le 20/06/2015 01:11, Enrico Forestieri a écrit :

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:


Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten

>from the list. The third inset works and is meant as a control. All 3 work

without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my "thourough test" is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


Hi Guillaume,


I tested the latest stable that seems to include the patches. As I already
told Enrico, sorry for the delay as I did not have much free time until now.

Thank you very much, this is really quick now. Thanks also for the timer for
generating previews. Also I only had 1 segmentation error, which I could not
reproduce unfortunately. It happened after changing from "Instant preview:
On" to "No maths" and zooming. But probably it's part of the bigger issues
with math macros, and again I could not reproduce.


Yes, I also think this is not specifically related to previews.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro is
not defined. I had many bugs of this style, so let's hope that this one is
representative, otherwise I'll come back with more errors.


Yes, I think it is. I was not taking into account that macros could also
occur in the arguments of other macros. Should be fixed in master now.


lyx-bug-renewcommandx4.lyx: here we have again an error where renewcommandx
is used while the macro is not defined beforehand. If it is really too error
prone to keep track of what has already been defined then it is easy to work
around by using \definecommandx:
   \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx previews
(but maybe you have other reasons for distinguishing the cases newcommandx
and renewcommandx that I don't understand).


This was due to a stupid typo and should also be fixed in master.
As regards your proposal, I don't like defining commands only to immediately
redefining them. And the fix was quite straightforward.


Good. We are down to 14 failing previews. (examples at the end)




Lastly I see that you prevent loading the microtype package by redefining
\usepackage as you described earlier in the thread. While your redefinition
of \usepackage seems to be very careful, I still think that passing the
option draft to microtype is more reliable in case the user actually uses
macros from microtype (in addition there's no need to test whether the user
loads microtype).


I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.


Yes, and the draft option disables the microtype features completely 
according to the manual. That's also why I mentioned it. But it's your call.





I don't want to be too much of a PITA so here's a patch to
lyxpreview2bitmap.py that integrates my above two suggestions and solves the
above two problems. (The bug in lyx-bug-undefined.lyx has to be addressed
separately.) Parsing a file using regexps is always delicate so I think it's
good that with my patch there are fewer of these. I do not think that I
missed any subtlety in the existing code, but in any case you don't need to
accept it as is.


In this particular case the regexp was simply wrong.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening the
preview is not generated because \Coloneqq is not defined. This looks like
the bug that you are referring to in your message where packages for symbols
are not properly loaded. But, notice that the preview is correctly generated
on a second time, when entering and leaving the math inset. So maybe it's
easier to fix than it seemed. But indeed it's

Re: test of math previews


Le 20/06/2015 15:58, Enrico Forestieri a écrit :

On Sat, Jun 20, 2015 at 08:14:03AM +0100, Guillaume M-M wrote:

Le 20/06/2015 01:11, Enrico Forestieri a écrit :

On Fri, Jun 19, 2015 at 04:50:43PM +0100, Guillaume M-M wrote:


Lastly I see that you prevent loading the microtype package by redefining
\usepackage as you described earlier in the thread. While your redefinition
of \usepackage seems to be very careful, I still think that passing the
option draft to microtype is more reliable in case the user actually uses
macros from microtype (in addition there's no need to test whether the user
loads microtype).


I am concerned with the fact that in dvi mode the microtype package
considerably slows down the processing and prefer to not allow it.


Yes, and the draft option disables the microtype features completely
according to the manual. That's also why I mentioned it. But it's your call.


In this case I will reconsider. Please, let me perform some checks first.


Please, try again with master and report back. The required changes to
address these glitches are straightforward and maybe Richard will allow
backporting them to stable.



I simply applied your patch 98a5072a to stable directly (quicker to
recompile).


You were missing the amendment at b610c13f that solves the issue with
lyx-bug-undefined5.lyx.


Well yes unfortunately b610c13f did not exist when I pulled and 
recompiled. But I think I should also test master when I have more time.





lyx-bug-undefined3.lyx: macros inside nested macro definitions (!) are not
taken into account.


I knew you would have been able to spot another corner case :)
This should also be solved at cabc7c4b.


lyx-bug-undefined4.lyx: a combination of two bugs I think. In particular,
our friend \renewcommandx again. More detailed comments in the files.


Here it was going as follows. The script detected a postscript special
in the second preview snippet and thus decided to use the legacy route
through dvips for obtaining the preview instead of directly using dvipng.
In order to do that, the affected snippets are extracted from the original
latex file. Now, in the original file the second snippet was correctly
using \renewcommandx because the macro was already defined in the first
snippet, but now it was incorrect, of course. Also solved at cabc7c4b.


lyx-bug-undefined5.lyx: the arguments are only scanned on the first
occurrence of a macro.


This had already been taken into account at b610c13f.

For your convenience I am attaching the overall set of patches for
the stable branch. Please, let me know if you are able to find some
other remaining glitches :)



Thank you for the convenience.

I have no other issue to report for stable, Enrico wins :)

Re: test of math previews

2015-06-19 Thread Guillaume M-M


Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
from the list. The third inset works and is meant as a control. All 3 work
without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my thourough test is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


I tested the latest stable that seems to include the patches. As I 
already told Enrico, sorry for the delay as I did not have much free 
time until now.


Thank you very much, this is really quick now. Thanks also for the timer 
for generating previews. Also I only had 1 segmentation error, which I 
could not reproduce unfortunately. It happened after changing from 
Instant preview: On to No maths and zooming. But probably it's part 
of the bigger issues with math macros, and again I could not reproduce.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro 
is not defined. I had many bugs of this style, so let's hope that this 
one is representative, otherwise I'll come back with more errors.


lyx-bug-renewcommandx4.lyx: here we have again an error where 
renewcommandx is used while the macro is not defined beforehand. If it 
is really too error prone to keep track of what has already been defined 
then it is easy to work around by using \definecommandx:

  \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx 
previews (but maybe you have other reasons for distinguishing the cases 
newcommandx and renewcommandx that I don't understand).


Lastly I see that you prevent loading the microtype package by 
redefining \usepackage as you described earlier in the thread. While 
your redefinition of \usepackage seems to be very careful, I still think 
that passing the option draft to microtype is more reliable in case the 
user actually uses macros from microtype (in addition there's no need to 
test whether the user loads microtype).


I don't want to be too much of a PITA so here's a patch to 
lyxpreview2bitmap.py that integrates my above two suggestions and solves 
the above two problems. (The bug in lyx-bug-undefined.lyx has to be 
addressed separately.) Parsing a file using regexps is always delicate 
so I think it's good that with my patch there are fewer of these. I do 
not think that I missed any subtlety in the existing code, but in any 
case you don't need to accept it as is.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening 
the preview is not generated because \Coloneqq is not defined. This 
looks like the bug that you are referring to in your message where 
packages for symbols are not properly loaded. But, notice that the 
preview is correctly generated on a second time, when entering and 
leaving the math inset. So maybe it's easier to fix than it seemed. But 
indeed it's not a regression.



Best regards
Guillaume



lyx-bug-undefined.lyx
Description: application/lyx


lyx-bug-renewcommandx4.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index a7d7623..fe9bea1 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,65 +159,35 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
-def_re = re.compile(r(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z])(.+))
-usepackage_re = re.compile(usepackage)
-userpreamble_re = re.compile(User specified LaTeX commands)
-enduserpreamble_re = re.compile(makeatother)
+documentclass_re = re.compile((documentclass))
+documentclass_pt_re = re.compile((documentclass\[)(1[012]pt,?)(.+))
+def_re = re.compile(r(\\newcommandx|\\renewcommandx

Re: test of math previews

2015-06-19 Thread Guillaume M-M


Le 07/06/2015 12:49, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 08:07:12PM +0100, Guillaume M-M wrote:


lyx-preview-macros2-failure.lyx shows two cases where a macro is forgotten
from the list. The third inset works and is meant as a control. All 3 work
without the patch.


Here I was forgetting to also scan nested insets.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is
activated. Does not assert without the patch.


Here I did not account for the fact that also the macros defined in the
symbols file are spotted. However, they do not have a valid DataMacro
and this was causing the assert.

Note that there is another bug here, but it is not a regression as it
seems to be like that since ever (I checked with lyx versions since 1.3).
The bug is that when using a symbol defined in the symbols file and this
symbol requires a certain package, this requirement is not taken into
account when generating the tex file for preview and thus latex fails.


Notice that my "thourough test" is basically loading my current paper with
preview on.


I think that your paper is a very valid test case for macros ;)

The attached patch solves all of the above problems (and also the segfault
you report separately) for me. I am also attaching the patch for #9354
accordingly updated. Please test both and report the issues you find.
If your paper pass the tests, I think they are good for stable ;)



Hello again,


I tested the latest stable that seems to include the patches. As I 
already told Enrico, sorry for the delay as I did not have much free 
time until now.


Thank you very much, this is really quick now. Thanks also for the timer 
for generating previews. Also I only had 1 segmentation error, which I 
could not reproduce unfortunately. It happened after changing from 
"Instant preview: On" to "No maths" and zooming. But probably it's part 
of the bigger issues with math macros, and again I could not reproduce.


Here are two examples that still fail.

lyx-bug-undefined.lyx: the macro used in the argument of another macro 
is not defined. I had many bugs of this style, so let's hope that this 
one is representative, otherwise I'll come back with more errors.


lyx-bug-renewcommandx4.lyx: here we have again an error where 
renewcommandx is used while the macro is not defined beforehand. If it 
is really too error prone to keep track of what has already been defined 
then it is easy to work around by using \definecommandx:

  \def\definecommandx#1{\providecommand#1{}\renewcommandx#1}
This seems to work at least for the way newcommandx is used in lyx 
previews (but maybe you have other reasons for distinguishing the cases 
newcommandx and renewcommandx that I don't understand).


Lastly I see that you prevent loading the microtype package by 
redefining \usepackage as you described earlier in the thread. While 
your redefinition of \usepackage seems to be very careful, I still think 
that passing the option draft to microtype is more reliable in case the 
user actually uses macros from microtype (in addition there's no need to 
test whether the user loads microtype).


I don't want to be too much of a PITA so here's a patch to 
lyxpreview2bitmap.py that integrates my above two suggestions and solves 
the above two problems. (The bug in lyx-bug-undefined.lyx has to be 
addressed separately.) Parsing a file using regexps is always delicate 
so I think it's good that with my patch there are fewer of these. I do 
not think that I missed any subtlety in the existing code, but in any 
case you don't need to accept it as is.


Also, lyx-preview-macros-2-lassert.lyx no longer lasserts but on opening 
the preview is not generated because \Coloneqq is not defined. This 
looks like the bug that you are referring to in your message where 
packages for symbols are not properly loaded. But, notice that the 
preview is correctly generated on a second time, when entering and 
leaving the math inset. So maybe it's easier to fix than it seemed. But 
indeed it's not a regression.



Best regards
Guillaume



lyx-bug-undefined.lyx
Description: application/lyx


lyx-bug-renewcommandx4.lyx
Description: application/lyx
diff --git a/lib/scripts/lyxpreview2bitmap.py b/lib/scripts/lyxpreview2bitmap.py
index a7d7623..fe9bea1 100755
--- a/lib/scripts/lyxpreview2bitmap.py
+++ b/lib/scripts/lyxpreview2bitmap.py
@@ -159,65 +159,35 @@ def extract_metrics_info(dvipng_stdout):
 
 
 def fix_latex_file(latex_file, pdf_output):
-documentclass_re = re.compile("(documentclass\[)(1[012]pt,?)(.+)")
-def_re = re.compile(r"(\\newcommandx|\\global\\long\\def)(\\[a-zA-Z])(.+)")
-usepackage_re = re.compile("usepackage")
-userpreamble_re = re.compile("User specified LaTeX commands")
-enduserpreamble_re = re.compile("makeatother")
+documentclass_re = re.compile("(documentclass)")
+documentclass_pt_re = re.

Re: test of math previews


Le 06/06/2015 18:12, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 03:23:48PM +0200, Kornel Benko wrote:


Am Samstag, 6. Juni 2015 um 13:13:22, schrieb Enrico Forestieri for...@lyx.org

+void InsetMathHull::usedMacros(MathData const  md, MacroNameSet  macros) 
const
+{
+   for (size_t i = 0; i  md.size(); ++i) {
+   MathMacro * mi = const_castMathMacro 
*(md[i].nucleus()-asMacro());
+   if (mi) {
+   macros.insert(mi-name());
+   usedMacros(mi-definition(), macros);


I would change the order, to get the used macro first.


No, that is correct. The top level macro has to appear in the last position.

I failed to understand why that was not working but, most probably, it has
to do with the fact not all data is copied over to a cloned buffer.
However, I found a different way for collecting only the macros used
in a given math inset, so I did not investigate it further.

The attached patch for stable works for me and avoids the size explosion
when a very lot of macros are defined in a document. I count on Guillaume
to give it a thourough test. If he doesn't find glitches I will feel
confident about proposing to apply it for 2.1.4.



:)

lyx-preview-macros2-failure.lyx shows two cases where a macro is 
forgotten from the list. The third inset works and is meant as a 
control. All 3 work without the patch.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is 
activated. Does not assert without the patch.


Notice that my thourough test is basically loading my current paper 
with preview on.


lyx-preview-macros-2-failure.lyx
Description: application/lyx


lyx-preview-macros-2-lassert.lyx
Description: application/lyx

Re: test of math previews


Le 06/06/2015 18:12, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 03:23:48PM +0200, Kornel Benko wrote:


Am Samstag, 6. Juni 2015 um 13:13:22, schrieb Enrico Forestieri for...@lyx.org

+void InsetMathHull::usedMacros(MathData const  md, MacroNameSet  macros) 
const
+{
+   for (size_t i = 0; i  md.size(); ++i) {
+   MathMacro * mi = const_castMathMacro 
*(md[i].nucleus()-asMacro());
+   if (mi) {
+   macros.insert(mi-name());
+   usedMacros(mi-definition(), macros);


I would change the order, to get the used macro first.


No, that is correct. The top level macro has to appear in the last position.

I failed to understand why that was not working but, most probably, it has
to do with the fact not all data is copied over to a cloned buffer.
However, I found a different way for collecting only the macros used
in a given math inset, so I did not investigate it further.

The attached patch for stable works for me and avoids the size explosion
when a very lot of macros are defined in a document. I count on Guillaume
to give it a thourough test. If he doesn't find glitches I will feel
confident about proposing to apply it for 2.1.4.



Obvious one to test for


lyx-preview-macros-2-sigsegv.lyx
Description: application/lyx

Re: test of math previews


Le 06/06/2015 18:12, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 03:23:48PM +0200, Kornel Benko wrote:


Am Samstag, 6. Juni 2015 um 13:13:22, schrieb Enrico Forestieri 

+void InsetMathHull::usedMacros(MathData const & md, MacroNameSet & macros) 
const
+{
+   for (size_t i = 0; i < md.size(); ++i) {
+   MathMacro * mi = const_cast(md[i].nucleus()->asMacro());
+   if (mi) {
+   macros.insert(mi->name());
+   usedMacros(mi->definition(), macros);


I would change the order, to get the used macro first.


No, that is correct. The top level macro has to appear in the last position.

I failed to understand why that was not working but, most probably, it has
to do with the fact not all data is copied over to a cloned buffer.
However, I found a different way for collecting only the macros used
in a given math inset, so I did not investigate it further.

The attached patch for stable works for me and avoids the size explosion
when a very lot of macros are defined in a document. I count on Guillaume
to give it a thourough test. If he doesn't find glitches I will feel
confident about proposing to apply it for 2.1.4.



:)

lyx-preview-macros2-failure.lyx shows two cases where a macro is 
forgotten from the list. The third inset works and is meant as a 
control. All 3 work without the patch.


lyx-preview-macros2-lassert.lyx triggers an assertion when preview is 
activated. Does not assert without the patch.


Notice that my "thourough test" is basically loading my current paper 
with preview on.


lyx-preview-macros-2-failure.lyx
Description: application/lyx


lyx-preview-macros-2-lassert.lyx
Description: application/lyx

Re: test of math previews


Le 06/06/2015 18:12, Enrico Forestieri a écrit :

On Sat, Jun 06, 2015 at 03:23:48PM +0200, Kornel Benko wrote:


Am Samstag, 6. Juni 2015 um 13:13:22, schrieb Enrico Forestieri 

+void InsetMathHull::usedMacros(MathData const & md, MacroNameSet & macros) 
const
+{
+   for (size_t i = 0; i < md.size(); ++i) {
+   MathMacro * mi = const_cast(md[i].nucleus()->asMacro());
+   if (mi) {
+   macros.insert(mi->name());
+   usedMacros(mi->definition(), macros);


I would change the order, to get the used macro first.


No, that is correct. The top level macro has to appear in the last position.

I failed to understand why that was not working but, most probably, it has
to do with the fact not all data is copied over to a cloned buffer.
However, I found a different way for collecting only the macros used
in a given math inset, so I did not investigate it further.

The attached patch for stable works for me and avoids the size explosion
when a very lot of macros are defined in a document. I count on Guillaume
to give it a thourough test. If he doesn't find glitches I will feel
confident about proposing to apply it for 2.1.4.



Obvious one to test for


lyx-preview-macros-2-sigsegv.lyx
Description: application/lyx

Re: test of math previews

2015-06-05 Thread Guillaume M-M


Le 05/06/2015 08:14, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 07:32:03PM -0400, Richard Heck wrote:

On 06/04/2015 07:13 PM, Guillaume M-M wrote:


Bad news, it seems to forget that macros can use macros. With the attached
file the preview is as follows:

\begin{preview}
\global\long\def\b{\a}

$\b$
\end{preview}


I suspect this is why all macros are included.


Most probably. This leaves us pretty stuck with the problem caused by
having hundreds of macros. I will not commit any change to stable until
we find a good solution. After all, this is what already happens now
and it is not a regression. I think the complaint is due to the fact
that now also the previews get zoomed and this may cause relevant delays,


Enrico mentions a complaint. There seems to be a misunderstanding. The 
freeze on zoom is a regression in stable, while the time explosion was 
already there. This is only a factual report of the issues trying to be 
the most helpful. The reports are the outcome of my tests of the preview 
mechanism following Enrico's request of having his patch at 
http://www.lyx.org/trac/ticket/9354 tested.


In truth, I have no interest in full preview, only in the solution to 
#9354, and my tests concluded that there are no immediate issues with 
his patch, while I managed to find other issues---many thanks to Enrico 
and Jürgen for fixing them promptly. Fixing #9354 (preview inset does 
not work with math macros) in 2.1.4 would make the preview mechanism 
useful again in my context, avoiding the performance issues. (Especially 
because I cannot ask my collaborators to compile from git.) Apart from 
that, only this regression regarding the zoom/preview interaction 
remains regarding the stable branch (to summarise the thread, since you 
probably want to move forward with 2.1.4).


After this thread dies off, I may record the remaining important issues 
in the bug tracker, but again please do not regard such reports as 
complaints!





but I hope one is not zooming all the time.  And it starts to be a problem
when you have hundreds of macros, not a very common case, IMHO.



Indeed, to be precise, the freeze time does not seem to be linear in the 
number of macros (otherwise with ~35 macros and 700 insets one would 
have to wait ~5s for LyX to unfreeze, but I could observe that it was 
probably less than 0.5s in reality). However, the math manual is the 
other extreme because it only contains one macro, so it is not an 
accurate test either.

Re: test of math previews

2015-06-05 Thread Guillaume M-M


Le 05/06/2015 08:14, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 07:32:03PM -0400, Richard Heck wrote:

On 06/04/2015 07:13 PM, Guillaume M-M wrote:


Bad news, it seems to forget that macros can use macros. With the attached
file the preview is as follows:

\begin{preview}
\global\long\def\b{\a}

$\b$
\end{preview}


I suspect this is why all macros are included.


Most probably. This leaves us pretty stuck with the problem caused by
having hundreds of macros. I will not commit any change to stable until
we find a good solution. After all, this is what already happens now
and it is not a regression. I think the complaint is due to the fact
that now also the previews get zoomed and this may cause relevant delays,


Enrico mentions a "complaint". There seems to be a misunderstanding. The 
freeze on zoom is a regression in stable, while the time explosion was 
already there. This is only a factual report of the issues trying to be 
the most helpful. The reports are the outcome of my tests of the preview 
mechanism following Enrico's request of having his patch at 
<http://www.lyx.org/trac/ticket/9354> tested.


In truth, I have no interest in full preview, only in the solution to 
#9354, and my tests concluded that there are no immediate issues with 
his patch, while I managed to find other issues---many thanks to Enrico 
and Jürgen for fixing them promptly. Fixing #9354 (preview inset does 
not work with math macros) in 2.1.4 would make the preview mechanism 
useful again in my context, avoiding the performance issues. (Especially 
because I cannot ask my collaborators to compile from git.) Apart from 
that, only this regression regarding the zoom/preview interaction 
remains regarding the stable branch (to summarise the thread, since you 
probably want to move forward with 2.1.4).


After this thread dies off, I may record the remaining important issues 
in the bug tracker, but again please do not regard such reports as 
complaints!





but I hope one is not zooming all the time.  And it starts to be a problem
when you have hundreds of macros, not a very common case, IMHO.



Indeed, to be precise, the freeze time does not seem to be linear in the 
number of macros (otherwise with ~35 macros and 700 insets one would 
have to wait ~5s for LyX to unfreeze, but I could observe that it was 
probably less than 0.5s in reality). However, the math manual is the 
other extreme because it only contains one macro, so it is not an 
accurate test either.

Re: test of math previews


Le 04/06/2015 22:29, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 06:33:28PM +0100, Guillaume M-M wrote:


1) the explosion in size mentioned above. This affects both stable and
master. (This is also responsible for a regression wrt 2.1.3 because of
zooming triggers preview as already discussed.)


Using vim I duplicated your document 26 times, thus creating a document
with a total of 676 different macros (attached). When generating the
previews, a 12Mb file was created, so the issue is real, at least for those
using hundreds of macros in a document, not the vast majority, I bet ;)

The attached patch against stable reduced the size of the tex file to
a perfectly manageable size of about 60Kb.

Richard, I think that this is pretty safe for stable. It simply omits
the macro definition if it is not used in the math inset. At worst,
it is added unnecessarily if for example \beta appears in the inset
and the macro name is \b, \be, or \bet.

As regards master, we have still to solve the other problem mentioned
in this thread before we can proceed.



Good news, I can confirm that it is much quicker, even unnoticeable.

Bad news, it seems to forget that macros can use macros. With the 
attached file the preview is as follows:


\begin{preview}
\global\long\def\b{\a}

$\b$
\end{preview}

Good news, opening the file lyx-bug-lassert-preview-startup.lyx no 
longer makes a crash (probably it just hides the bug).




lyx-preview-macros.lyx
Description: application/lyx

Re: test of math previews


Le 04/06/2015 20:17, Scott Kostyshak a écrit :

On Thu, Jun 4, 2015 at 3:05 PM, Enrico Forestieri for...@lyx.org wrote:

On Thu, Jun 04, 2015 at 02:44:56PM -0400, Scott Kostyshak wrote:

On Thu, Jun 4, 2015 at 2:34 PM, Scott Kostyshak skost...@lyx.org wrote:

On Thu, Jun 4, 2015 at 2:31 PM, Enrico Forestieri for...@lyx.org wrote:

On Thu, Jun 04, 2015 at 06:33:28PM +0100, Guillaume M-M wrote:


2) an assertion violation that happen on copy-paste with preview (does not
happen without preview). This is a regression in master, does not happen in
the stable branch.


I can reproduce the assertion. Bisect points at 73460423 and it was
backported to stable at 6ac04e21 where it asserts in the same way.


Ah thank you for catching this and bisecting. I will revert in branch
and master.


Can someone please confirm that I should indeed revert?
I took a look at lyx-preview-explosion.lyx and I can indeed reproduce
the assertion. My guess though is that the referenced commits expose a
different bug that has to do with previews and macros. But in the end
from a user perspective it is a regression. Thus, I think I should
revert.


Wouldn't it be better trying to understand why it asserts such that it
can be avoided?


Yes much better. However, we are close to release so I was thinking to
revert in the meantime. And second, I don't understand the underlying
code involving macros at all so it would be up to someone else to do
that. From what I remember of previous issues regarding preview +
macro, this is a complicated issue over my head.

Scott



The attached file produces a similar lassert when preview is on. No 
copy-paste involved, just open the file. (Sorry for not refining the 
example more, I think it's already small enough.)


Can leave lyx in a crash-on-startup state, forcing to remove by hand the 
line \preview from preferences. Affects master at cda4589f, and stable 
at 7013445b plus the following patch that removes the line added by 
6ac04e21:


diff --git a/src/Text3.cpp b/src/Text3.cpp
index 3359e35..0d256c2 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1269,7 +1269,7 @@ void Text::dispatch(Cursor  cur, FuncRequest  cmd)
bv-buffer().errors(Paste);
cur.clearSelection(); // bug 393
cur.finishUndo();
-   bv-buffer().updatePreviews();
+// bv-buffer().updatePreviews();
break;
}



lyx-bug-lassert-preview-startup.lyx
Description: application/lyx

Re: test of math previews


Le 04/06/2015 17:39, Enrico Forestieri a écrit :

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.


Could reproduce systematically, so did not look like a race condition. 
See the lassert from my previous message, could be related since it 
seems to happen similarly when the children are spawned. My flags are 
now build=development warnings assertions stdlib-debug concept-checks.




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.


Yes, I no longer have it (at cda4589f), but can trigger it similarly by 
switching Instant Preview from No Maths to On.

Re: test of math previews


Le 01/06/2015 23:04, Enrico Forestieri a écrit :

You may be right that microtype may have been the reason why I had the
impression that latex is slower than pdflatex, but this does not account for
the 55s (on a good computer) during which LyX is frozen while generating the
16MB tex file. I will run tests again to confirm (and also test the new
patch) and will reply to the previous message in a short while. (BTW yes I
have epstopdf and pdfcairo.)


Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.



The attached files demonstrate two bugs:

1) the explosion in size mentioned above. This affects both stable and 
master. (This is also responsible for a regression wrt 2.1.3 because of 
zooming triggers preview as already discussed.)


2) an assertion violation that happen on copy-paste with preview (does 
not happen without preview). This is a regression in master, does not 
happen in the stable branch.


Details:

1) Instant preview is activated. The preview tex file generated first 
time on opening redefines all the macros before each math inset. In this 
example there are 26 macros and 26 math insets. For my actual paper in 
preparation (quite modest, 18 pages with wide margins), the preview tex 
file lists 370 macros and 769 math insets. Given this data one can 
verify that its complete preview file is at least 284000 non-empty lines 
with a size of approx 15MB. I tried to make an example file in the same 
order of magnitude in order to demonstrate the performance impact, but 
bug 2) prevented me from doing that. You could argue that I could reduce 
the number of macros by half if I specialise my macro file to my current 
paper, but this defeats the purpose of having a global macro file, while 
not improving the situation much.



2) to trigger the assertion violation in master:
  0. enable instant preview
  1. select the whole document
  2. copy
  3. paste at the end

(Built from git commit hash 77ab3017)

\batchmode
%% LyX 2.2.0dev created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\makeatletter
\def\input@path{{/home/gm/Bureau//}}
\makeatother
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{amstext}

\makeatletter
%% User specified LaTeX commands.
% Added by lyx2lyx
\@ifundefined{rangeHsb}{\usepackage{xcolor}}

\makeatother

\usepackage{babel}

\def\lyxlock{}


\usepackage[active,delayed,showlabels,lyx]{preview}


\begin{document}
\begin{preview}
\global\long\def\A{\textit{this is the macro A }}

\global\long\def\B{\textit{this is the macro B }}

\global\long\def\C{\textit{this is the macro C }}

\global\long\def\D{\textit{this is the macro D }}

\global\long\def\E{\textit{this is the macro E }}

\global\long\def\F{\textit{this is the macro F }}

\global\long\def\G{\textit{this is the macro G }}

\global\long\def\H{\textit{this is the macro H }}

\global\long\def\I{\textit{this is the macro I }}

\global\long\def\J{\textit{this is the macro J }}

\global\long\def\K{\textit{this is the macro K }}

\global\long\def\L{\textit{this is the macro L }}

\global\long\def\M{\textit{this is the macro M }}

\global\long\def\N{\textit{this is the macro N }}

\global\long\def\O{\textit{this is the macro O }}

\global\long\def\P{\textit{this is the macro P }}

\global\long\def\Q{\textit{this is the macro Q }}

\global\long\def\R{\textit{this is the macro R }}

\global\long\def\S{\textit{this is the macro S }}

\global\long\def\T{\textit{this is the macro T }}

\global\long\def\U{\textit{this is the macro U }}

\global\long\def\V{\textit{this is the macro V }}

\global\long\def\W{\textit{this is the macro W }}

\global\long\def\X{\textit{this is the macro X }}

\global\long\def\Y{\textit{this is the macro Y }}

\global\long\def\Z{\textit{this is the macro Z }}
$\A$
\end{preview}

\begin{preview}
\global\long\def\A{\textit{this is the macro A }}

\global\long\def\B{\textit{this is the macro B }}

\global\long\def\C{\textit{this is the macro C }}

\global\long\def\D{\textit{this is the macro D }}

\global\long\def\E{\textit{this is the macro E }}

\global\long\def\F{\textit{this is the macro F }}

\global\long\def\G{\textit{this is the macro G }}

\global\long\def\H{\textit{this is the macro H }}

\global\long\def\I{\textit{this is the macro I }}

\global\long\def\J{\textit{this is the macro J }}

\global\long\def\K{\textit{this is the macro K }}

\global\long\def\L{\textit{this is the macro L }}

\global\long\def\M{\textit{this is the macro M }}

\global\long\def\N{\textit{this is the macro N }}

\global\long\def\O{\textit{this is the macro O }}

\global\long\def\P{\textit{this is the macro P }}

\global\long\def\Q{\textit{this is the macro Q }}

\global\long\def\R{\textit{this is the macro R }}

\global\long\def\S{\textit{this is the macro S }}

Re: test of math previews


Le 01/06/2015 23:04, Enrico Forestieri a écrit :

You may be right that microtype may have been the reason why I had the
impression that latex is slower than pdflatex, but this does not account for
the 55s (on a good computer) during which LyX is frozen while generating the
16MB tex file. I will run tests again to confirm (and also test the new
patch) and will reply to the previous message in a short while. (BTW yes I
have epstopdf and pdfcairo.)


Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.



The attached files demonstrate two bugs:

1) the explosion in size mentioned above. This affects both stable and 
master. (This is also responsible for a regression wrt 2.1.3 because of 
zooming triggers preview as already discussed.)


2) an assertion violation that happen on copy-paste with preview (does 
not happen without preview). This is a regression in master, does not 
happen in the stable branch.


Details:

1) Instant preview is activated. The preview tex file generated first 
time on opening redefines all the macros before each math inset. In this 
example there are 26 macros and 26 math insets. For my actual paper in 
preparation (quite modest, 18 pages with wide margins), the preview tex 
file lists 370 macros and 769 math insets. Given this data one can 
verify that its complete preview file is at least 284000 non-empty lines 
with a size of approx 15MB. I tried to make an example file in the same 
order of magnitude in order to demonstrate the performance impact, but 
bug 2) prevented me from doing that. You could argue that I could reduce 
the number of macros by half if I specialise my macro file to my current 
paper, but this defeats the purpose of having a global macro file, while 
not improving the situation much.



2) to trigger the assertion violation in master:
  0. enable instant preview
  1. select the whole document
  2. copy
  3. paste at the end

(Built from git commit hash 77ab3017)

\batchmode
%% LyX 2.2.0dev created this file.  For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\makeatletter
\def\input@path{{/home/gm/Bureau//}}
\makeatother
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{amstext}

\makeatletter
%% User specified LaTeX commands.
% Added by lyx2lyx
\@ifundefined{rangeHsb}{\usepackage{xcolor}}

\makeatother

\usepackage{babel}

\def\lyxlock{}


\usepackage[active,delayed,showlabels,lyx]{preview}


\begin{document}
\begin{preview}
\global\long\def\A{\textit{this is the macro A }}

\global\long\def\B{\textit{this is the macro B }}

\global\long\def\C{\textit{this is the macro C }}

\global\long\def\D{\textit{this is the macro D }}

\global\long\def\E{\textit{this is the macro E }}

\global\long\def\F{\textit{this is the macro F }}

\global\long\def\G{\textit{this is the macro G }}

\global\long\def\H{\textit{this is the macro H }}

\global\long\def\I{\textit{this is the macro I }}

\global\long\def\J{\textit{this is the macro J }}

\global\long\def\K{\textit{this is the macro K }}

\global\long\def\L{\textit{this is the macro L }}

\global\long\def\M{\textit{this is the macro M }}

\global\long\def\N{\textit{this is the macro N }}

\global\long\def\O{\textit{this is the macro O }}

\global\long\def\P{\textit{this is the macro P }}

\global\long\def\Q{\textit{this is the macro Q }}

\global\long\def\R{\textit{this is the macro R }}

\global\long\def\S{\textit{this is the macro S }}

\global\long\def\T{\textit{this is the macro T }}

\global\long\def\U{\textit{this is the macro U }}

\global\long\def\V{\textit{this is the macro V }}

\global\long\def\W{\textit{this is the macro W }}

\global\long\def\X{\textit{this is the macro X }}

\global\long\def\Y{\textit{this is the macro Y }}

\global\long\def\Z{\textit{this is the macro Z }}
$\A$
\end{preview}

\begin{preview}
\global\long\def\A{\textit{this is the macro A }}

\global\long\def\B{\textit{this is the macro B }}

\global\long\def\C{\textit{this is the macro C }}

\global\long\def\D{\textit{this is the macro D }}

\global\long\def\E{\textit{this is the macro E }}

\global\long\def\F{\textit{this is the macro F }}

\global\long\def\G{\textit{this is the macro G }}

\global\long\def\H{\textit{this is the macro H }}

\global\long\def\I{\textit{this is the macro I }}

\global\long\def\J{\textit{this is the macro J }}

\global\long\def\K{\textit{this is the macro K }}

\global\long\def\L{\textit{this is the macro L }}

\global\long\def\M{\textit{this is the macro M }}

\global\long\def\N{\textit{this is the macro N }}

\global\long\def\O{\textit{this is the macro O }}

\global\long\def\P{\textit{this is the macro P }}

\global\long\def\Q{\textit{this is the macro Q }}

\global\long\def\R{\textit{this is the macro R }}

\global\long\def\S{\textit{this is the macro S }}

Re: test of math previews


Le 04/06/2015 17:39, Enrico Forestieri a écrit :

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.


Could reproduce systematically, so did not look like a race condition. 
See the lassert from my previous message, could be related since it 
seems to happen similarly when the children are spawned. My flags are 
now build=development warnings assertions stdlib-debug concept-checks.




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.


Yes, I no longer have it (at cda4589f), but can trigger it similarly by 
switching Instant Preview from "No Maths" to "On".

Re: test of math previews


Le 04/06/2015 20:17, Scott Kostyshak a écrit :

On Thu, Jun 4, 2015 at 3:05 PM, Enrico Forestieri <for...@lyx.org> wrote:

On Thu, Jun 04, 2015 at 02:44:56PM -0400, Scott Kostyshak wrote:

On Thu, Jun 4, 2015 at 2:34 PM, Scott Kostyshak <skost...@lyx.org> wrote:

On Thu, Jun 4, 2015 at 2:31 PM, Enrico Forestieri <for...@lyx.org> wrote:

On Thu, Jun 04, 2015 at 06:33:28PM +0100, Guillaume M-M wrote:


2) an assertion violation that happen on copy-paste with preview (does not
happen without preview). This is a regression in master, does not happen in
the stable branch.


I can reproduce the assertion. Bisect points at 73460423 and it was
backported to stable at 6ac04e21 where it asserts in the same way.


Ah thank you for catching this and bisecting. I will revert in branch
and master.


Can someone please confirm that I should indeed revert?
I took a look at lyx-preview-explosion.lyx and I can indeed reproduce
the assertion. My guess though is that the referenced commits expose a
different bug that has to do with previews and macros. But in the end
from a user perspective it is a regression. Thus, I think I should
revert.


Wouldn't it be better trying to understand why it asserts such that it
can be avoided?


Yes much better. However, we are close to release so I was thinking to
revert in the meantime. And second, I don't understand the underlying
code involving macros at all so it would be up to someone else to do
that. From what I remember of previous issues regarding preview +
macro, this is a complicated issue over my head.

Scott



The attached file produces a similar lassert when preview is on. No 
copy-paste involved, just open the file. (Sorry for not refining the 
example more, I think it's already small enough.)


Can leave lyx in a crash-on-startup state, forcing to remove by hand the 
line \preview from preferences. Affects master at cda4589f, and stable 
at 7013445b plus the following patch that removes the line added by 
6ac04e21:


diff --git a/src/Text3.cpp b/src/Text3.cpp
index 3359e35..0d256c2 100644
--- a/src/Text3.cpp
+++ b/src/Text3.cpp
@@ -1269,7 +1269,7 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
bv->buffer().errors("Paste");
cur.clearSelection(); // bug 393
cur.finishUndo();
-   bv->buffer().updatePreviews();
+// bv->buffer().updatePreviews();
break;
}



lyx-bug-lassert-preview-startup.lyx
Description: application/lyx

Re: test of math previews


Le 04/06/2015 22:29, Enrico Forestieri a écrit :

On Thu, Jun 04, 2015 at 06:33:28PM +0100, Guillaume M-M wrote:


1) the explosion in size mentioned above. This affects both stable and
master. (This is also responsible for a regression wrt 2.1.3 because of
zooming triggers preview as already discussed.)


Using vim I duplicated your document 26 times, thus creating a document
with a total of 676 different macros (attached). When generating the
previews, a 12Mb file was created, so the issue is real, at least for those
using hundreds of macros in a document, not the vast majority, I bet ;)

The attached patch against stable reduced the size of the tex file to
a perfectly manageable size of about 60Kb.

Richard, I think that this is pretty safe for stable. It simply omits
the macro definition if it is not used in the math inset. At worst,
it is added unnecessarily if for example \beta appears in the inset
and the macro name is \b, \be, or \bet.

As regards master, we have still to solve the other problem mentioned
in this thread before we can proceed.



Good news, I can confirm that it is much quicker, even unnoticeable.

Bad news, it seems to forget that macros can use macros. With the 
attached file the preview is as follows:


\begin{preview}
\global\long\def\b{\a}

$\b$
\end{preview}

Good news, opening the file lyx-bug-lassert-preview-startup.lyx no 
longer makes a crash (probably it just hides the bug).




lyx-preview-macros.lyx
Description: application/lyx

Re: test of math previews

2015-06-03 Thread Guillaume M-M


Le 02/06/2015 23:50, Enrico Forestieri a écrit :



In fact I am currently having an assertion violation when activating full
instant preview (attached), which prevents me from completing the test. Can
anyone tell me how I get more meaningful symbols? I can try to send a
reproducer but I am a bit short on time to make one right now. (And time is
not pressing, it does not affect stable.)


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?






I am aware that it is less simple than it sounds given that often the user
wants to switch to a document class that already has more sensible defaults.
I will open an enhancement request if I figure out a solution, but I'd be
happy to know whether something like this was already discussed on the list.


Many times...


In that case, I will NOT open an enhancement request if there is already a
consensus :) (but I did not find any relevant entry in the bug tracker)


I don't know whether there is an entry in the bug tracker, but this issue
surfaces regularly either here or on the users list.



For the curious who missed the discussion from 2009, a relevant part is 
here http://comments.gmane.org/gmane.editors.lyx.general/60445 (it was 
quite hard to find because the discussion was moved over to the dev list 
during the discussion and this branch is not listed in the summary by day).


It was best summarised by Pavel Sanda: so isn't this rather request on 
latex devs to use latin modern as default for their classes?. I 
understand now that the only way of improving the new-user experience 
that is not ruled out by the arguments already given would be to find or 
invent some class/layout combination that would show the best defaults 
to a new user if any such notion of best defaults exists. (But I am 
leaving it there, this is not the problem at hand.)





In fact it does not work entirely in master. There is a regression (after
bc47054b I believe) because compilation can now fail due to \renewcommandx
being used without the command being defined prior to that (try the attached
lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
9285f338, it seems.) http://www.lyx.org/trac/ticket/6369

One quick solution would be to prepend all \renewcommandx\a{b} with
\providecommand\a{}.


I think this was already addressed by Jürgen at 83a9ed4e.



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}



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}



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}



lyx-bug-renewcommandx2.lyx
Description: application/lyx


lyx-bug-renewcommandx3.lyx
Description: application/lyx

Re: test of math previews

2015-06-03 Thread Guillaume M-M


Le 02/06/2015 23:50, Enrico Forestieri a écrit :



In fact I am currently having an assertion violation when activating full
instant preview (attached), which prevents me from completing the test. Can
anyone tell me how I get more meaningful symbols? I can try to send a
reproducer but I am a bit short on time to make one right now. (And time is
not pressing, it does not affect stable.)


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?






I am aware that it is less simple than it sounds given that often the user
wants to switch to a document class that already has more sensible defaults.
I will open an enhancement request if I figure out a solution, but I'd be
happy to know whether something like this was already discussed on the list.


Many times...


In that case, I will NOT open an enhancement request if there is already a
consensus :) (but I did not find any relevant entry in the bug tracker)


I don't know whether there is an entry in the bug tracker, but this issue
surfaces regularly either here or on the users list.



For the curious who missed the discussion from 2009, a relevant part is 
here  (it was 
quite hard to find because the discussion was moved over to the dev list 
during the discussion and this branch is not listed in the summary by day).


It was best summarised by Pavel Sanda: "so isn't this rather request on 
latex devs to use latin modern as default for their classes?". I 
understand now that the only way of improving the new-user experience 
that is not ruled out by the arguments already given would be to find or 
invent some class/layout combination that would show the best defaults 
to a new user if any such notion of best defaults exists. (But I am 
leaving it there, this is not the problem at hand.)





In fact it does not work entirely in master. There is a regression (after
bc47054b I believe) because compilation can now fail due to \renewcommandx
being used without the command being defined prior to that (try the attached
lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
9285f338, it seems.) 

One quick solution would be to prepend all \renewcommandx\a{b} with
\providecommand\a{}.


I think this was already addressed by Jürgen at 83a9ed4e.



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}
"""


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}
"""


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}
"""


lyx-bug-renewcommandx2.lyx
Description: application/lyx


lyx-bug-renewcommandx3.lyx
Description: application/lyx

Re: test of math previews


Le 02/06/2015 23:38, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 12:04:20AM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


By the way, a safer way to force not loading a package is to prepend
\usepackage with \@namedef{v...@microtype.sty}{/12/31}. If you just
strip the line from the preamble you can easily run into troubles. In
addition, at some point I had it on two lines like this (note the %):
   \usepackage[protrusion=true%,expansion=false
   ]{microtype}
in which case your regexp fails if I understood correctly. I suggest just
adding \@namedef{v...@microtype.sty}{/12/31} before the preamble
whether we suspect that microtype is used or not, without testing for its
presence. (Unless you see other errors this might generate.)


Ok, thanks for the tip.


Unfortunately, this does not work if options are also used. LaTeX is
tricked into thinking that the package was already loaded but the used
options are not acknowledged and errors are thrown.
I have now followed a different and safe way for dealing with this issue
by redefining \usepackage and simply omitting microtype when in dvi mode.
This takes care of your example above (and also of other more contrived ones).



You are right! I just sent a message suggesting to pass the draft option 
to microtype which should suffice according to the manual, unfortunately 
our messages crossed each other.

Re: test of math previews


Le 02/06/2015 23:56, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 11:47:45PM +0100, Guillaume M-M wrote:


Le 02/06/2015 23:38, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 12:04:20AM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


By the way, a safer way to force not loading a package is to prepend
\usepackage with \@namedef{v...@microtype.sty}{/12/31}. If you just
strip the line from the preamble you can easily run into troubles. In
addition, at some point I had it on two lines like this (note the %):
   \usepackage[protrusion=true%,expansion=false
   ]{microtype}
in which case your regexp fails if I understood correctly. I suggest just
adding \@namedef{v...@microtype.sty}{/12/31} before the preamble
whether we suspect that microtype is used or not, without testing for its
presence. (Unless you see other errors this might generate.)


Ok, thanks for the tip.


Unfortunately, this does not work if options are also used. LaTeX is
tricked into thinking that the package was already loaded but the used
options are not acknowledged and errors are thrown.
I have now followed a different and safe way for dealing with this issue
by redefining \usepackage and simply omitting microtype when in dvi mode.
This takes care of your example above (and also of other more contrived ones).



You are right! I just sent a message suggesting to pass the draft option to
microtype which should suffice according to the manual, unfortunately our
messages crossed each other.


BTW, that would still not work. \PassOptionToPackage only works if the
package is loaded without options.



I did the test, I wrote the following in the preamble:

\PassOptionsToPackage{draft}{microtype}
\usepackage[protrusion=true,expansion=true,tracking=true,kerning=true,spacing=true]{microtype}

and managed to compile in postscript and dvi without encountering any 
error (while it fails without the \PassOptions line).

Re: test of math previews


Le 02/06/2015 23:38, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 12:04:20AM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


By the way, a safer way to force not loading a package is to prepend
\usepackage with "\@namedef{v...@microtype.sty}{/12/31}". If you just
strip the line from the preamble you can easily run into troubles. In
addition, at some point I had it on two lines like this (note the %):
   \usepackage[protrusion=true%,expansion=false
   ]{microtype}
in which case your regexp fails if I understood correctly. I suggest just
adding "\@namedef{v...@microtype.sty}{/12/31}" before the preamble
whether we suspect that microtype is used or not, without testing for its
presence. (Unless you see other errors this might generate.)


Ok, thanks for the tip.


Unfortunately, this does not work if options are also used. LaTeX is
tricked into thinking that the package was already loaded but the used
options are not acknowledged and errors are thrown.
I have now followed a different and safe way for dealing with this issue
by redefining \usepackage and simply omitting microtype when in dvi mode.
This takes care of your example above (and also of other more contrived ones).



You are right! I just sent a message suggesting to pass the draft option 
to microtype which should suffice according to the manual, unfortunately 
our messages crossed each other.

Re: test of math previews


Le 02/06/2015 23:56, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 11:47:45PM +0100, Guillaume M-M wrote:


Le 02/06/2015 23:38, Enrico Forestieri a écrit :

On Tue, Jun 02, 2015 at 12:04:20AM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


By the way, a safer way to force not loading a package is to prepend
\usepackage with "\@namedef{v...@microtype.sty}{/12/31}". If you just
strip the line from the preamble you can easily run into troubles. In
addition, at some point I had it on two lines like this (note the %):
   \usepackage[protrusion=true%,expansion=false
   ]{microtype}
in which case your regexp fails if I understood correctly. I suggest just
adding "\@namedef{v...@microtype.sty}{/12/31}" before the preamble
whether we suspect that microtype is used or not, without testing for its
presence. (Unless you see other errors this might generate.)


Ok, thanks for the tip.


Unfortunately, this does not work if options are also used. LaTeX is
tricked into thinking that the package was already loaded but the used
options are not acknowledged and errors are thrown.
I have now followed a different and safe way for dealing with this issue
by redefining \usepackage and simply omitting microtype when in dvi mode.
This takes care of your example above (and also of other more contrived ones).



You are right! I just sent a message suggesting to pass the draft option to
microtype which should suffice according to the manual, unfortunately our
messages crossed each other.


BTW, that would still not work. \PassOptionToPackage only works if the
package is loaded without options.



I did the test, I wrote the following in the preamble:

\PassOptionsToPackage{draft}{microtype}
\usepackage[protrusion=true,expansion=true,tracking=true,kerning=true,spacing=true]{microtype}

and managed to compile in postscript and dvi without encountering any 
error (while it fails without the \PassOptions line).

test of math previews (was: [LyX/master] Really fix bug #9354)


Le 31/05/2015 16:12, Enrico Forestieri a écrit :

On Sun, May 31, 2015 at 01:24:05PM +0200, Kornel Benko wrote:


Am Sonntag, 31. Mai 2015 um 00:53:41, schrieb Enrico Forestieri for...@lyx.org

commit ad0d0f6d69a7acd6e99f7858f08b427a28d8f8cc
Author: Enrico Forestieri for...@lyx.org
Date:   Sun May 31 00:52:49 2015 +0200

 Really fix bug #9354



This is still not working in branch for redefined macros.
(Works in master as implemented by Jürgen)

Try the attached. (The second definition of \qG is different, but the preview
is not changed)


Thanks, should be fixed now.
This has nothing to do with bug 9354, though.



In fact it does not work entirely in master. There is a regression 
(after bc47054b I believe) because compilation can now fail due to 
\renewcommandx being used without the command being defined prior to 
that (try the attached lyx-bug-renewcommandx.lyx). (Stable is fine in 
this regard after your commit 9285f338, it seems.) 
http://www.lyx.org/trac/ticket/6369


One quick solution would be to prepend all \renewcommandx\a{b} with 
\providecommand\a{}.



Here are other conclusions from my test of stable and master this week-end:

1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py 
now includes the font lmodern (L236). I do not understand this addition: 
font setting is already done in the preamble. Removing the line fixes 
the issue.


2) In master, preview incorrectly calls latex instead of pdflatex if the 
default output format is set to default. More details in the attached 
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the 
default (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all 
the time, but it does not appear to be a regression wrt 2.1.3.


3) As reported in #6369, InstantPreview multiplies math macros 
definitions. Although the particular compilation issue has been solved, 
the duplication of macro definitions is not fixed. This has performance 
consequences. In stable and master, opening a moderately-sized math 
article (10-20 pages) with instant preview activated results in 75s of 
full CPU usage (and more when latex is called incorrectly instead of 
pdflatex), 55s during which LyX is unresponsive (and just generates the 
tex file). The instant preview tex file is 55 lines long and is 16MB 
big, mainly comprised of macro definitions (maybe there is another 
performance bottleneck, but this is probably one). So instant preview is 
still unusable for me (at least until the instant preview inset supports 
math macros---BTW the patch 
http://www.lyx.org/trac/attachment/ticket/9354/9354.diff works well 
for me).


4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the 
wrong size. LyX recreates the previews when zooming, and sometimes we 
end up with an intermediary size of preview inconsistent with the size 
of the text (race condition?).
(BTW why redoing preview from scratch when the pdf is already generated? 
Why not keeping the each preview as a pdfs, displayed on the fly by LyX 
using Cairo, when actually needed? This sounds vastly more efficient.)


3+4) Zooming with Ctrl+mousewheel is impossible with instant preview 
activated in a reasonably-sized document as a combination of 3) and 4). 
LyX freezes as soon as we touch the mouse wheel. (Both master and 
stable. Regression from 2.1.3. Same suggested solutions as 3 and 4.)


5) I find that the preferences dialog is counter-intuitive, with the 
distinction between Save, Apply and Close. I don't see the point of 
applying without saving (e.g. I think I have disabled instant preview, 
but then I find that it is reactivated the next time I run LyX). To add 
to the wish list of UI improvements...



Thank you, have a nice day.



lyx-bug-renewcommandx.lyx
Description: application/lyx


lyx-bug-font2.lyx
Description: application/lyx


lyx-bug-microtype.lyx
Description: application/lyx

Re: test of math previews


Le 01/06/2015 18:16, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:


2) In master, preview incorrectly calls latex instead of pdflatex if the
default output format is set to default. More details in the attached
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
default (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all the
time, but it does not appear to be a regression wrt 2.1.3.


Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.


I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.


I do not think that treating microtype as a special case is the way to 
go. First, the issue is with the option expansion=true. Without this 
option, microtype correctly works with latex and correctly activates 
expansion with pdflatex.


This was more to illustrate the fact that it is a great new feature in 
master to compile the previews using the default output format because 
of many small details like this error. For instance, although this seems 
easy to fix now that I understood the issue (just remove the option 
expansion=true, or set the default output format to pdflatex) it really 
took me a while to figure this out (partly because it is hard to access 
the error messages for the instant preview).


As I described, I think the issue is regarding the meaning of Default 
output format: Default. For the Ctrl+R shortcut, this means pdflatex 
while for instant preview this means latex. I don't understand the 
backwards-compatibility argument here, I think that it is safer to use 
the same default format as Ctrl+R in all cases.


This looks like a small detail, but for a general user, setting 
explicitly default output format: PDF (pdflatex) does not appear as an 
obvious solution to instant preview does not work. And the error can 
always be more fatal than this error with microtype.


IF the inconsistency regarding the meaning of Default output format: 
Default is intended for performance reason and that I did not make you 
change your mind, then I vote for:

 omitting the microtype
 package for the sake of generating the previews by using the faster
 dvipng method
But again it is hard to guess that default output format: default has 
this optimisation while default output format: PDF (pdflatex) does 
not. (But at least there is the option to force the use of pdflatex by 
instant preview if really needed.)


By the way, a safer way to force not loading a package is to prepend 
\usepackage with \@namedef{v...@microtype.sty}{/12/31}. If you just 
strip the line from the preamble you can easily run into troubles. In 
addition, at some point I had it on two lines like this (note the %):

  \usepackage[protrusion=true%,expansion=false
  ]{microtype}
in which case your regexp fails if I understood correctly. I suggest 
just adding \@namedef{v...@microtype.sty}{/12/31} before the 
preamble whether we suspect that microtype is used or not, without 
testing for its presence. (Unless you see other errors this might generate.)


Again the philosophy of my comment is not please deal explicitly with 
these corner cases but it's

Re: test of math previews


Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri for...@lyx.org
mailto:for...@lyx.org:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
 On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
 
  1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the
  attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
  includes the font lmodern (L236). I do not understand this addition: 
font
  setting is already done in the preamble. Removing the line fixes the 
issue.

 It was added in order to have vector fonts, otherwise the previews
 generated by the legacy method would be of very poor quality. It is
 difficult to determine what a user could do in the preamble and whether
 it is safe using lmodern or not. However, given that it may produce 
issues,
 it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi


Jürgen




Is there any lyx file demonstrating the poor font quality? I have been 
unable to reproduce the font issue in master (after removing the line 
that forces latin modern in instant previews), even with the default 
setting of LyX that produces a PDF with bitmap fonts...


Anyway, here's a suggestion for getting those horrible bitmap fonts out 
of the way of new users, in a perfectly non-intrusive and 
backwards-compatible manner: just set Latin Modern to be the default 
choice for a new document. This would also solve the issue considered 
above. Note that I don't suggest to change the meaning of Default for 
roman fonts, but rather to force the user explicitly select Default 
over Latin Modern if he really wants to. I think it is always good 
when LyX shows the standard way. Then if the user wants poor bitmap 
fonts, that will be by choice.


(I know that I may suggest patches instead of ideas, but I do not have 
much time currently to become a new contributor to LyX, although I have 
been considering it.)

Re: test of math previews


Le 01/06/2015 21:16, Guillaume M-M a écrit :

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri for...@lyx.org
mailto:for...@lyx.org:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
 On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
 
  1) b3d2ffc0 introduces a regression in stable and master wrt
2.1.3. See the
  attached lyx-bug-font2.lyx. This is because
legacy_lyxpreview2ppm.py now
  includes the font lmodern (L236). I do not understand this
addition: font
  setting is already done in the preamble. Removing the line
fixes the issue.

 It was added in order to have vector fonts, otherwise the previews
 generated by the legacy method would be of very poor quality. It is
 difficult to determine what a user could do in the preamble and
whether
 it is safe using lmodern or not. However, given that it may
produce issues,
 it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?


lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi


Jürgen




Is there any lyx file demonstrating the poor font quality? I have been
unable to reproduce the font issue in master (after removing the line
that forces latin modern in instant previews), even with the default
setting of LyX that produces a PDF with bitmap fonts...

Anyway, here's a suggestion for getting those horrible bitmap fonts out
of the way of new users, in a perfectly non-intrusive and
backwards-compatible manner: just set Latin Modern to be the default
choice for a new document. This would also solve the issue considered
above. Note that I don't suggest to change the meaning of Default for
roman fonts, but rather to force the user explicitly select Default
over Latin Modern if he really wants to. I think it is always good
when LyX shows the standard way. Then if the user wants poor bitmap
fonts, that will be by choice.



I am aware that it is less simple than it sounds given that often the 
user wants to switch to a document class that already has more sensible 
defaults. I will open an enhancement request if I figure out a solution, 
but I'd be happy to know whether something like this was already 
discussed on the list.

Re: test of math previews


Le 01/06/2015 22:12, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


I don't understand the
backwards-compatibility argument here, I think that it is safer to use the
same default format as Ctrl+R in all cases.


I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.




I know the importance of backwards compatibility, but I don't understand 
how it applies here.


Currently in stable:
* With default format output = Default
  * Ctrl+R - pdflatex
  * Instant preview - latex
* With default format output = PDF (pdflatex)
  * Ctrl+R - pdflatex
  * Instant preview - latex

Whereas in master:
* With default format output = Default
  * Ctrl+R - pdflatex
  * Instant preview - latex
* With default format output = PDF (pdflatex)
  * Ctrl+R - pdflatex
  * Instant preview - pdflatex

Thus, if changing the behaviour of instant preview for Default means 
breaking backwards compatibility, then backwards compatibility is 
already broken in master given that the behaviour is changed for PDF 
(pdflatex). We don't appear to believe that. This is what I meant.


But I am receptive to your idea of keeping latex for the speedup and 
disabling microtype, for the same speed reason. I like the idea of still 
having the choice via default output format (even though the feature 
will be kind of hidden).


Le 01/06/2015 22:20, Enrico Forestieri a écrit :


I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)


Sorry for the false alarm, I can indeed reproduce with these 
explanations. However this is consistent with the document settings: 
lmodern should indeed not be loaded if the fonts have already been set 
properly, as suggested by Jürgen.


Thank you

Re: test of math previews


Le 01/06/2015 23:04, Enrico Forestieri a écrit :

You may be right that microtype may have been the reason why I had the
impression that latex is slower than pdflatex, but this does not account for
the 55s (on a good computer) during which LyX is frozen while generating the
16MB tex file. I will run tests again to confirm (and also test the new
patch) and will reply to the previous message in a short while. (BTW yes I
have epstopdf and pdfcairo.)


Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.



Read again: I am saying that I am running further tests and come back 
later with a reply :)


In fact I am currently having an assertion violation when activating 
full instant preview (attached), which prevents me from completing the 
test. Can anyone tell me how I get more meaningful symbols? I can try to 
send a reproducer but I am a bit short on time to make one right now. 
(And time is not pressing, it does not affect stable.)


LyX 2.2.0dev (not released yet)
  Git commit hash cb201027
Configuration
  Host type:   x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks

  C++ Compiler:g++ (4.9.2)
  C++ Compiler flags:   -Wall -Wextra -Wfloat-conversion -g -O
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  4.8.6
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-gm




I am aware that it is less simple than it sounds given that often the user
wants to switch to a document class that already has more sensible defaults.
I will open an enhancement request if I figure out a solution, but I'd be
happy to know whether something like this was already discussed on the list.


Many times...


In that case, I will NOT open an enhancement request if there is already 
a consensus :) (but I did not find any relevant entry in the bug tracker)



In fact it does not work entirely in master. There is a regression (after
bc47054b I believe) because compilation can now fail due to \renewcommandx
being used without the command being defined prior to that (try the attached
lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
9285f338, it seems.) http://www.lyx.org/trac/ticket/6369

One quick solution would be to prepend all \renewcommandx\a{b} with
\providecommand\a{}.


I think this was already addressed by Jürgen at 83a9ed4e.



For me the bug is still here at cb201027. Try again my file 
lyx-bug-renewcommandx.lyx attached to my first message.


Warning: pdflatex had problems compiling lyxpreviewM16620.tex
Warning: trying to recover from failed compilation
lassert.cpp (51): ASSERTION !empty() VIOLATED IN DocIterator.cpp:114
(  1) lyx-gm: lyx-gm() [0xc6b79b]
(  2) lyx-gm: lyx-gm() [0xc6b8b2]
(  3) lyx-gm: lyx-gm() [0x54e84f]
(  4) lyx-gm: lyx-gm() [0x7f4438]
(  5) lyx-gm: lyx-gm() [0x7a0a9e]
(  6) lyx-gm: lyx-gm() [0x7a1b4f]
(  7) lyx-gm: lyx-gm() [0x495c28]
(  8) lyx-gm: lyx-gm() [0x4d4809]
(  9) lyx-gm: lyx-gm() [0xb77b75]
( 10) lyx-gm: lyx-gm() [0xa676c4]
( 11) lyx-gm: lyx-gm() [0xabb7ae]
( 12) lyx-gm: lyx-gm() [0xabb864]
( 13) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QMetaObject::activate(QObject*, 
QMetaObject const*, int, void**)
( 14) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QAbstractButton::clicked(bool)
( 15) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59e533) [0x7f129d9fd533]
( 16) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59f8e4) [0x7f129d9fe8e4]
( 17) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractButton::mouseReleaseEvent(QMouseEvent*)
( 18) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 19) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplication::notify(QObject*, 
QEvent*)
( 21) lyx-gm: lyx-gm() [0x9d1084]
( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, 
QWidget**, QPointerQWidget, bool)
( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2489a2) [0x7f129d6a79a2]
( 25) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 26) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f129d6cfba2]
( 27) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d) 
[0x7f129ba3cc3d]
( 28) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f129ba3cf20]
( 29)

test of math previews (was: [LyX/master] Really fix bug #9354)


Le 31/05/2015 16:12, Enrico Forestieri a écrit :

On Sun, May 31, 2015 at 01:24:05PM +0200, Kornel Benko wrote:


Am Sonntag, 31. Mai 2015 um 00:53:41, schrieb Enrico Forestieri 

commit ad0d0f6d69a7acd6e99f7858f08b427a28d8f8cc
Author: Enrico Forestieri 
Date:   Sun May 31 00:52:49 2015 +0200

 Really fix bug #9354



This is still not working in branch for redefined macros.
(Works in master as implemented by Jürgen)

Try the attached. (The second definition of \qG is different, but the preview
is not changed)


Thanks, should be fixed now.
This has nothing to do with bug 9354, though.



In fact it does not work entirely in master. There is a regression 
(after bc47054b I believe) because compilation can now fail due to 
\renewcommandx being used without the command being defined prior to 
that (try the attached lyx-bug-renewcommandx.lyx). (Stable is fine in 
this regard after your commit 9285f338, it seems.) 



One quick solution would be to prepend all \renewcommandx\a{b} with 
\providecommand\a{}.



Here are other conclusions from my test of stable and master this week-end:

1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py 
now includes the font lmodern (L236). I do not understand this addition: 
font setting is already done in the preamble. Removing the line fixes 
the issue.


2) In master, preview incorrectly calls latex instead of pdflatex if the 
default output format is set to "default". More details in the attached 
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the 
"default" (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all 
the time, but it does not appear to be a regression wrt 2.1.3.


3) As reported in #6369, "InstantPreview multiplies math macros 
definitions". Although the particular compilation issue has been solved, 
the duplication of macro definitions is not fixed. This has performance 
consequences. In stable and master, opening a moderately-sized math 
article (10-20 pages) with instant preview activated results in 75s of 
full CPU usage (and more when latex is called incorrectly instead of 
pdflatex), 55s during which LyX is unresponsive (and just generates the 
tex file). The instant preview tex file is 55 lines long and is 16MB 
big, mainly comprised of macro definitions (maybe there is another 
performance bottleneck, but this is probably one). So instant preview is 
still unusable for me (at least until the instant preview inset supports 
math macros---BTW the patch 
 works well 
for me).


4) Using Ctrl+Mousewheel to zoom sometimes results in a preview of the 
wrong size. LyX recreates the previews when zooming, and sometimes we 
end up with an intermediary size of preview inconsistent with the size 
of the text (race condition?).
(BTW why redoing preview from scratch when the pdf is already generated? 
Why not keeping the each preview as a pdfs, displayed on the fly by LyX 
using Cairo, when actually needed? This sounds vastly more efficient.)


3+4) Zooming with Ctrl+mousewheel is impossible with instant preview 
activated in a reasonably-sized document as a combination of 3) and 4). 
LyX freezes as soon as we touch the mouse wheel. (Both master and 
stable. Regression from 2.1.3. Same suggested solutions as 3 and 4.)


5) I find that the preferences dialog is counter-intuitive, with the 
distinction between Save, Apply and Close. I don't see the point of 
applying without saving (e.g. I think I have disabled instant preview, 
but then I find that it is reactivated the next time I run LyX). To add 
to the wish list of UI improvements...



Thank you, have a nice day.



lyx-bug-renewcommandx.lyx
Description: application/lyx


lyx-bug-font2.lyx
Description: application/lyx


lyx-bug-microtype.lyx
Description: application/lyx

Re: test of math previews

Le 01/06/2015 18:16, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:

On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:

2) In master, preview incorrectly calls latex instead of pdflatex if the
default output format is set to "default". More details in the attached
lyx-bug-microtype.lyx. (It causes the instant preview to fail, while the
"default" (pdflatex) compilation with Ctrl+R succeeds.)
Stable also fails because it seems to call latex instead of pdflatex all the
time, but it does not appear to be a regression wrt 2.1.3.

Note that we have to guarantee backward compatibility and using latex
when the document does not specify a default output format is a must,
otherwise instant preview may fail for existing documents.
See #9371 for details.

When using pdflatex (or other formats producing a pdf) for generating
the previews, the legacy method is used. It turns out to be much slower
than the dvipng route, so that care is taken to try to use dvi output for
all previews not failing and then trying pdflatex for those that fail.
For some reason, the failure you report escapes those checks. So, this
reason should be identified and accordingly corrected. Typically, in
open source projects one can suggest a patch to speed up the correction
of an issue.

I had a closer look at this issue and it turned out to be as follows.
If a snippet produces latex errors it is now not previewed at all.
Now, when using the microtype package in dvi mode, latex issues an
error about not finding the tfm file for a font, but nevertheless
goes on and produces a correct output. This error is issued only at
the beginning so that it associated with the first snippet, which is
for this reason marked as bad. Actually, the script generates a valid
preview but it is not used. All other snippets are used, so only the
first one is omitted even if it would be Ok.

There are 2 possible solutions. The first one is omitting the microtype
package for the sake of generating the previews by using the faster
dvipng method (attached patch no-microtype.diff for master).
The second one is forcing the use of pdflatex when the use of microtype
is detected. In this case the slower legacy mathod will be used for
generating the previews (attached patch yes-microtype.diff for master).

Please, vote for the one or the other. I will commit the patch getting
more votes.

I do not think that treating microtype as a special case is the way to 
go. First, the issue is with the option "expansion=true". Without this 
option, microtype correctly works with latex and correctly activates 
expansion with pdflatex.

This was more to illustrate the fact that it is a great new feature in 
master to compile the previews using the default output format because 
of many small details like this error. For instance, although this seems 
easy to fix now that I understood the issue (just remove the option 
expansion=true, or set the default output format to pdflatex) it really 
took me a while to figure this out (partly because it is hard to access 
the error messages for the instant preview).

As I described, I think the issue is regarding the meaning of "Default 
output format: Default". For the Ctrl+R shortcut, this means pdflatex 
while for instant preview this means latex. I don't understand the 
backwards-compatibility argument here, I think that it is safer to use 
the same default format as Ctrl+R in all cases.

This looks like a small detail, but for a general user, setting 
explicitly "default output format: PDF (pdflatex)" does not appear as an 
obvious solution to "instant preview does not work". And the error can 
always be more fatal than this error with microtype.

IF the inconsistency regarding the meaning of "Default output format: 
Default" is intended for performance reason and that I did not make you 
change your mind, then I vote for:

> omitting the microtype
> package for the sake of generating the previews by using the faster
> dvipng method
But again it is hard to guess that "default output format: default" has 
this optimisation while "default output format: PDF (pdflatex)" does 
not. (But at least there is the option to force the use of pdflatex by 
instant preview if really needed.)

By the way, a safer way to force not loading a package is to prepend 
\usepackage with "\@namedef{v...@microtype.sty}{/12/31}". If you just 
strip the line from the preamble you can easily run into troubles. In 
addition, at some point I had it on two lines like this (note the %):

  \usepackage[protrusion=true%,expansion=false
  ]{microtype}
in which case your regexp fails if I understood correctly. I suggest 
just adding "\@namedef{v...@microtype.sty}{/12/31}" before the 
preamble whether we suspect that microtype is used or not, without 
testing for its presence.

Re: test of math previews

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri <for...@lyx.org
<mailto:for...@lyx.org>>:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> >
> > 1) b3d2ffc0 introduces a regression in stable and master wrt 2.1.3. See 
the
> > attached lyx-bug-font2.lyx. This is because legacy_lyxpreview2ppm.py now
> > includes the font lmodern (L236). I do not understand this addition: 
font
> > setting is already done in the preamble. Removing the line fixes the 
issue.
>
> It was added in order to have vector fonts, otherwise the previews
> generated by the legacy method would be of very poor quality. It is
> difficult to determine what a user could do in the preamble and whether
> it is safe using lmodern or not. However, given that it may produce 
issues,
> it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?

lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi

Jürgen

Is there any lyx file demonstrating the poor font quality? I have been 
unable to reproduce the font issue in master (after removing the line 
that forces latin modern in instant previews), even with the default 
setting of LyX that produces a PDF with bitmap fonts...

Anyway, here's a suggestion for getting those horrible bitmap fonts out 
of the way of new users, in a perfectly non-intrusive and 
backwards-compatible manner: just set Latin Modern to be the default 
choice for a new document. This would also solve the issue considered 
above. Note that I don't suggest to change the meaning of "Default" for 
roman fonts, but rather to force the user explicitly select "Default" 
over "Latin Modern" if he really wants to. I think it is always good 
when LyX shows the standard way. Then if the user wants poor bitmap 
fonts, that will be by choice.

(I know that I may suggest patches instead of ideas, but I do not have 
much time currently to become a new contributor to LyX, although I have 
been considering it.)

Re: test of math previews

Le 01/06/2015 21:16, Guillaume M-M a écrit :

Le 01/06/2015 19:50, Jürgen Spitzmüller a écrit :

2015-06-01 19:34 GMT+02:00 Enrico Forestieri <for...@lyx.org
<mailto:for...@lyx.org>>:

On Mon, Jun 01, 2015 at 03:50:49PM +0200, Enrico Forestieri wrote:
> On Mon, Jun 01, 2015 at 07:26:55AM +0100, Guillaume M-M wrote:
> >
> > 1) b3d2ffc0 introduces a regression in stable and master wrt
2.1.3. See the
> > attached lyx-bug-font2.lyx. This is because
legacy_lyxpreview2ppm.py now
> > includes the font lmodern (L236). I do not understand this
addition: font
> > setting is already done in the preamble. Removing the line
fixes the issue.
>
> It was added in order to have vector fonts, otherwise the previews
> generated by the legacy method would be of very poor quality. It is
> difficult to determine what a user could do in the preamble and
whether
> it is safe using lmodern or not. However, given that it may
produce issues,
> it may be better not using it, if nobody has a better idea.

Jürgen, any idea on this one?

lmodern must only be loaded if no other font has been loaded, i.e. if
computer modern is the active font:

\def\tempa{cmr}

\ifx\f@family\tempa\usepackage{lmodern}\else\fi

Jürgen

Is there any lyx file demonstrating the poor font quality? I have been
unable to reproduce the font issue in master (after removing the line
that forces latin modern in instant previews), even with the default
setting of LyX that produces a PDF with bitmap fonts...

Anyway, here's a suggestion for getting those horrible bitmap fonts out
of the way of new users, in a perfectly non-intrusive and
backwards-compatible manner: just set Latin Modern to be the default
choice for a new document. This would also solve the issue considered
above. Note that I don't suggest to change the meaning of "Default" for
roman fonts, but rather to force the user explicitly select "Default"
over "Latin Modern" if he really wants to. I think it is always good
when LyX shows the standard way. Then if the user wants poor bitmap
fonts, that will be by choice.

I am aware that it is less simple than it sounds given that often the 
user wants to switch to a document class that already has more sensible 
defaults. I will open an enhancement request if I figure out a solution, 
but I'd be happy to know whether something like this was already 
discussed on the list.

Re: test of math previews


Le 01/06/2015 22:12, Enrico Forestieri a écrit :

On Mon, Jun 01, 2015 at 08:07:11PM +0100, Guillaume M-M wrote:


I don't understand the
backwards-compatibility argument here, I think that it is safer to use the
same default format as Ctrl+R in all cases.


I think that the backward-compatibility argument is a serious one.
If an old document that was perfectly working does not work anymore,
one could simply decide that LyX is not the right tool to use and it
is safer using latex directly.




I know the importance of backwards compatibility, but I don't understand 
how it applies here.


Currently in stable:
* With default format output = Default
  * Ctrl+R -> pdflatex
  * Instant preview -> latex
* With default format output = PDF (pdflatex)
  * Ctrl+R -> pdflatex
  * Instant preview -> latex

Whereas in master:
* With default format output = Default
  * Ctrl+R -> pdflatex
  * Instant preview -> latex
* With default format output = PDF (pdflatex)
  * Ctrl+R -> pdflatex
  * Instant preview -> pdflatex

Thus, if changing the behaviour of instant preview for "Default" means 
breaking backwards compatibility, then backwards compatibility is 
already broken in master given that the behaviour is changed for "PDF 
(pdflatex)". We don't appear to believe that. This is what I meant.


But I am receptive to your idea of keeping latex for the speedup and 
disabling microtype, for the same speed reason. I like the idea of still 
having the choice via "default output format" (even though the feature 
will be kind of hidden).


Le 01/06/2015 22:20, Enrico Forestieri a écrit :


I attach here the pdfs I get with a new document with default output set to
pdflatex and simply an 'a' in a preview inset.
The first one (lyxpreviewdCv436.pdf) when I ditch the lmodern line, the
second one (lyxpreviewxWL436.pdf) with that line in place. The previews
are then generated by converting the pdfs into pngs.
Here you can also find how the difference looks like on screen:
http://www.lyx.org/trac/attachment/ticket/9371/example-2.1.png (good)
http://www.lyx.org/trac/attachment/ticket/9371/example-2.2.png (bad)


Sorry for the false alarm, I can indeed reproduce with these 
explanations. However this is consistent with the document settings: 
lmodern should indeed not be loaded if the fonts have already been set 
properly, as suggested by Jürgen.


Thank you

Re: test of math previews


Le 01/06/2015 23:04, Enrico Forestieri a écrit :

You may be right that microtype may have been the reason why I had the
impression that latex is slower than pdflatex, but this does not account for
the 55s (on a good computer) during which LyX is frozen while generating the
16MB tex file. I will run tests again to confirm (and also test the new
patch) and will reply to the previous message in a short while. (BTW yes I
have epstopdf and pdfcairo.)


Here we are not going anywhere. I say it works well for me, while you say it
doesn't work. Please, provide an example that generates a 16MB tex file for
a ~20 page document.



Read again: I am saying that I am running further tests and come back 
later with a reply :)


In fact I am currently having an assertion violation when activating 
full instant preview (attached), which prevents me from completing the 
test. Can anyone tell me how I get more meaningful symbols? I can try to 
send a reproducer but I am a bit short on time to make one right now. 
(And time is not pressing, it does not affect stable.)


LyX 2.2.0dev (not released yet)
  Git commit hash cb201027
Configuration
  Host type:   x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks

  C++ Compiler:g++ (4.9.2)
  C++ Compiler flags:   -Wall -Wextra -Wfloat-conversion -g -O
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  4.8.6
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-gm




I am aware that it is less simple than it sounds given that often the user
wants to switch to a document class that already has more sensible defaults.
I will open an enhancement request if I figure out a solution, but I'd be
happy to know whether something like this was already discussed on the list.


Many times...


In that case, I will NOT open an enhancement request if there is already 
a consensus :) (but I did not find any relevant entry in the bug tracker)



In fact it does not work entirely in master. There is a regression (after
bc47054b I believe) because compilation can now fail due to \renewcommandx
being used without the command being defined prior to that (try the attached
lyx-bug-renewcommandx.lyx). (Stable is fine in this regard after your commit
9285f338, it seems.) 

One quick solution would be to prepend all \renewcommandx\a{b} with
\providecommand\a{}.


I think this was already addressed by Jürgen at 83a9ed4e.



For me the bug is still here at cb201027. Try again my file 
lyx-bug-renewcommandx.lyx attached to my first message.


Warning: pdflatex had problems compiling lyxpreviewM16620.tex
Warning: trying to recover from failed compilation
lassert.cpp (51): ASSERTION !empty() VIOLATED IN DocIterator.cpp:114
(  1) lyx-gm: lyx-gm() [0xc6b79b]
(  2) lyx-gm: lyx-gm() [0xc6b8b2]
(  3) lyx-gm: lyx-gm() [0x54e84f]
(  4) lyx-gm: lyx-gm() [0x7f4438]
(  5) lyx-gm: lyx-gm() [0x7a0a9e]
(  6) lyx-gm: lyx-gm() [0x7a1b4f]
(  7) lyx-gm: lyx-gm() [0x495c28]
(  8) lyx-gm: lyx-gm() [0x4d4809]
(  9) lyx-gm: lyx-gm() [0xb77b75]
( 10) lyx-gm: lyx-gm() [0xa676c4]
( 11) lyx-gm: lyx-gm() [0xabb7ae]
( 12) lyx-gm: lyx-gm() [0xabb864]
( 13) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QMetaObject::activate(QObject*, 
QMetaObject const*, int, void**)
( 14) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QAbstractButton::clicked(bool)
( 15) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59e533) [0x7f129d9fd533]
( 16) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x59f8e4) [0x7f129d9fe8e4]
( 17) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QAbstractButton::mouseReleaseEvent(QMouseEvent*)
( 18) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 19) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QApplication::notify(QObject*, 
QEvent*)
( 21) lyx-gm: lyx-gm() [0x9d1084]
( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: 
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, 
QWidget**, QPointer&, bool)
( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x2489a2) [0x7f129d6a79a2]
( 25) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
QApplication::x11ProcessEvent(_XEvent*)
( 26) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x270ba2) [0x7f129d6cfba2]
( 27) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d) 
[0x7f129ba3cc3d]
( 28) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f20) [0x7f129ba3cf20]
( 29)

Re: LyX 2.1.4

2015-05-30 Thread Guillaume M-M


Dear Enrico,

It's quite strange, to me #9354 does not appear fixed at all! I just 
left a detailed comment in http://www.lyx.org/trac/ticket/9354.


If I missed something please tell me what so that I can be more helpful 
in future testings.



Best regards
Guillaume

Le 30/05/2015 15:00, Enrico Forestieri a écrit :

On Fri, May 29, 2015 at 11:12:51AM -0400, Richard Heck wrote:



I'd like to start the 2.1.4 release process by freezing strings, etc. Any
fixes that need to go in before I do that?


What about http://www.lyx.org/trac/ticket/8258 ?

I have also attached a patch at http://www.lyx.org/trac/ticket/9371
that, by only touching the python scripts, would solve:
http://www.lyx.org/trac/ticket/6369
http://www.lyx.org/trac/ticket/9354
http://www.lyx.org/trac/ticket/9508
http://www.lyx.org/trac/ticket/9510

Re: LyX 2.1.4

2015-05-30 Thread Guillaume M-M


Dear Enrico,

It's quite strange, to me #9354 does not appear fixed at all! I just 
left a detailed comment in .


If I missed something please tell me what so that I can be more helpful 
in future testings.



Best regards
Guillaume

Le 30/05/2015 15:00, Enrico Forestieri a écrit :

On Fri, May 29, 2015 at 11:12:51AM -0400, Richard Heck wrote:



I'd like to start the 2.1.4 release process by freezing strings, etc. Any
fixes that need to go in before I do that?


What about http://www.lyx.org/trac/ticket/8258 ?

I have also attached a patch at http://www.lyx.org/trac/ticket/9371
that, by only touching the python scripts, would solve:
http://www.lyx.org/trac/ticket/6369
http://www.lyx.org/trac/ticket/9354
http://www.lyx.org/trac/ticket/9508
http://www.lyx.org/trac/ticket/9510

Re: math macro crashes again (bug 9490)

2015-05-15 Thread Guillaume M-M


On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place, then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: math macro crashes again (bug 9490)

2015-05-15 Thread Guillaume M-M


On 05/15/15 10:04, Jean-Marc Lasgouttes wrote:

Le 14/05/15 22:31, Guillaume M-M a écrit :

My typical use case is to change the macro while keeping the same
arguments. In the absolute, it is easy to see that this can be useful
occasionally at least. Indeed, in the absence of macro-unfolding, the
alternative is to copy and paste the arguments one by one from the old
macro to the new macro. With unfolding, one just edits the name of the
macro, benefiting from name completion, etc.


I see it better now. It does not make much sense though that this is
possible with a macro and not with \frac.


I agree.




But, also, once one is aware of unfolding, one can start using it more
systematically, because one can define similar, but different, macros,
and switch between them when it is needed. (I can give you practical
examples if you want...) I currently do not know how to achieve
something similar without unfolding.


I would do that by putting different definitions of the same macro in
different branches. But this may not be exactly what you are after.


No indeed, I am speaking of something else. For instance we can use 
copy/paste on one equation because only a few details have to be 
changed. Or simply we can change our mind during the typesetting of a 
proof: writing an article does not go in a straight line.





In fact, I do not care so much about macro unfolding itself than the
possibility of changing the macro in-place (with name completion). Am I
missing anything?


I do not think you are missing something. Obviously, changing macro
would be possible as long as the parameters of the macros have the same
structure. But switching from a two parameters macro to a one parameter
one is trickier.


About toggling, they had this discussion before some years ago:
<http://marc.info/?l=lyx-devel=122071560319193=1>. I admit that I
don't use repeated unfolding so much. In addition, I do not use macro
folding because the macros folds itself automatically once the name is
changed. (But if other power users of unfolding and folding are reading
this they will surely speak up, right?)

I hope this clarifies.


Well it indeed clarifies that macro-unfold is a very weird concept :)


For these implementation details I agree---but if the question is "how 
do we change the name of a macro in a way that has the same features 
(e.g. completion) as inserting the macro in the first place", then the 
idea of unfolding is quite natural.


Sorry for not being familiar enough with the source code to make more 
constructive suggestions.



Guillaume

Re: Problem whith Shaded menu


On 05/14/15 16:25, hatim ali wrote:

Dear lyx team
Thank you for good job.
I used lyx 2.2 with ubuntu.
When i start lyx then dropdown any menu like File, Edit, Insert, i got
shaded commands, i mean the first 3 or 4 command in the list ( enable )
but others was disbale ( shaded - unable to click).
To resolve this problem, must change lyx interface language from
Preferences...  save, then retern to default languge then save.


Best regards



Dear Ali,

Could this be your problem? 
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059


If so, then it is a bug with indicator-appmenu. I proposed a patch two 
weeks ago and we are waiting for the developer to look at it. In the 
meanwhile you'll find a workaround to disable the appmenu.



Best
Guillaume

Re: math macro crashes again (bug 9490)


On 05/14/15 19:46, Georg Baum wrote:

Guillaume M-M wrote:


Thank you for looking at these bugs. I reported 9418 and 9490, and I use
macro unfolding quite often. Before discovering this feature, I would
occasionally edit the lyx file externally (!) to change certain macros.
Given that the original bug was about a crash occurring during
unfolding, the second solution is a bit like curing a pain by
amputation...


Sure. However, as I understand it now, this feature is not implemented in a
way that fits with the math inset infrastructure. I do not have the time for
a complete rewrite, and I honestly don't know what to do. At least I know
now that the fold/unfold feature is actually used.


I would really appreciate a long-term solution to the math macro bugs.
It would be useful to know whether many other people had segmentation
faults because of macros, because I suspect that these crashes have been
under-reported due to how hard they were to reproduce.


I believe that not so many people are macro power users. I would guess that
we would get many more reports otherwise.


Georg





Do you think that it would solve all the crashes currently happening due 
to macros, or would your solution only prevent crashes happening while 
unfolding?


Personally I would rather suffer from the occasional crash than losing 
unfolding... :)



Guillaume

Re: math macro crashes again (bug 9490)


On 05/14/15 20:37, Jean-Marc Lasgouttes wrote:

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This
allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it,
then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that
I have tried it, I am not so sure why it is useful. Moreover it uses
bindings that are not accessible with my french kbd. Why doesn't this
use inset-toggle? Why isn't macro-fold a toggle?

JMarc




Dear Jean-Marc,


Macro power user here, as Georg wrote...

My typical use case is to change the macro while keeping the same 
arguments. In the absolute, it is easy to see that this can be useful 
occasionally at least. Indeed, in the absence of macro-unfolding, the 
alternative is to copy and paste the arguments one by one from the old 
macro to the new macro. With unfolding, one just edits the name of the 
macro, benefiting from name completion, etc.


But, also, once one is aware of unfolding, one can start using it more 
systematically, because one can define similar, but different, macros, 
and switch between them when it is needed. (I can give you practical 
examples if you want...) I currently do not know how to achieve 
something similar without unfolding.


In fact, I do not care so much about macro unfolding itself than the 
possibility of changing the macro in-place (with name completion). Am I 
missing anything?


About toggling, they had this discussion before some years ago: 
http://marc.info/?l=lyx-develm=122071560319193w=1. I admit that I 
don't use repeated unfolding so much. In addition, I do not use macro 
folding because the macros folds itself automatically once the name is 
changed. (But if other power users of unfolding and folding are reading 
this they will surely speak up, right?)


I hope this clarifies.


Best
Guillaume

Re: Problem whith Shaded menu


On 05/14/15 16:25, hatim ali wrote:

Dear lyx team
Thank you for good job.
I used lyx 2.2 with ubuntu.
When i start lyx then dropdown any menu like File, Edit, Insert, i got
shaded commands, i mean the first 3 or 4 command in the list ( enable )
but others was disbale ( shaded - unable to click).
To resolve this problem, must change lyx interface language from
Preferences... > save, then retern to default languge then save.


Best regards



Dear Ali,

Could this be your problem? 
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059


If so, then it is a bug with indicator-appmenu. I proposed a patch two 
weeks ago and we are waiting for the developer to look at it. In the 
meanwhile you'll find a workaround to disable the appmenu.



Best
Guillaume

Re: math macro crashes again (bug 9490)


On 05/14/15 19:46, Georg Baum wrote:

Guillaume M-M wrote:


Thank you for looking at these bugs. I reported 9418 and 9490, and I use
macro unfolding quite often. Before discovering this feature, I would
occasionally edit the lyx file externally (!) to change certain macros.
Given that the original bug was about a crash occurring during
unfolding, the second solution is a bit like curing a pain by
amputation...


Sure. However, as I understand it now, this feature is not implemented in a
way that fits with the math inset infrastructure. I do not have the time for
a complete rewrite, and I honestly don't know what to do. At least I know
now that the fold/unfold feature is actually used.


I would really appreciate a long-term solution to the math macro bugs.
It would be useful to know whether many other people had segmentation
faults because of macros, because I suspect that these crashes have been
under-reported due to how hard they were to reproduce.


I believe that not so many people are macro power users. I would guess that
we would get many more reports otherwise.


Georg





Do you think that it would solve all the crashes currently happening due 
to macros, or would your solution only prevent crashes happening while 
unfolding?


Personally I would rather suffer from the occasional crash than losing 
unfolding... :)



Guillaume

Re: math macro crashes again (bug 9490)


On 05/14/15 20:37, Jean-Marc Lasgouttes wrote:

Le 14/05/2015 21:00, Georg Baum a écrit :

Jean-Marc Lasgouttes wrote:


I think I do not understand yet what an argumentproxy really is. Could
you explain that to me (again??)?


It is a dummy inset that can be used like a MathInset from outside, but
forwards every work to the math macro cell that it represents. This
allows
to store the expanded cells in a standard MathData, and it also allows to
manage the cells like any other math inset if they are detached from the
macro (well it would allow that if the bug we are currently discussing
would not exist).


Is there one per macro use or one per argument?


Would it make sense for the macro inset to hold a copy of the argument
proxy instead of a pointer? And then this copy would be somehow updated
as needed.


It is the other way round: The proxy holds a pointer to the math macro.


Could we make a copy of the macro, then?



What is math macro unfolding exactly?


In folded mode, the macro itself is not drawn unless you enter it,
then the
name is drawn in light grey at the top left corner. In unfolded mode, the
macro name is drawn like ERT, and you can change it.


I had to grep the code to understand how to unfold a macro. And now that
I have tried it, I am not so sure why it is useful. Moreover it uses
bindings that are not accessible with my french kbd. Why doesn't this
use inset-toggle? Why isn't macro-fold a toggle?

JMarc




Dear Jean-Marc,


"Macro power user" here, as Georg wrote...

My typical use case is to change the macro while keeping the same 
arguments. In the absolute, it is easy to see that this can be useful 
occasionally at least. Indeed, in the absence of macro-unfolding, the 
alternative is to copy and paste the arguments one by one from the old 
macro to the new macro. With unfolding, one just edits the name of the 
macro, benefiting from name completion, etc.


But, also, once one is aware of unfolding, one can start using it more 
systematically, because one can define similar, but different, macros, 
and switch between them when it is needed. (I can give you practical 
examples if you want...) I currently do not know how to achieve 
something similar without unfolding.


In fact, I do not care so much about macro unfolding itself than the 
possibility of changing the macro in-place (with name completion). Am I 
missing anything?


About toggling, they had this discussion before some years ago: 
. I admit that I 
don't use repeated unfolding so much. In addition, I do not use macro 
folding because the macros folds itself automatically once the name is 
changed. (But if other power users of unfolding and folding are reading 
this they will surely speak up, right?)


I hope this clarifies.


Best
Guillaume

Re: math macro crashes again (bug 9490)

2015-05-13 Thread Guillaume M-M


On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d-expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d-expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied = pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the self-contained property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume

Re: math macro crashes again (bug 9490)

2015-05-13 Thread Guillaume M-M


On 05/13/15 21:34, Georg Baum wrote:

Hi,

after a lot of debugging I understand now what happens in
http://www.lyx.org/trac/ticket/9490. As you may recall, the last math macro
crash I fixed (9418) was caused by a broken ArgumentProxy::mathMacro_
pointer. At that time, I assumed that the only place where an ArgumentProxy
can occur is as an element of MathMacro::d->expanded_ (which is also
indicated by the comment in ArgumentProxy::draw(). Under this assumption,
the fix for 9418 would have fixed all cases of invalid mathMacro_ pointers.

However, this assumption is not true. In MathData::detachMacroParameters(),
elements of MathMacro::d->expanded_ can be extracted and put into the same
vector as the macro itself. Unfortunately, if you insert an element into a
vector, the existing elements may be copied => pointers may become invalid.
The fix for 9419 does not work for this case, since the ArgumentProxy
instances in question are already extracted from the macro and stored in the
local variable detachedArgs.

It would be relatively easy to do a local fix in
MathData::detachMacroParameters(). However, since the detached ArgumentProxy
instances stay alive after leaving MathData::detachMacroParameters(), this
is not enough.

I tried to keep a record of each ArgumentProxy child in a new member of the
MathMacro itself. Then ArgumentProxy::setOwner() can be called reliably
whenever a copy of a MathMacro is made. This works fine, but exposes another
problem: When following the recipe of bug 9490, a MathMacro instance is
deleted in Undo::Private::doTextUndoOrRedo() while an ArgumentProxy pointing
to it is still alive.

What to do now? I don't know. I see the following options:

- Change the base class of MathData to RandomAccessList as proposed by Abdel
in the discussion of 9419. This would solve the invalid pointer problems,
but not the problem showed by the undo stack, and I fear that more hidden
problems like this one exist. To me it is now more clear than during the
discussion of 9418 that the "self-contained" property of a MathInset is
really really important and assumed implicitly all over the place. The
ArgumentProxy is not self-contained, and this is the root of all evil.

- Get rid of MathData::detachMacroParameters(). This would be a feature
regression: Unfolding a math macro would no longer be possible. Is this an
important feature?

- Rewrite ArgumentProxy to get rid of the mathMacro_ pointer (or even get
rid of the class ArgumentProxy). This is a big task.


Any other ideas? Preferences? Unless somebody has a brilliant idea I tend
towards the second item, since the first does not solve all problems, and
the last is too much work for me ATM.



Georg





Dear Georg,


Thank you for looking at these bugs. I reported 9418 and 9490, and I use 
macro unfolding quite often. Before discovering this feature, I would 
occasionally edit the lyx file externally (!) to change certain macros. 
Given that the original bug was about a crash occurring during 
unfolding, the second solution is a bit like curing a pain by amputation...


I would really appreciate a long-term solution to the math macro bugs. 
It would be useful to know whether many other people had segmentation 
faults because of macros, because I suspect that these crashes have been 
under-reported due to how hard they were to reproduce.


Thank you again for the hard work.


Best,
Guillaume

Re: LyX is broken on Ubuntu 15.04

2015-05-03 Thread Guillaume M-M

Hi Jean-Marc,

On 05/01/15 23:46, Jean-Marc Lasgouttes wrote:

Hi Guillaume,

I am in vacation this week, but I will look at what I can do next week. What
would be helpful is a description of what indicator happens expects. The menu
code in LyX has mostly been done in an empirical way.

In the meanwhile I looked a bit further, but I'll leave it there. See
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059.

Apparently, dbusmenu is going to be deprecated anyway
http://askubuntu.com/a/139925. So I am happy if the previous behaviour
is just restored, as with the patch (for indicator-appmenu) that I proposed.

Your workaround is intriguing. Is there a general notion of global menu bar in
Qt? Currently we have special code for MacOS, it could maybe be expanded to
cover unity too.

You can have a look at g/qmenumodel https://launchpad.net/qmenumodel,
which is going to replace dbusmenu. Maybe that with qmenumodel you can
extend the code for MacOS to cover the Unity global menu. This would be
a nice feature, and maybe leave the current problems behind.

Another possibility is that we should react to some signals.

See https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059, it
seems unlikely.

Guillaume

JMarc

Le 30 avril 2015 02:12:15 CEST, Guillaume M-M ga...@free.fr a écrit :

Dear list,

The bug appeared in indicator-appmenu after the following commit:

http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.15.04/revision/267

See
https://bugs.launchpad.net/indicator-appmenu/+bug/1430059/comments/20

for more details. I continued the discussion there because it is not
clear if the bug is in lyx or indicator-appmenu.

Scott, I am willing to test out any patch against master on 15.04.

In the meanwhile the workaround is to run lyx with the command line:
QT_X11_NO_NATIVE_MENUBAR=1 lyx

or to adapt /usr/share/applications/lyx.desktop as follows:
Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lyx %F

Re: LyX is broken on Ubuntu 15.04

2015-05-03 Thread Guillaume M-M

Hi Jean-Marc,

On 05/01/15 23:46, Jean-Marc Lasgouttes wrote:

Hi Guillaume,

In the meanwhile I looked a bit further, but I'll leave it there. See
<https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059>.

Apparently, dbusmenu is going to be deprecated anyway
<http://askubuntu.com/a/139925>. So I am happy if the previous behaviour
is just restored, as with the patch (for indicator-appmenu) that I proposed.

Your workaround is intriguing. Is there a general notion of global menu bar in
Qt? Currently we have special code for MacOS, it could maybe be expanded to
cover unity too.

You can have a look at g/qmenumodel <https://launchpad.net/qmenumodel>,
which is going to replace dbusmenu. Maybe that with qmenumodel you can
extend the code for MacOS to cover the Unity global menu. This would be
a nice feature, and maybe leave the current problems behind.

Another possibility is that we should react to some signals.

See <https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059>, it
seems unlikely.

Guillaume

JMarc

Le 30 avril 2015 02:12:15 CEST, Guillaume M-M <ga...@free.fr> a écrit :

Dear list,

The bug appeared in indicator-appmenu after the following commit:

<http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.15.04/revision/267>

See
<https://bugs.launchpad.net/indicator-appmenu/+bug/1430059/comments/20>

for more details. I continued the discussion there because it is not
clear if the bug is in lyx or indicator-appmenu.

Scott, I am willing to test out any patch against master on 15.04.

In the meanwhile the workaround is to run lyx with the command line:
QT_X11_NO_NATIVE_MENUBAR=1 lyx

or to adapt /usr/share/applications/lyx.desktop as follows:
Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lyx %F

Re: LyX is broken on Ubuntu 15.04

On 04/25/15 07:18, Scott Kostyshak wrote:

Reported to lyx-users here:
https://www.mail-archive.com/lyx-users@lists.lyx.org/msg100825.html

Reported and confirmed by multiple users here:
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059

I've reproduced this with both self-compiled and from the repos.

The reason for why the menus are greyed out is not because the LFUNs
are disabled. In fact, if you run the command on the minibuffer it
works just fine. The problem is that Menu::updateView() is not even
being called when I click on the menu categories. For example, usually
(when this bug does not appear, e.g. on Ubuntu 14.10)
Menu::updateView() is called twice every time I click on Document (I
would be curious to know by the way why it is called twice and not
once). But on 15.04 it is not called at all when I click on the
Document menu.

I have found a (partial) work around: if you press alt in Ubuntu it
brings up the HUD which searches the menu of the open application. For
example, if I press alt and then sett it shows me Settings
(Document), meaning that it found an entry under Document that
matches my search string. I can then press return and it is as if I
went to Document Settings. After I open the HUD and type a letter,
all of the menus are refreshed (Menu::updateView() was called).
However, you have to do this each time you want the menus to be
refreshed.

Does anyone feel like using Virtual Box to test out LyX on 15.04?

Scott

Dear list,

The bug appeared in indicator-appmenu after the following commit:

http://bazaar.launchpad.net/~indicator-applet-developers/indicator-appmenu/trunk.15.04/revision/267

See
https://bugs.launchpad.net/indicator-appmenu/+bug/1430059/comments/20
for more details. I continued the discussion there because it is not
clear if the bug is in lyx or indicator-appmenu.

Scott, I am willing to test out any patch against master on 15.04.

In the meanwhile the workaround is to run lyx with the command line:
QT_X11_NO_NATIVE_MENUBAR=1 lyx

or to adapt /usr/share/applications/lyx.desktop as follows:
Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lyx %F

Guillaume

Re: LyX is broken on Ubuntu 15.04


On 04/30/15 01:12, Guillaume M-M wrote:

See
https://bugs.launchpad.net/indicator-appmenu/+bug/1430059/comments/20
for more details. I continued the discussion there because it is not
clear if the bug is in lyx or indicator-appmenu.


moved:
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059/comments/20

(also in /ubuntu/+source/indicator-appmenu/)

Re: LyX is broken on Ubuntu 15.04


On 04/25/15 07:18, Scott Kostyshak wrote:

Reported to lyx-users here:
https://www.mail-archive.com/lyx-users@lists.lyx.org/msg100825.html

Reported and confirmed by multiple users here:
https://bugs.launchpad.net/ubuntu/+source/lyx/+bug/1430059

I've reproduced this with both self-compiled and from the repos.

The reason for why the menus are greyed out is not because the LFUNs
are disabled. In fact, if you run the command on the minibuffer it
works just fine. The problem is that Menu::updateView() is not even
being called when I click on the menu categories. For example, usually
(when this bug does not appear, e.g. on Ubuntu 14.10)
Menu::updateView() is called twice every time I click on "Document" (I
would be curious to know by the way why it is called twice and not
once). But on 15.04 it is not called at all when I click on the
"Document" menu.

I have found a (partial) work around: if you press "alt" in Ubuntu it
brings up the HUD which searches the menu of the open application. For
example, if I press alt and then "sett" it shows me "Settings
(Document)", meaning that it found an entry under Document that
matches my search string. I can then press return and it is as if I
went to Document > Settings. After I open the HUD and type a letter,
all of the menus are refreshed (Menu::updateView() was called).
However, you have to do this each time you want the menus to be
refreshed.

Does anyone feel like using Virtual Box to test out LyX on 15.04?

Scott




Dear list,


The bug appeared in indicator-appmenu after the following commit:



See 
 
for more details. I continued the discussion there because it is not 
clear if the bug is in lyx or indicator-appmenu.


Scott, I am willing to test out any patch against master on 15.04.

In the meanwhile the workaround is to run lyx with the command line:
  QT_X11_NO_NATIVE_MENUBAR=1 lyx

or to adapt /usr/share/applications/lyx.desktop as follows:
  Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lyx %F


Guillaume

Re: LyX is broken on Ubuntu 15.04