LyX 2.3.1 on Xubuntu 18.04.1 bug: crashes when opening LyX files with graphics

[Jeff Defoe]

(  1) lyx: lyx() [0x8de95d]
(  2) lyx: lyx() [0x8b]
(  3) lyx: lyx() [0x5a13dc]
(  4) /lib/x86_64-linux-gnu/libc.so.6:
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f83f8afaf20]
(  5) lyx: lyx() [0x902e5d]
(  6) lyx: lyx() [0x90164c]
(  7) lyx: lyx() [0x90b451]
(  8) lyx: lyx() [0x6e9d1b]
(  9) lyx: lyx() [0x6eba5b]
( 10) lyx: lyx() [0x661239]
( 11) lyx: lyx() [0x661932]
( 12) lyx: lyx() [0x8b7b22]
( 13) lyx: lyx() [0x7e899f]
( 14) lyx: lyx() [0x6eb595]
( 15) lyx: lyx() [0x6eba16]
( 16) lyx: lyx() [0x661239]
( 17) lyx: lyx() [0x661932]
( 18) lyx: lyx() [0x6adf43]
( 19) lyx: lyx() [0x93e374]
( 20) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 21) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QFrame::event(QEvent*)
( 22) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*)
( 23) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 24) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QApplication::notify(QObject*, QEvent*)
( 25) lyx: lyx() [0x8f134c]
( 26) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 27) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&,
int, QPainter*, QWidgetBackingStore*)
( 28) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x3eadc8) [0x7f83fa400dc8]
( 29) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QWidgetPrivate::syncBackingStore()
( 30) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QWidget::event(QEvent*)
( 31) /usr/lib/x86_64-linux-gnu/libQtGui.so.4: QMainWindow::event(QEvent*)
( 32) lyx: lyx() [0x92d70d]
( 33) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 34) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
QApplication::notify(QObject*, QEvent*)
( 35) lyx: lyx() [0x8f134c]
( 36) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QCoreApplication::notifyInternal(QObject*, QEvent*)
( 37) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
( 38) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
/usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1bb09e) [0x7f83f9cdf09e]
( 39) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0:
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2e7)
[0x7f83f85ee287]
( 40) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0:
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c4c0) [0x7f83f85ee4c0]
( 41) /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0:
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)
[0x7f83f85ee54c]
( 42) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QEventDispatcherGlib::processEvents(QFlags)
( 43) /usr/lib/x86_64-linux-gnu/libQtGui.so.4:
/usr/lib/x86_64-linux-gnu/libQtGui.so.4(+0x272666) [0x7f83fa288666]
( 44) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QEventLoop::processEvents(QFlags)
( 45) /usr/lib/x86_64-linux-gnu/libQtCore.so.4:
QEventLoop::exec(QFlags)
( 46) /usr/lib/x86_64-linux-gnu/libQtCore.so.4: QCoreApplication::exec()
( 47) lyx: lyx() [0x5aa17d]
( 48) lyx: lyx() [0x43d5ad]
( 49) /lib/x86_64-linux-gnu/libc.so.6:
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f83f8addb97]
( 50) lyx: lyx() [0x449539]

Re: No screen font smoothing in a Parallels VM

[Jean-Marc Lasgouttes]

Le 1 novembre 2018 20:04:44 GMT+00:00, Chris Menzel  a 
écrit :
>Problem solved! I upgraded to KDE Plasma version 5.14.2 (via the
>backports
>PPA) and LyX 2.3.1 and that solved the problem. (Not sure if either of
>itself would have done the job.) Thanks again to the LyX (and KDE)
>developers.

Normally it is LyX 2.3.1  which did the trick.

JMarc

Re: Patch test with several minor dialog alignment fixes

[Scott Kostyshak]

On Thu, Nov 01, 2018 at 09:35:25PM +0100, Daniel wrote:
> On 2018-11-01 21:07, Scott Kostyshak wrote:
> > On Thu, Nov 01, 2018 at 05:18:18PM +0100, Daniel wrote:
> > > On 01/11/2018 16:58, Scott Kostyshak wrote:
> > > > On Thu, Nov 01, 2018 at 06:52:11AM +0100, Daniel wrote:
> > > > 
> > > > > Great. And by the way, while I tend to think all the changes I make 
> > > > > sense, I
> > > > > can change things on feedback.
> > > > 
> > > > Sounds good. One comment which I'm not sure is relevant is: often Qt
> > > > Creator reformats a bunch of things when you save. I find it helpful if
> > > > you just save a version that only contains the reformatting. This is the
> > > > analog of in LyX, when opening a 2.2.x document in LyX 2.3.x, save a
> > > > no-op (e.g. make a change, then save, then undo the change, then save).
> > > > Then, commit that. Then commit your changes in a separate commit. This
> > > > will make it easier to see exactly what you changed. I don't suggest you
> > > > go back and redo things, but I would prefer this for future changes (you
> > > > might want to check with others though; perhaps this is just my personal
> > > > preference).
> > > 
> > > I am not sure I can follow. Is the idea to make two commits? One with the
> > > changes and one with the changes undone?
> > 
> > The idea is to make two commits: one with possibly changes to style, and
> > one with actual content change. It might be that the first commit is
> > unnecessary. To see, do the following: open a .ui file, make a change,
> > save, undo the change, save. If there is no diff, then this commit is
> > unnecessary. If there is a diff, then commit that. Sometimes newer Qt
> > Creator versions just add whitespace somewhere or have a different
> > style.
> > 
> > The analog is like opening a 2.2.x file in LyX 2.3.x. It makes sense to
> > commit just the lyx2lyx changes before committing changes to actual
> > content. Otherwise, it's not clear what changes are just the different
> > format and which changes are to the content.
> 
> Thanks, got it.
> 
> Another thing I realized is that when moving elements and back again to try
> things out in Creator this sometimes still causes changes. So, it might be
> better to undo changes using the undo function rather than "manually"
> undoing.

Good to know. That makes sense. I think the key is to save before doing
undo, otherwise the buffer might not be marked as dirty.

An alternative might be to not do any operation and just use "Save As"
instead.

Scott


signature.asc
Description: PGP signature

Re: No PDF viewer installed

[Richard Kimberly Heck]

On 11/1/18 4:39 PM, Daniel wrote:
> On 2018-11-01 20:50, Andrew Parsloe wrote:
>> On 2/11/2018 1:33 a.m., Daniel wrote:
>>> On 01/11/2018 13:13, Kornel Benko wrote:
 Am Donnerstag, 1. November 2018 12:56:08 CET schrieb Daniel
 :
> I am still getting the "No PDF viewer installed" error message when
> "pdfview" is selected as Viewer. I am a bit lost whether this
> should be
> fixed by now or not in 2.3.1. I saw that the "pdfview" option is
> missing
> in current master. Maybe that will be the "fix"?
>
> Daniel
>
>

 As far as I can see, configure.py checks for pdfview. See
 configure.py:716

 The only reason I can imagine is, that it is not found in searched
 PATH.

 Kornel

>>>
>>> It seems that pdfview itself is the problem. When I execute it, I
>>> get the exact same error dialog.
>>>
>>> Probably worth mentioning: I have a number of PDF viewers installed
>>> including Adobe Reader and SumartaPDF.
>>>
>>> Daniel
>> Using 2.3.1-1 on windows 7, the problem is fixed on my system. It
>> requires a system-wide association of .pdf filetypes with a viewer
>> (Sumatra in my case, but I changed it to Adobe reader to test and
>> that worked too). I (dimly) remember Riki doing something about
>> pdfview for 2.3.1-1.
>>
>> Andrew
>
> I actually have neither Adobe nor Sumatra as default reader but Edge
> (I know...). I'll try tomorrow whether this makes any difference.

What pdfview is SUPPOSED to do is find out what viewer is installed for
PDF files and then do magic tricks if it's Acrobat, but otherwise just
launch that viewer. For whatever reason, the system call to do this
fails on Windows 10 unless some viewer has been explicitly configured.
(I.e., if there's just a 'default' viewer, then it seems we get nothing
back.) Presumably there's some new system call that can be made here,
but I would not know what it is. That's the problem.

Maybe we should try writing something in Python to do this.

Riki

Re: No PDF viewer installed

[Daniel]

On 2018-11-01 20:50, Andrew Parsloe wrote:

On 2/11/2018 1:33 a.m., Daniel wrote:

On 01/11/2018 13:13, Kornel Benko wrote:
Am Donnerstag, 1. November 2018 12:56:08 CET schrieb Daniel 
:

I am still getting the "No PDF viewer installed" error message when
"pdfview" is selected as Viewer. I am a bit lost whether this should be
fixed by now or not in 2.3.1. I saw that the "pdfview" option is 
missing

in current master. Maybe that will be the "fix"?

Daniel




As far as I can see, configure.py checks for pdfview. See 
configure.py:716


The only reason I can imagine is, that it is not found in searched PATH.

Kornel



It seems that pdfview itself is the problem. When I execute it, I get 
the exact same error dialog.


Probably worth mentioning: I have a number of PDF viewers installed 
including Adobe Reader and SumartaPDF.


Daniel
Using 2.3.1-1 on windows 7, the problem is fixed on my system. It 
requires a system-wide association of .pdf filetypes with a viewer 
(Sumatra in my case, but I changed it to Adobe reader to test and that 
worked too). I (dimly) remember Riki doing something about pdfview for 
2.3.1-1.


Andrew


I actually have neither Adobe nor Sumatra as default reader but Edge (I 
know...). I'll try tomorrow whether this makes any difference.


Daniel

Re: Patch test with several minor dialog alignment fixes

[Daniel]

On 2018-11-01 21:07, Scott Kostyshak wrote:

On Thu, Nov 01, 2018 at 05:18:18PM +0100, Daniel wrote:

On 01/11/2018 16:58, Scott Kostyshak wrote:

On Thu, Nov 01, 2018 at 06:52:11AM +0100, Daniel wrote:


Great. And by the way, while I tend to think all the changes I make sense, I
can change things on feedback.


Sounds good. One comment which I'm not sure is relevant is: often Qt
Creator reformats a bunch of things when you save. I find it helpful if
you just save a version that only contains the reformatting. This is the
analog of in LyX, when opening a 2.2.x document in LyX 2.3.x, save a
no-op (e.g. make a change, then save, then undo the change, then save).
Then, commit that. Then commit your changes in a separate commit. This
will make it easier to see exactly what you changed. I don't suggest you
go back and redo things, but I would prefer this for future changes (you
might want to check with others though; perhaps this is just my personal
preference).


I am not sure I can follow. Is the idea to make two commits? One with the
changes and one with the changes undone?


The idea is to make two commits: one with possibly changes to style, and
one with actual content change. It might be that the first commit is
unnecessary. To see, do the following: open a .ui file, make a change,
save, undo the change, save. If there is no diff, then this commit is
unnecessary. If there is a diff, then commit that. Sometimes newer Qt
Creator versions just add whitespace somewhere or have a different
style.

The analog is like opening a 2.2.x file in LyX 2.3.x. It makes sense to
commit just the lyx2lyx changes before committing changes to actual
content. Otherwise, it's not clear what changes are just the different
format and which changes are to the content.


Thanks, got it.

Another thing I realized is that when moving elements and back again to 
try things out in Creator this sometimes still causes changes. So, it 
might be better to undo changes using the undo function rather than 
"manually" undoing.


Daniel

Re: No PDF viewer installed

[Richard Kimberly Heck]

On 11/1/18 3:50 PM, Andrew Parsloe wrote:
> On 2/11/2018 1:33 a.m., Daniel wrote:
>> On 01/11/2018 13:13, Kornel Benko wrote:
>>> Am Donnerstag, 1. November 2018 12:56:08 CET schrieb Daniel
>>> :
 I am still getting the "No PDF viewer installed" error message when
 "pdfview" is selected as Viewer. I am a bit lost whether this
 should be
 fixed by now or not in 2.3.1. I saw that the "pdfview" option is
 missing
 in current master. Maybe that will be the "fix"?

 Daniel


>>>
>>> As far as I can see, configure.py checks for pdfview. See
>>> configure.py:716
>>>
>>> The only reason I can imagine is, that it is not found in searched
>>> PATH.
>>>
>>> Kornel
>>>
>>
>> It seems that pdfview itself is the problem. When I execute it, I get
>> the exact same error dialog.
>>
>> Probably worth mentioning: I have a number of PDF viewers installed
>> including Adobe Reader and SumartaPDF.
>>
>> Daniel
> Using 2.3.1-1 on windows 7, the problem is fixed on my system. It
> requires a system-wide association of .pdf filetypes with a viewer
> (Sumatra in my case, but I changed it to Adobe reader to test and that
> worked too). I (dimly) remember Riki doing something about pdfview for
> 2.3.1-1.


I'll try to have a look at this again for the 2.3.2 release, but I don't
think we've solved any of the pdfview problems yet.

The whole thing is a hack to work around the fact that Acrobat locks the
pdf file when you view it, so you can't use View> Update to see any
updated view.

Riki

Re: Patch test with several minor dialog alignment fixes

[Scott Kostyshak]

On Thu, Nov 01, 2018 at 05:18:18PM +0100, Daniel wrote:
> On 01/11/2018 16:58, Scott Kostyshak wrote:
> > On Thu, Nov 01, 2018 at 06:52:11AM +0100, Daniel wrote:
> > 
> > > Great. And by the way, while I tend to think all the changes I make 
> > > sense, I
> > > can change things on feedback.
> > 
> > Sounds good. One comment which I'm not sure is relevant is: often Qt
> > Creator reformats a bunch of things when you save. I find it helpful if
> > you just save a version that only contains the reformatting. This is the
> > analog of in LyX, when opening a 2.2.x document in LyX 2.3.x, save a
> > no-op (e.g. make a change, then save, then undo the change, then save).
> > Then, commit that. Then commit your changes in a separate commit. This
> > will make it easier to see exactly what you changed. I don't suggest you
> > go back and redo things, but I would prefer this for future changes (you
> > might want to check with others though; perhaps this is just my personal
> > preference).
> 
> I am not sure I can follow. Is the idea to make two commits? One with the
> changes and one with the changes undone?

The idea is to make two commits: one with possibly changes to style, and
one with actual content change. It might be that the first commit is
unnecessary. To see, do the following: open a .ui file, make a change,
save, undo the change, save. If there is no diff, then this commit is
unnecessary. If there is a diff, then commit that. Sometimes newer Qt
Creator versions just add whitespace somewhere or have a different
style.

The analog is like opening a 2.2.x file in LyX 2.3.x. It makes sense to
commit just the lyx2lyx changes before committing changes to actual
content. Otherwise, it's not clear what changes are just the different
format and which changes are to the content.

Scott


signature.asc
Description: PGP signature

Re: No screen font smoothing in a Parallels VM

[Chris Menzel]

Problem solved! I upgraded to KDE Plasma version 5.14.2 (via the backports
PPA) and LyX 2.3.1 and that solved the problem. (Not sure if either of
itself would have done the job.) Thanks again to the LyX (and KDE)
developers.

Chris Menzel


On Thu, Nov 1, 2018 at 12:07 PM Chris Menzel  wrote:

> Dear Lyx folk,
>
> I've just installed Parallels on my iMac in part because LyX runs so well
> under Linux and Parallels creates very robust virtual machines (indeed,
> some things in Linux (like trackpad gestures) work *better* in a Parallels
> VM). LyX looks fantastic running natively on my (hi-res) iMac (the current
> problems with boldface notwithstanding) and running natively on my
> Dell laptop under Linux. But for some reason, when I run it under Linux in
> a Parallels VM on my iMac, I'm not getting any font smoothing; screen fonts
> are jaggy and pixelated. All other Linux apps looks great in the VM,
> including those using the same screen font. I've attached a couple of
> screensgrabs to illustrate the problem, one showing the lack of font
> smoothing in LyX and another showing how the same font looks in all other
> Linux apps. Is this a known issue? And, if so, is there a fix? I haven't
> turned up anything after a lot of googling.
>
> Thanks for any ideas here.
>
> Chris Menzel
>

Re: Build LyX with MSVC 2017

[Jean-Marc Lasgouttes]

Le 23/10/2018 à 08:39, Kornel Benko a écrit :


Sure. They can and they would if not having the necessary tools.
OTOH, it makes sense to me to install with NLS if possible.

There is always the possibility to not use LYX_INSTALL (unfortunately i cannot 
test on Windows)


It is normal that NLS is on by default. But if people opt out of it, we 
should respect that.


JMarc

Re: No screen font smoothing in a Parallels VM

[Jean-Marc Lasgouttes]

Le 01/11/2018 à 17:07, Chris Menzel a écrit :

Dear Lyx folk,

I've just installed Parallels on my iMac in part because LyX runs so 
well under Linux and Parallels creates very robust virtual machines 
(indeed, some things in Linux (like trackpad gestures) work *better* in 
a Parallels VM). LyX looks fantastic running natively on my (hi-res) 
iMac (the current problems with boldface notwithstanding) and running 
natively on my Dell laptop under Linux. But for some reason, when I run 
it under Linux in a Parallels VM on my iMac, I'm not getting any font 
smoothing; screen fonts are jaggy and pixelated. 

Dear Chris,

What version of LyX is that?

JMarc

Re: No PDF viewer installed

[Andrew Parsloe]

On 2/11/2018 1:33 a.m., Daniel wrote:

On 01/11/2018 13:13, Kornel Benko wrote:
Am Donnerstag, 1. November 2018 12:56:08 CET schrieb Daniel 
:

I am still getting the "No PDF viewer installed" error message when
"pdfview" is selected as Viewer. I am a bit lost whether this should be
fixed by now or not in 2.3.1. I saw that the "pdfview" option is 
missing

in current master. Maybe that will be the "fix"?

Daniel




As far as I can see, configure.py checks for pdfview. See 
configure.py:716


The only reason I can imagine is, that it is not found in searched PATH.

Kornel



It seems that pdfview itself is the problem. When I execute it, I get 
the exact same error dialog.


Probably worth mentioning: I have a number of PDF viewers installed 
including Adobe Reader and SumartaPDF.


Daniel
Using 2.3.1-1 on windows 7, the problem is fixed on my system. It 
requires a system-wide association of .pdf filetypes with a viewer 
(Sumatra in my case, but I changed it to Adobe reader to test and that 
worked too). I (dimly) remember Riki doing something about pdfview for 
2.3.1-1.


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [LyX/master] Fix parentheses with Hebrew

[Richard Kimberly Heck]

On 11/1/18 2:23 PM, Kornel Benko wrote:
> Am Donnerstag, 1. November 2018 19:21:22 CET schrieb Kornel Benko 
> :
>> Am Donnerstag, 1. November 2018 19:24:50 CET schrieb Guy Rutenberg 
>> :
>>> Hi,
>>>
>>> On Thu, 1 Nov 2018 at 18:43, Richard Kimberly Heck  wrote:
>>>
 My second suggestion in the last email is along these lines, too. I
 should have added that it is only when the language is Hebrew that we do
 any of the other tests. (We have to go through the whole file, of
 course, to find out whether Hebrew is ever used.)

 I've followed the suggestion and now it runs much faster. See my attached
>>> patch.
>>>
>>> Thanks,
>>> Guy
>> Sorry, with this patch the conversion is fast, but unfortunately also fails.
>>
> This is the error, if used manually
>
> Traceback (most recent call last):
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx", line 24, in 
> import LyX
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/LyX.py", line 107, in 
> convert = getattr(__import__("lyx_" + step), mode)
>   File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx_2_4.py", line 39, in 
> from lyx2lyx_tools import (put_cmd_in_ert, add_to_preamble, 
> get_language_for_line)
> ImportError: cannot import name 'get_language_for_line'

Right, we just need to remove that from the import line. (Guy introduced
then deleted that routine.)

Riki

Re: [LyX/master] Fix parentheses with Hebrew

[Kornel Benko]

Am Donnerstag, 1. November 2018 19:21:22 CET schrieb Kornel Benko 
:
> Am Donnerstag, 1. November 2018 19:24:50 CET schrieb Guy Rutenberg 
> :
> > Hi,
> > 
> > On Thu, 1 Nov 2018 at 18:43, Richard Kimberly Heck  wrote:
> > 
> > >
> > > My second suggestion in the last email is along these lines, too. I
> > > should have added that it is only when the language is Hebrew that we do
> > > any of the other tests. (We have to go through the whole file, of
> > > course, to find out whether Hebrew is ever used.)
> > >
> > > I've followed the suggestion and now it runs much faster. See my attached
> > patch.
> > 
> > Thanks,
> > Guy
> 
> Sorry, with this patch the conversion is fast, but unfortunately also fails.
> 
This is the error, if used manually

Traceback (most recent call last):
  File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx2lyx", line 24, in 
import LyX
  File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/LyX.py", line 107, in 
convert = getattr(__import__("lyx_" + step), mode)
  File "/usr2/src/lyx/lyx-git/lib/lyx2lyx/lyx_2_4.py", line 39, in 
from lyx2lyx_tools import (put_cmd_in_ert, add_to_preamble, 
get_language_for_line)
ImportError: cannot import name 'get_language_for_line'

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Fix parentheses with Hebrew

[Kornel Benko]

Am Donnerstag, 1. November 2018 19:24:50 CET schrieb Guy Rutenberg 
:
> Hi,
> 
> On Thu, 1 Nov 2018 at 18:43, Richard Kimberly Heck  wrote:
> 
> >
> > My second suggestion in the last email is along these lines, too. I
> > should have added that it is only when the language is Hebrew that we do
> > any of the other tests. (We have to go through the whole file, of
> > course, to find out whether Hebrew is ever used.)
> >
> > I've followed the suggestion and now it runs much faster. See my attached
> patch.
> 
> Thanks,
> Guy

Sorry, with this patch the conversion is fast, but unfortunately also fails.

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Fix parentheses with Hebrew

[Guy Rutenberg]

Hi,

On Thu, 1 Nov 2018 at 18:43, Richard Kimberly Heck  wrote:

>
> My second suggestion in the last email is along these lines, too. I
> should have added that it is only when the language is Hebrew that we do
> any of the other tests. (We have to go through the whole file, of
> course, to find out whether Hebrew is ever used.)
>
> I've followed the suggestion and now it runs much faster. See my attached
patch.

Thanks,
Guy
From d6fe68cfbbb3e9cbd0fd9748ebb9b392dfc4bb96 Mon Sep 17 00:00:00 2001
From: Guy Rutenberg 
Date: Thu, 1 Nov 2018 19:23:17 +0200
Subject: [PATCH] Fix performance when fixing parentheses in Hebrew.

---
 lib/lyx2lyx/lyx2lyx_tools.py | 15 ---
 lib/lyx2lyx/lyx_2_4.py   | 10 ++
 2 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/lib/lyx2lyx/lyx2lyx_tools.py b/lib/lyx2lyx/lyx2lyx_tools.py
index 51412e5b31..73f7d78c10 100644
--- a/lib/lyx2lyx/lyx2lyx_tools.py
+++ b/lib/lyx2lyx/lyx2lyx_tools.py
@@ -83,9 +83,6 @@ insert_document_option(document, option):
 
 remove_document_option(document, option):
   Remove _option_ as a document option.
-
-get_language_for_line(document, i):
-  Return the language setting for line number i.
 '''
 
 import re
@@ -607,15 +604,3 @@ def is_document_option(document, option):
 return False
 
 return True
-
-
-def get_language_for_line(document, i):
-" Return the language for line number i"
-layout = get_containing_layout(document.body, i)
-if not layout:
-return document.language
-start_of_par = layout[3]
-for line in document.body[i:start_of_par:-1]:
-if line.startswith('\\lang '):
-return line[len('\\lang '):]
-return document.language
diff --git a/lib/lyx2lyx/lyx_2_4.py b/lib/lyx2lyx/lyx_2_4.py
index b6b626c316..670e31abfc 100644
--- a/lib/lyx2lyx/lyx_2_4.py
+++ b/lib/lyx2lyx/lyx_2_4.py
@@ -1383,11 +1383,13 @@ def revert_lformatinfo(document):
 
 def convert_hebrew_parentheses(document):
 " Don't reverse parentheses in Hebrew text"
+current_language = document.language
 for i, line in enumerate(document.body):
-if line.startswith(''):
-# not a text line, skip
-continue
-if get_language_for_line(document, i) == 'hebrew':
+if line.startswith('\\lang '):
+current_language = line[len('\\lang '):]
+elif line.startswith('\\end_layout'):
+current_language = document.language
+if current_language == 'hebrew' and not line.startswith('\\'):
 document.body[i] = line.replace('(','\x00').replace(')','(').replace('\x00',')')
 
 
-- 
2.11.0

Re: [LyX/master] Fix parentheses with Hebrew

[Richard Kimberly Heck]

On 11/1/18 12:26 PM, Jürgen Spitzmüller wrote:
> Am Donnerstag, den 01.11.2018, 18:09 +0200 schrieb Guy Rutenberg:
>> After some profiling the main culprit is the call to
>>
>> get_containing_layout, which is apparently some kind of O(n^2). For
>> example for de/Tutorial.lyx there are about ~5000 lines, and we
>> indeed call during the conversion we call get_containing_layout 5285
>> times. However, it calls find_end_of_layout a whopping 80936 times.
> I wonder whether you actually need this. Wouldn't it be more efficient
> to 
> 1. check whether the document uses Hebrew at all
> and
> 2. If so, search for parentheses and then check whether they follow a
> \\lang hebrew (and not any other \\lang) or whether they are in a
> document with main language hebrew and do not follow any other \\lang?

My second suggestion in the last email is along these lines, too. I
should have added that it is only when the language is Hebrew that we do
any of the other tests. (We have to go through the whole file, of
course, to find out whether Hebrew is ever used.)

Riki

Re: [LyX/master] Fix parentheses with Hebrew

[Richard Kimberly Heck]

On 11/1/18 12:09 PM, Guy Rutenberg wrote:
>
>
> On Thu, 1 Nov 2018 at 17:44, Jürgen Spitzmüller  > wrote:
>
> Am Donnerstag, den 01.11.2018, 16:26 +0100 schrieb Kornel Benko:
> > This would not be better.
>
> I was not saying it is good. I was just saying it's not a loop.
>
>
> After some profiling the main culprit is the call to
> get_containing_layout, which is apparently some kind of O(n^2). For
> example for de/Tutorial.lyx there are about ~5000 lines, and we indeed
> call during the conversion we call get_containing_layout 5285 times.
> However, it calls find_end_of_layout a whopping 80936 times.

I fought with these kinds of problems a while ago, too. Things like this
can be surprisingly slow.

I think get_containing_layout could be made a lot faster. The reason for
the complexity is that there might be "embedded" layouts (e.g., in a
footnote), so we can't just look for \\begin_layout. But we probably
could just keep going backwards, keeping track of this 'depth' as we go,
until we find the right \\begin_layout. Probably we could also somehow
make it optional how much info get_containing_layout returns. We do not
need the paragraph params here, for example.

A couple other possibilities.

1. Check first if there are any parens in the line. Only if there are
should we then call get_language_for_line.

2. Go at this differently and keep track, throughout the loop, of what
the current language is. We can start with the document language and
whenever we see a \\lang we switch to that language. We reset to the
document language whenever we see \\end_layout. That might be fastest.

Riki

Re: [LyX/master] Fix parentheses with Hebrew

[Jürgen Spitzmüller]

Am Donnerstag, den 01.11.2018, 18:09 +0200 schrieb Guy Rutenberg:
> After some profiling the main culprit is the call to
> 
> get_containing_layout, which is apparently some kind of O(n^2). For
> example for de/Tutorial.lyx there are about ~5000 lines, and we
> indeed call during the conversion we call get_containing_layout 5285
> times. However, it calls find_end_of_layout a whopping 80936 times.

I wonder whether you actually need this. Wouldn't it be more efficient
to 
1. check whether the document uses Hebrew at all
and
2. If so, search for parentheses and then check whether they follow a
\\lang hebrew (and not any other \\lang) or whether they are in a
document with main language hebrew and do not follow any other \\lang?

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: Patch test with several minor dialog alignment fixes

[Daniel]

On 01/11/2018 16:58, Scott Kostyshak wrote:

On Thu, Nov 01, 2018 at 06:52:11AM +0100, Daniel wrote:


Great. And by the way, while I tend to think all the changes I make sense, I
can change things on feedback.


Sounds good. One comment which I'm not sure is relevant is: often Qt
Creator reformats a bunch of things when you save. I find it helpful if
you just save a version that only contains the reformatting. This is the
analog of in LyX, when opening a 2.2.x document in LyX 2.3.x, save a
no-op (e.g. make a change, then save, then undo the change, then save).
Then, commit that. Then commit your changes in a separate commit. This
will make it easier to see exactly what you changed. I don't suggest you
go back and redo things, but I would prefer this for future changes (you
might want to check with others though; perhaps this is just my personal
preference).


I am not sure I can follow. Is the idea to make two commits? One with 
the changes and one with the changes undone?



Also, if you come across some oddity in a
dialog that I haven't caught yet, please let me know. I think I got the hang
of Qt Creator.


Thank you for this offer! I have a ticket that has been itching me for a
long time that I tried to fix but couldn't figure out how. I'll CC you
on it to see if you have any ideas, but no pressure :)


And I can't promise anything :)

Daniel

Re: [LyX/master] Fix parentheses with Hebrew

[Guy Rutenberg]

On Thu, 1 Nov 2018 at 17:44, Jürgen Spitzmüller  wrote:

> Am Donnerstag, den 01.11.2018, 16:26 +0100 schrieb Kornel Benko:
> > This would not be better.
>
> I was not saying it is good. I was just saying it's not a loop.
>
>
After some profiling the main culprit is the call to get_containing_layout,
which is apparently some kind of O(n^2). For example for de/Tutorial.lyx
there are about ~5000 lines, and we indeed call during the conversion we
call get_containing_layout 5285 times. However, it calls find_end_of_layout
a whopping 80936 times.

Another small issue, if the usage of range under Python2 which also
contributes quite a bit to the performance hit.

Jürg
>

Re: Patch test with several minor dialog alignment fixes

[Scott Kostyshak]

On Thu, Nov 01, 2018 at 06:52:11AM +0100, Daniel wrote:

> Great. And by the way, while I tend to think all the changes I make sense, I
> can change things on feedback.

Sounds good. One comment which I'm not sure is relevant is: often Qt
Creator reformats a bunch of things when you save. I find it helpful if
you just save a version that only contains the reformatting. This is the
analog of in LyX, when opening a 2.2.x document in LyX 2.3.x, save a
no-op (e.g. make a change, then save, then undo the change, then save).
Then, commit that. Then commit your changes in a separate commit. This
will make it easier to see exactly what you changed. I don't suggest you
go back and redo things, but I would prefer this for future changes (you
might want to check with others though; perhaps this is just my personal
preference).

> Also, if you come across some oddity in a
> dialog that I haven't caught yet, please let me know. I think I got the hang
> of Qt Creator.

Thank you for this offer! I have a ticket that has been itching me for a
long time that I tried to fix but couldn't figure out how. I'll CC you
on it to see if you have any ideas, but no pressure :)

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Fix parentheses with Hebrew

[Jürgen Spitzmüller]

Am Donnerstag, den 01.11.2018, 16:26 +0100 schrieb Kornel Benko:
> This would not be better.

I was not saying it is good. I was just saying it's not a loop.

Jürgen


signature.asc
Description: This is a digitally signed message part

Re: [LyX/master] Fix parentheses with Hebrew

[Kornel Benko]

Am Donnerstag, 1. November 2018 17:16:08 CET schrieb Guy Rutenberg 
:
> Hi,
> 
> It seems not to be an endless loop, but to simply take a *very* long time.
> I'll look at what keeping it busy, and submit a patch.
> 
> Thanks,
> Guy

Right, after 18 minutes the file was loaded.

 Kornel



signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Fix parentheses with Hebrew

[Kornel Benko]

Am Donnerstag, 1. November 2018 16:13:16 CET schrieb Jürgen Spitzmüller 
:
> Am Donnerstag, den 01.11.2018, 15:47 +0100 schrieb Kornel Benko:
> > Not able to read doc/de/Additional.lyx after this commit.
> > Endless loop in lyx2lyx.
> 
> I don't think it's an endless loop. It's just incredibly slow.

16:16:30
...
16:26:35
This would not be better. I am waiting now for 10 minutes, cpu is at 100%,
nothing happens.

Kornel




signature.asc
Description: This is a digitally signed message part.

Re: [LyX/master] Fix parentheses with Hebrew

[Guy Rutenberg]

Hi,

It seems not to be an endless loop, but to simply take a *very* long time.
I'll look at what keeping it busy, and submit a patch.

Thanks,
Guy

On Thu, 1 Nov 2018 at 16:48, Kornel Benko  wrote:

> Am Dienstag, 30. Oktober 2018 12:34:47 CET schrieb Juergen Spitzmueller <
> sp...@lyx.org>:
> > commit 0ec295d63ef1ae59ab016214d4934585d351ccc4
> > Author: Juergen Spitzmueller 
> > Date:   Tue Oct 30 12:33:35 2018 +0100
> >
> > Fix parentheses with Hebrew
> >
> > Patch by Guy Rutenberg, with some changes of mine.
> >
> > Fixes: #11191
> > ---
> >  development/FORMAT   |6 
> >  lib/lyx2lyx/lyx2lyx_tools.py |   17 +++-
> >  lib/lyx2lyx/lyx_2_4.py   |   20 +-
> >  src/Paragraph.cpp|   61
> --
> >  src/TextMetrics.cpp  |   11 +---
> >  src/version.h|4 +-
> >  6 files changed, 73 insertions(+), 46 deletions(-)
>
> Not able to read doc/de/Additional.lyx after this commit.
> Endless loop in lyx2lyx.
>
> Kornel

Re: [LyX/master] Fix parentheses with Hebrew

[Jürgen Spitzmüller]

Am Donnerstag, den 01.11.2018, 15:47 +0100 schrieb Kornel Benko:
> Not able to read doc/de/Additional.lyx after this commit.
> Endless loop in lyx2lyx.

I don't think it's an endless loop. It's just incredibly slow.

Jürgen

> 
>   Kornel


signature.asc
Description: This is a digitally signed message part

Re: No PDF viewer installed

[Paul A. Rubin]

On 11/1/18 7:56 AM, Daniel wrote:
I am still getting the "No PDF viewer installed" error message when 
"pdfview" is selected as Viewer. I am a bit lost whether this should 
be fixed by now or not in 2.3.1. I saw that the "pdfview" option is 
missing in current master. Maybe that will be the "fix"?


Daniel

I'm using LyX 2.3.1 on Linux Mint. The installed copy of configure.py 
has pdfview at the head of the list of PDF viewer alternatives.


Paul

Re: [LyX/master] Fix parentheses with Hebrew

[Kornel Benko]

Am Dienstag, 30. Oktober 2018 12:34:47 CET schrieb Juergen Spitzmueller 
:
> commit 0ec295d63ef1ae59ab016214d4934585d351ccc4
> Author: Juergen Spitzmueller 
> Date:   Tue Oct 30 12:33:35 2018 +0100
> 
> Fix parentheses with Hebrew
> 
> Patch by Guy Rutenberg, with some changes of mine.
> 
> Fixes: #11191
> ---
>  development/FORMAT   |6 
>  lib/lyx2lyx/lyx2lyx_tools.py |   17 +++-
>  lib/lyx2lyx/lyx_2_4.py   |   20 +-
>  src/Paragraph.cpp|   61 
> --
>  src/TextMetrics.cpp  |   11 +---
>  src/version.h|4 +-
>  6 files changed, 73 insertions(+), 46 deletions(-)

Not able to read doc/de/Additional.lyx after this commit.
Endless loop in lyx2lyx.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: No PDF viewer installed

[Daniel]

On 01/11/2018 13:13, Kornel Benko wrote:

Am Donnerstag, 1. November 2018 12:56:08 CET schrieb Daniel :

I am still getting the "No PDF viewer installed" error message when
"pdfview" is selected as Viewer. I am a bit lost whether this should be
fixed by now or not in 2.3.1. I saw that the "pdfview" option is missing
in current master. Maybe that will be the "fix"?

Daniel




As far as I can see, configure.py checks for pdfview. See configure.py:716

The only reason I can imagine is, that it is not found in searched PATH.

Kornel



It seems that pdfview itself is the problem. When I execute it, I get 
the exact same error dialog.


Probably worth mentioning: I have a number of PDF viewers installed 
including Adobe Reader and SumartaPDF.


Daniel

Re: No PDF viewer installed

[Kornel Benko]

Am Donnerstag, 1. November 2018 12:56:08 CET schrieb Daniel :
> I am still getting the "No PDF viewer installed" error message when 
> "pdfview" is selected as Viewer. I am a bit lost whether this should be 
> fixed by now or not in 2.3.1. I saw that the "pdfview" option is missing 
> in current master. Maybe that will be the "fix"?
> 
> Daniel
> 
> 

As far as I can see, configure.py checks for pdfview. See configure.py:716

The only reason I can imagine is, that it is not found in searched PATH.

Kornel


signature.asc
Description: This is a digitally signed message part.

No PDF viewer installed

[Daniel]

I am still getting the "No PDF viewer installed" error message when 
"pdfview" is selected as Viewer. I am a bit lost whether this should be 
fixed by now or not in 2.3.1. I saw that the "pdfview" option is missing 
in current master. Maybe that will be the "fix"?


Daniel

Re: Patch test with several minor dialog alignment fixes

[Daniel]

On 01/11/2018 12:45, Kornel Benko wrote:

Am Donnerstag, 1. November 2018 12:32:13 CET schrieb Daniel :

On 01/11/2018 10:42, Kornel Benko wrote:

Am Donnerstag, 1. November 2018 06:52:11 CET schrieb Daniel :


Thanks for checking. That the left hand labels don't stretch was driven by
the idea that it would be easier to match the label and the text boxes. As
for the buttons: I have never seen a (professional) dialog UI where the
buttons stretch. So, I suggest to stick to what has been used elsewhere.
(Probably for good reason but I am not sure about what that might be.) Also,
my hunch was that this stretching behaviour was unintentional because it
does not appear so long as the dialog is kept to a narrow width.


Makes sense. Thanks,

Scott



Great. And by the way, while I tend to think all the changes I make
sense, I can change things on feedback. Also, if you come across some
oddity in a dialog that I haven't caught yet, please let me know. I
think I got the hang of Qt Creator.


Are you considering also different languages? LTR vs. RTL for instance,
or different sizes of text fields?

(All your examples are English only, therefore the question)


Good point. I just tried RTL and it seems to me that Qt takes care of
this pretty well. Nice feature. Though I must confess that my UI
intuitions are a bit weak there. Basically, everything should be
mirrored, right?


Don't know. Just made a point.


I am not sure what you mean by different sizes of text fields. However,
as far as I can see my changes give text field more rather than less
(horizontal) space, if that is the concern.

Daniel



I meant the width of translatable entries.

Kornel



I see. It was probably a bit ambiguous when I wrote "fixed width" in the 
description of changes. I did not set any width to a fixed number but 
only to their minimal size given their content.


Daniel

Re: Patch test with several minor dialog alignment fixes

[Kornel Benko]

Am Donnerstag, 1. November 2018 12:32:13 CET schrieb Daniel :
> On 01/11/2018 10:42, Kornel Benko wrote:
> > Am Donnerstag, 1. November 2018 06:52:11 CET schrieb Daniel 
> > :
> > 
>  Thanks for checking. That the left hand labels don't stretch was driven 
>  by
>  the idea that it would be easier to match the label and the text boxes. 
>  As
>  for the buttons: I have never seen a (professional) dialog UI where the
>  buttons stretch. So, I suggest to stick to what has been used elsewhere.
>  (Probably for good reason but I am not sure about what that might be.) 
>  Also,
>  my hunch was that this stretching behaviour was unintentional because it
>  does not appear so long as the dialog is kept to a narrow width.
> >>>
> >>> Makes sense. Thanks,
> >>>
> >>> Scott
> >>>
> >>
> >> Great. And by the way, while I tend to think all the changes I make
> >> sense, I can change things on feedback. Also, if you come across some
> >> oddity in a dialog that I haven't caught yet, please let me know. I
> >> think I got the hang of Qt Creator.
> > 
> > Are you considering also different languages? LTR vs. RTL for instance,
> > or different sizes of text fields?
> > 
> > (All your examples are English only, therefore the question)
> 
> Good point. I just tried RTL and it seems to me that Qt takes care of 
> this pretty well. Nice feature. Though I must confess that my UI 
> intuitions are a bit weak there. Basically, everything should be 
> mirrored, right?

Don't know. Just made a point.

> I am not sure what you mean by different sizes of text fields. However, 
> as far as I can see my changes give text field more rather than less 
> (horizontal) space, if that is the concern.
> 
> Daniel
> 

I meant the width of translatable entries.

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: Patch test with several minor dialog alignment fixes

[Daniel]

On 01/11/2018 10:42, Kornel Benko wrote:

Am Donnerstag, 1. November 2018 06:52:11 CET schrieb Daniel :


Thanks for checking. That the left hand labels don't stretch was driven by
the idea that it would be easier to match the label and the text boxes. As
for the buttons: I have never seen a (professional) dialog UI where the
buttons stretch. So, I suggest to stick to what has been used elsewhere.
(Probably for good reason but I am not sure about what that might be.) Also,
my hunch was that this stretching behaviour was unintentional because it
does not appear so long as the dialog is kept to a narrow width.


Makes sense. Thanks,

Scott



Great. And by the way, while I tend to think all the changes I make
sense, I can change things on feedback. Also, if you come across some
oddity in a dialog that I haven't caught yet, please let me know. I
think I got the hang of Qt Creator.


Are you considering also different languages? LTR vs. RTL for instance,
or different sizes of text fields?

(All your examples are English only, therefore the question)


Good point. I just tried RTL and it seems to me that Qt takes care of 
this pretty well. Nice feature. Though I must confess that my UI 
intuitions are a bit weak there. Basically, everything should be 
mirrored, right?


I am not sure what you mean by different sizes of text fields. However, 
as far as I can see my changes give text field more rather than less 
(horizontal) space, if that is the concern.


Daniel

Re: Patch test with several minor dialog alignment fixes

[Kornel Benko]

Am Donnerstag, 1. November 2018 06:52:11 CET schrieb Daniel :
...
> >> Thanks for checking. That the left hand labels don't stretch was driven by
> >> the idea that it would be easier to match the label and the text boxes. As
> >> for the buttons: I have never seen a (professional) dialog UI where the
> >> buttons stretch. So, I suggest to stick to what has been used elsewhere.
> >> (Probably for good reason but I am not sure about what that might be.) 
> >> Also,
> >> my hunch was that this stretching behaviour was unintentional because it
> >> does not appear so long as the dialog is kept to a narrow width.
> >
> > Makes sense. Thanks,
> >
> > Scott
> >
> 
> Great. And by the way, while I tend to think all the changes I make 
> sense, I can change things on feedback. Also, if you come across some 
> oddity in a dialog that I haven't caught yet, please let me know. I 
> think I got the hang of Qt Creator.

Are you considering also different languages? LTR vs. RTL for instance,
or different sizes of text fields?

(All your examples are English only, therefore the question)

> Daniel

Kornel



signature.asc
Description: This is a digitally signed message part.