Re: Language change within Flex inset exports wrong babel construct
Jürgen Spitzmüller spitz at lyx.org writes: Jean-Pierre Chrétien wrote: So to come back to the previous thread, if Enrico's patch is not applied, which one of the }\n strings in output_latex.cpp should be modified ? See attachment. The new bool is introduced because pending_newline is used multiple times. Works fine, both on my test file and on the French version of the Customization manual. Thanks a lot, I won't have to search and correct all the ocurrences of English words in Flex:code I left there. Once this patch is committed, I will close ticket #7607. -- Jean-Pierre
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-10, Jürgen Spitzmüller wrote:
[-- Type: text/plain, Encoding: quoted-printable --]
Jean-Pierre Chrétien wrote:
So to come back to the previous thread, if Enrico's patch is not applied,
which one of the }\n strings in output_latex.cpp should be modified ?
See attachment.
The new bool is introduced because pending_newline is used multiple times.
Could we call the new bool mask_newline or escape_newline, please?
This seems better to reflect its function (prevent unwanted whitespace):
...
+++ src/output_latex.cpp (Arbeitskopie)
...
bool pending_newline = false;
+ bool unskip_newline = false;
...
- if (pending_newline)
+ if (pending_newline) {
+ if (unskip_newline)
+ // prevent unwanted whitespace
+ os '%';
os '\n';
+ }
Thanks,
Günter
Re: Profiling results of scrolling through the Users Guide
Am 10.06.2011 um 03:00 schrieb Richard Heck: On 06/09/2011 04:03 PM, Stephan Witt wrote: Am 09.06.2011 um 20:21 schrieb Peter Kümmel: On 09.06.2011 08:12, Stephan Witt wrote: To investigate the recently mentioned scrolling problems I did some profiling on my machine. See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) but it's interesting too. To scroll with Page-Down through the Users Guide completely I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are images, tables and math. I did this twice. The first time with drawing of text fragments and the 2nd time with single character drawing. While doing this I collected the time profile with Shark, the profiler tool of Xcode. The most interesting observation I've made is: most of the time LyX is busy with other things - not with screen drawing. The scroll operation cost is 5% for the first and 15% for the second variant of drawing. The other things are thread and socket management and QProcess's doing. Stephan OK, it is Enrico's job to ask for, but could rerun the test with USE_QPROCESS undefined? Peter There is no difference in response time. Scroll speed is the same. The numbers are changing a little bit, perhaps it's a little bit faster. But it's far from a valuable performance gain. I suspect, but hardly know, that in this case QProcess is simply being used to launch things like graphics conversions, and it would be shocking if using it instead of whatever we use instead was the issue here. I'm lost with this too. I suspect, QProcess is doing some work every time, e. g. querying for lost children. The conversion of graphics shouldn't happen, all of them are cached already. Or am I missing something? In fact, I'm using the Users Guide for my tests regularly. I suspect that the issue relates more to what we have to do every time the screen moves, and I believe we do that---e.g., recalculate metrics prior to redrawing the screen, which may involve a buffer update, etc, etc---each time new material appears on the screen, which could be every 0.1 seconds or so if you are scrolling quickly, or holding down PageDn. A shot in the dark: Could one interrupt these processes when a new scroll event happens? Why finish calculating the metrics when we know they are about to be irrelevant? But metrics computation looks innocent in the profiles. Am 10.06.2011 um 01:42 schrieb Pavel Sanda: Stephan Witt wrote: To investigate the recently mentioned scrolling problems I did some profiling on my machine. See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html i'm afraid we need exactly the setup where X is the main consumer. Agreed. I think the combination of this Xserver and current LyX behaves sub-optimal. On my Mac and my Linux running in VMware I don't have this Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) but it's interesting too. To scroll with Page-Down through the Users Guide completely I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are images, tables and math. I did this twice. The first time with drawing of text fragments and the 2nd time with single character drawing. While doing this I collected the time profile with Shark, the profiler tool of Xcode. The most interesting observation I've made is: most of the time LyX is busy with other things - not with screen drawing. The scroll operation cost is 5% for the first and 15% for the second variant of drawing. The other things are thread and socket management and QProcess's doing. dont know shark but i guess this is misinterpretation. socket and thread managment look as main consumers just because the percentage is cumulative, no? (ie all the computation which happens under lyx::start will be automatically added to its callers - socketthread) Yes, maybe. There is an option in Shark to add system calls costs and code without debug info to there callers. When using it I cannot see QProcess and socket ops anymore. I guess it's cumulated in the 23.8% for lyx::frontend::GuiApplication::exec() then. Stephan The statistics excerpt: Self+Children 0.0%100.0% main 0.0%99.9%lyx::LyX::exec(int, char**) 23.8% 94.8% lyx::frontend::GuiApplication::exec() 0.7%62.2% lyx::frontend::GuiApplication::notify(QObject*, QEvent*) 0.0%51.8% lyx::frontend::GuiProgressView::qt_metacall(QMetaObject::Call, int, void**) 0.9%51.8%lyx::frontend::GuiProgressView::appendLyXErrText(QString const) 1.9%50.9% lyx::frontend::GuiApplication::notify(QObject*, QEvent*) 0.0%28.4% lyx::frontend::GuiWorkArea::event(QEvent*) 0.0%28.4% lyx::frontend::GuiWorkArea::keyPressEvent(QKeyEvent*) 0.0%28.4%
epstopdf fails with 2.0.1svn
Hello, While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind of errors for every .eps file to be converted to pdf: cite Systemcall.cpp(238): Systemcall: 'epstopdf --outfile=32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.pdf 32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.eps' did not start! Systemcall.cpp(239): error The process failed to start.\ Either the invoked program is missing, or you may have\ insufficient permissions to invoke the program. Error: Cannot convert file /cite This did not heppen with 2.0.0. Setting the absolute path in the Preferences does not work either. Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010 -- Jean-Pierre
Re: Profiling results of scrolling through the Users Guide
Stephan Witt wrote: dont know shark but i guess this is misinterpretation. socket and thread managment look as main consumers just because the percentage is cumulative, no? (ie all the computation which happens under lyx::start will be automatically added to its callers - socketthread) Yes, maybe. There is an option in Shark to add system calls costs and code without debug info to there callers. i think something can be guessed when looking on two stats - one for self one for cumulative percentage. i'm just running sysprof to see whats behind the curtains. pavel
Re: Profiling results of scrolling through the Users Guide
Pavel Sanda wrote: in short total: /usr/bin/X60% kernel31 lyx 30 tracking down these 30 (but now in trunk): 16 goes for bv::showcursor and 8.7 to buf::updatemacros 3.4 to buf::changed. most part (13) from 16 of showcursor boils down to drawparagraph. but i guess the real bottleneck is not in lyx itself. btw after the few minutes with sysprof i find its UI very relieving and productive compared to the work with gprof and its output. pavel
Re: epstopdf fails with 2.0.1svn
On 06/10/2011 04:14 AM, Jean-Pierre Chrétien wrote: Hello, While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind of errors for every .eps file to be converted to pdf: cite Systemcall.cpp(238): Systemcall: 'epstopdf --outfile=32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.pdf 32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.eps' did not start! Systemcall.cpp(239): error The process failed to start.\ Either the invoked program is missing, or you may have\ insufficient permissions to invoke the program. Error: Cannot convert file /cite This did not heppen with 2.0.0. Setting the absolute path in the Preferences does not work either. Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010 I have also seen these errors, and I have no idea what changed. This has to be fixed, obviously, before 2.0.1. Richard
Re: epstopdf fails with 2.0.1svn
Richard Heck wrote: I have also seen these errors, and I have no idea what changed. This is th culprit apparently: http://www.lyx.org/trac/changeset/38746/lyx- devel/branches/BRANCH_2_0_X/src/Converter.cpp Jürgen
Re: epstopdf fails with 2.0.1svn
Am piatok 10 Jún 2011 schrieb Richard Heck: On 06/10/2011 04:14 AM, Jean-Pierre Chrétien wrote: Hello, While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind of errors for every .eps file to be converted to pdf: cite Systemcall.cpp(238): Systemcall: 'epstopdf --outfile=32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.pdf 32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.eps' did not start! Systemcall.cpp(239): error The process failed to start.\ Either the invoked program is missing, or you may have\ insufficient permissions to invoke the program. Error: Cannot convert file /cite This did not heppen with 2.0.0. Setting the absolute path in the Preferences does not work either. Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010 I have also seen these errors, and I have no idea what changed. This has to be fixed, obviously, before 2.0.1. Richard I also had this. Cured after changing the converter EPS-PDF(ps2pdf) from epstopdf --outfile=$$o $$i to ps2pdf $$o $$i. But I don't understand too. epstopdf is working here, checked also with mobius.eps. Kornel signature.asc Description: This is a digitally signed message part.
Re: epstopdf fails with 2.0.1svn
Kornel kornel at lyx.org writes: I also had this. Cured after changing the converter EPS-PDF(ps2pdf) from epstopdf --outfile=$$o $$i to ps2pdf $$o $$i. I replaced in my lyxrc.example epstopdf--outfile=$$o $$i by the absolute path /ext/local/texlive/2010/bin/i386-linux/epstopdf --outfile=$$o $$i with no success. However with: perl /ext/local/texlive/2010/bin/i386-linux/epstopdf --outfile=$$o $$i the errors disppears. Looks like an acess to perl problem then. But now, coming back to any of the two other converters, the errors do not appear anymore -- Jean-Pierre
Re: Language change within Flex inset exports wrong babel construct
Jürgen Spitzmüller lyx.org> writes: > > Jean-Pierre Chrétien wrote: > > So to come back to the previous thread, if Enrico's patch is not applied, > > which one of the "}\n" strings in output_latex.cpp should be modified ? > > See attachment. > > The new bool is introduced because pending_newline is used multiple times. Works fine, both on my test file and on the French version of the Customization manual. Thanks a lot, I won't have to search and correct all the ocurrences of English words in Flex:code I left there. Once this patch is committed, I will close ticket #7607. -- Jean-Pierre
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-10, Jürgen Spitzmüller wrote:
> [-- Type: text/plain, Encoding: quoted-printable --]
> Jean-Pierre Chrétien wrote:
>> So to come back to the previous thread, if Enrico's patch is not applied,
>> which one of the "}\n" strings in output_latex.cpp should be modified ?
> See attachment.
> The new bool is introduced because pending_newline is used multiple times.
Could we call the new bool "mask_newline" or "escape_newline", please?
This seems better to reflect its function (prevent unwanted whitespace):
...
> +++ src/output_latex.cpp (Arbeitskopie)
...
> bool pending_newline = false;
> + bool unskip_newline = false;
...
> - if (pending_newline)
> + if (pending_newline) {
> + if (unskip_newline)
> + // prevent unwanted whitespace
> + os << '%';
> os << '\n';
> + }
Thanks,
Günter
Re: Profiling results of scrolling through the Users Guide
Am 10.06.2011 um 03:00 schrieb Richard Heck: > On 06/09/2011 04:03 PM, Stephan Witt wrote: >> Am 09.06.2011 um 20:21 schrieb Peter Kümmel: >> >>> On 09.06.2011 08:12, Stephan Witt wrote: To investigate the recently mentioned scrolling problems I did some profiling on my machine. See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) but it's interesting too. To scroll with Page-Down through the Users Guide completely I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there are images, tables and math. I did this twice. The first time with drawing of text fragments and the 2nd time with single character drawing. While doing this I collected the time profile with Shark, the profiler tool of Xcode. The most interesting observation I've made is: most of the time LyX is busy with other things - not with screen drawing. The scroll operation cost is 5% for the first and 15% for the second variant of drawing. The other things are thread and socket management and QProcess's doing. Stephan >>> OK, it is Enrico's job to ask for, but could rerun the test with >>> USE_QPROCESS undefined? >>> >>> Peter >> There is no difference in response time. Scroll speed is the same. >> The numbers are changing a little bit, perhaps it's a little bit faster. >> But it's far from a valuable performance gain. >> > I suspect, but hardly know, that in this case QProcess is simply being used > to launch things like graphics conversions, and it would be shocking if using > it instead of whatever we use instead was the issue here. I'm lost with this too. I suspect, QProcess is doing some work every time, e. g. querying for lost children. The conversion of graphics shouldn't happen, all of them are cached already. Or am I missing something? In fact, I'm using the Users Guide for my tests regularly. > I suspect that the issue relates more to what we have to do every time the > screen moves, and I believe we do that---e.g., recalculate metrics prior to > redrawing the screen, which may involve a buffer update, etc, etc---each time > new material appears on the screen, which could be every 0.1 seconds or so if > you are scrolling quickly, or holding down PageDn. A shot in the dark: Could > one interrupt these processes when a new scroll event happens? Why finish > calculating the metrics when we know they are about to be irrelevant? But metrics computation looks innocent in the profiles. Am 10.06.2011 um 01:42 schrieb Pavel Sanda: > Stephan Witt wrote: >> To investigate the recently mentioned scrolling problems I did some >> profiling on my machine. >> See http://www.mail-archive.com/lyx-users@lists.lyx.org/msg87278.html > > i'm afraid we need exactly the setup where X is the main consumer. Agreed. I think the combination of this Xserver and current LyX behaves sub-optimal. On my Mac and my Linux running in VMware I don't have this > >> Ok, it's a completely different environment (Mac, Qt-4.6-Cocoa, SVN-trunk) >> but it's interesting too. To scroll with Page-Down through the Users Guide >> completely >> I have to wait appr. 20 or 30 seconds. Of course it's not pure text, there >> are images, >> tables and math. I did this twice. The first time with drawing of text >> fragments and >> the 2nd time with single character drawing. >> >> While doing this I collected the time profile with Shark, the profiler tool >> of Xcode. >> >> The most interesting observation I've made is: most of the time LyX is busy >> with other >> things - not with screen drawing. The scroll operation cost is 5% for the >> first and 15% >> for the second variant of drawing. >> The other things are thread and socket management and QProcess's doing. > > dont know shark but i guess this is misinterpretation. socket and thread > managment > look as main consumers just because the percentage is cumulative, no? (ie all > the computation > which happens under lyx::start will be automatically added to its callers - > socket) Yes, maybe. There is an option in Shark to add system calls costs and code without debug info to there callers. When using it I cannot see QProcess and socket ops anymore. I guess it's cumulated in the 23.8% for lyx::frontend::GuiApplication::exec() then. Stephan The statistics excerpt: Self+Children 0.0%100.0% main 0.0%99.9%lyx::LyX::exec(int&, char**) 23.8% 94.8% lyx::frontend::GuiApplication::exec() 0.7%62.2% lyx::frontend::GuiApplication::notify(QObject*, QEvent*) 0.0%51.8% lyx::frontend::GuiProgressView::qt_metacall(QMetaObject::Call, int, void**) 0.9%51.8%lyx::frontend::GuiProgressView::appendLyXErrText(QString const&) 1.9%50.9% lyx::frontend::GuiApplication::notify(QObject*, QEvent*) 0.0%
epstopdf fails with 2.0.1svn
Hello, While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind of errors for every .eps file to be converted to pdf: Systemcall.cpp(238): Systemcall: 'epstopdf --outfile="32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.pdf" "32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.eps"' did not start! Systemcall.cpp(239): error The process failed to start.\ Either the invoked program is missing, or you may have\ insufficient permissions to invoke the program. Error: Cannot convert file This did not heppen with 2.0.0. Setting the absolute path in the Preferences does not work either. Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010 -- Jean-Pierre
Re: Profiling results of scrolling through the Users Guide
Stephan Witt wrote: > > dont know shark but i guess this is misinterpretation. socket and thread > > managment > > look as main consumers just because the percentage is cumulative, no? (ie > > all the computation > > which happens under lyx::start will be automatically added to its callers - > > socket) > > Yes, maybe. There is an option in Shark to add system calls costs and code > without debug info to there callers. i think something can be guessed when looking on two stats - one for self one for cumulative percentage. i'm just running sysprof to see whats behind the curtains. pavel
Re: Profiling results of scrolling through the Users Guide
Pavel Sanda wrote: > in short > total: > /usr/bin/X60% > kernel31 > lyx 30 tracking down these 30 (but now in trunk): 16 goes for bv::showcursor and 8.7 to buf::updatemacros 3.4 to buf::changed. most part (13) from 16 of showcursor boils down to drawparagraph. but i guess the real bottleneck is not in lyx itself. btw after the few minutes with sysprof i find its UI very relieving and productive compared to the work with gprof and its output. pavel
Re: epstopdf fails with 2.0.1svn
On 06/10/2011 04:14 AM, Jean-Pierre Chrétien wrote: > Hello, > > While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind of > errors for every .eps file to be converted to pdf: > > > Systemcall.cpp(238): Systemcall: 'epstopdf --outfile="32_usr_local_share_lyx-\ > 2_0_1svn_doc_clipart_mobius.pdf" "32_usr_local_share_lyx-\ > 2_0_1svn_doc_clipart_mobius.eps"' did not start! > Systemcall.cpp(239): error The process failed to start.\ > Either the invoked program is missing, or you may have\ > insufficient permissions to invoke the program. > Error: Cannot convert file > > > This did not heppen with 2.0.0. > Setting the absolute path in the Preferences does not work either. > > Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010 > I have also seen these errors, and I have no idea what changed. This has to be fixed, obviously, before 2.0.1. Richard
Re: epstopdf fails with 2.0.1svn
Richard Heck wrote: > I have also seen these errors, and I have no idea what changed. This is th culprit apparently: http://www.lyx.org/trac/changeset/38746/lyx- devel/branches/BRANCH_2_0_X/src/Converter.cpp Jürgen
Re: epstopdf fails with 2.0.1svn
Am piatok 10 Jún 2011 schrieb Richard Heck: > On 06/10/2011 04:14 AM, Jean-Pierre Chrétien wrote: > > Hello, > > > > While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind > > of errors for every .eps file to be converted to pdf: > > > > > > Systemcall.cpp(238): Systemcall: 'epstopdf > > --outfile="32_usr_local_share_lyx-\ 2_0_1svn_doc_clipart_mobius.pdf" > > "32_usr_local_share_lyx-\ > > 2_0_1svn_doc_clipart_mobius.eps"' did not start! > > Systemcall.cpp(239): error The process failed to start.\ > > Either the invoked program is missing, or you may have\ > > insufficient permissions to invoke the program. > > Error: Cannot convert file > > > > > > This did not heppen with 2.0.0. > > Setting the absolute path in the Preferences does not work either. > > > > Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010 > > I have also seen these errors, and I have no idea what changed. > > This has to be fixed, obviously, before 2.0.1. > > Richard I also had this. Cured after changing the converter EPS->PDF(ps2pdf) from "epstopdf --outfile=$$o $$i" to "ps2pdf $$o $$i". But I don't understand too. epstopdf is working here, checked also with mobius.eps. Kornel signature.asc Description: This is a digitally signed message part.
Re: epstopdf fails with 2.0.1svn
Kornel lyx.org> writes: > > I also had this. Cured after changing the converter > EPS->PDF(ps2pdf) > from "epstopdf --outfile=$$o $$i" to "ps2pdf $$o $$i". > I replaced in my lyxrc.example epstopdf--outfile=$$o $$i by the absolute path /ext/local/texlive/2010/bin/i386-linux/epstopdf --outfile=$$o $$i with no success. However with: perl /ext/local/texlive/2010/bin/i386-linux/epstopdf --outfile=$$o $$i the errors disppears. Looks like an acess to perl problem then. But now, coming back to any of the two other converters, the errors do not appear anymore -- Jean-Pierre
