Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: I guess that's what the person who wrote debugstream thought. This is probably good enough. It is IMO a nice solution for outputting simple stuff without plastering the code with if(). The problem it has is that the right hand side is always computed, even if the output is discarded. But if one keeps that in mind it is a good debug utility. But that person forgot to have a look at nullstream. It is a piece of absolute crap. You can certainly backup that statement with measurements or other evidence? Otherwise it falls back on yourself. So it boils down to a very simple message for all coders here: ** Don't use lyxerr[] in a critical code path. *** Wrong. Right is: Don't use any lyxerr in a critical code path at all, and don't use lyxerr[] anywhere if the right hand side is expensive to compute. lyxerr[Debug::PAINTING] Painting at x = x , y = y '\n'; where x and y are simple numbers is pretty cheap. We have several commented lyxerr statements in the code in performance critical sections. They are commented and not used with [] exactly for performance reasons. I think the main problem is that many debug statements have been added lately by people who where not aware how lyxerr really works. Georg
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Abdelrazak Younes wrote: You misunderstood me. I don't deny you are right these are probably too expensive. I am just saying that I am not convinced that this is the major culprit for the slowness on Mac and on Windows for LyX file with a lot of big equation. But hey, every bit of speed we can gain is good :-) Try to make a test program that does nothing but allocate small pieces of memory, fill it up, and then free it again. Before you run it, guess how many allocations you can do in a second. Then run it and learn. Well, well, well... I am not sure if you are joking here or if you are arrogant but, anyway, I'll repeat that again in upper case in case you didn't hear me: THIS IS NOT THE MAJOR CULPRIT FOR THE OBSERVED SLOWNESS! That being said, thanks for the C++ lecture ;-) Abdel.
Re: [1.5 PATCH] Re: [Bug 2882] not possible to delete row in ERT inset
Michael == Michael Gerz [EMAIL PROTECTED] writes: Could someone test it too? Michael? Michael I did some basic testing (= OK!) and applied the patch. I Michael will have a look at the CT-specific parts by the end of the Michael week. Thanks. JMarc
Re: Let us remove the multi-window support !
José == José Matos [EMAIL PROTECTED] writes: Instead of hard-coding this like on Mac OS X right now, the Windows / Mac installers can set a default in lyxrc.dist and users will always be able to change it. The OSX case is different : this is specified at OS level and we are not supposed to do it differently. JMarc
Re: 3 important bugs right now - more testing needed!
Asger == Asger Ottar Alstrup [EMAIL PROTECTED] writes: Asger * Spell checking cannot be invoked a second time. This is Asger probably a one-liner. Asger * The first time the spell checker is started, an empty window Asger shown instead of the first misspelled word. Probably also a Asger one-liner. Ha! The spellchecker is such a mess that these bugs are horrible to fix. It needs at least a small facelift to be usable. JMarc
Re: 3 important bugs right now - more testing needed!
On Wednesday 08 November 2006 8:54 am, Jean-Marc Lasgouttes wrote: Ha! The spellchecker is such a mess that these bugs are horrible to fix. It needs at least a small facelift to be usable. I will shoot the first who disagrees with you about this. ;-) JMarc -- José Abílio
Re: missing qt-4 dependencies
Joost == Joost Verburg [EMAIL PROTECTED] writes: Joost Uwe Stöhr wrote: But this file is not available. The available lyx-windows-deps-msvc.zip doesn't include the qt-4 stuff, only qt-3. Abdel, could you please upload or send me a version that includes the files. Joost I uploaded this file yesterday, along with the 1.4.3-5 release. Joost Jean-Marc will soon move these files to ftp.lyx.org. The files are there now. JMarc
Re: Can LyX handle large files ?
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg It is IMO a nice solution for outputting simple stuff without Georg plastering the code with if(). The problem it has is that the Georg right hand side is always computed, even if the output is Georg discarded. But if one keeps that in mind it is a good debug Georg utility. Providing Asger can back up his claim with evidence, it may be time to try the preprocessor trick I proposed some time ago: #define LYXERR(flag) if (lyxerr.debugging(flag)) lyxerr or maybe (to avoid problems with nested ifs) #define LYXERR(flag) if (!lyxerr.debugging(flag)); else lyxerr Then LYXERR(Debug::PAINTING) foo bar will do the right thing. JMarc
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg It is IMO a nice solution for outputting simple stuff without Georg plastering the code with if(). The problem it has is that the Georg right hand side is always computed, even if the output is Georg discarded. But if one keeps that in mind it is a good debug Georg utility. Providing Asger can back up his claim with evidence, it may be time to try the preprocessor trick I proposed some time ago: #define LYXERR(flag) if (lyxerr.debugging(flag)) lyxerr or maybe (to avoid problems with nested ifs) #define LYXERR(flag) if (!lyxerr.debugging(flag)); else lyxerr Then LYXERR(Debug::PAINTING) foo bar will do the right thing. Even though I don't like much macro, I think that in this case, this is an excellent idea! This is an easy (but boring) task, anyone volunteers? Abdel.
Re: Can LyX handle large files ?
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak The cursor and dociterator pist is a good one I think. I Abdelrazak attach again the test file. At the end of file, appending Abdelrazak characters at the end of the last line is _slow_ but Abdelrazak hitting return and typing in a new line is very quick (as Abdelrazak quick as usual I mean). So the relationship between two Abdelrazak consecutive paragraph is the key to our problem I think. And this slowness is visible in csrss.exe? This is without gcc debug STL, right? JMarc
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak The cursor and dociterator pist is a good one I think. I Abdelrazak attach again the test file. At the end of file, appending Abdelrazak characters at the end of the last line is _slow_ but Abdelrazak hitting return and typing in a new line is very quick (as Abdelrazak quick as usual I mean). So the relationship between two Abdelrazak consecutive paragraph is the key to our problem I think. And this slowness is visible in csrss.exe? I am not sure of what you mean... By slowness I mean that characters are slowly inserted. While inserting the characters one by one, csrss.exe occupies 50% of the CPU and lyx the rest. This behaviour is only visible for the paragraph immediately following the big formula. Insertion of characters in the following paragraph is rapid again. This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel.
Some dudes on 1.5.0 messages
Hi all,
I'm updating Basque translation for LyX 1.5.0 branch. But there are some
messages that i'm not sure bout their sense:
Standard\t\\frac
Here the '\\frac' word means a Latex command, and should be not
translate, as '\\arabic{theorem}'... or can translate it?
Same question for:
No hor. line\t\\atop
is 'atop' a LaTeX command?
Same question for:
Nice\t\\nicefrac
is 'nicefrac' a LaTeX command? And Nice would mean something like
'priority' ( used in UNIX systems to give a priority to a process), o it
senses like to be kind or beauty?
What means exactly
Uncover
uncovered on slides
means to quit some cover from the slides? or to show something?
Thanks and best regards,
Dooteo
Re: Some dudes on 1.5.0 messages
dooteo wrote:
Hi all,
I'm updating Basque translation for LyX 1.5.0 branch. But there are some
messages that i'm not sure bout their sense:
Standard\t\\frac
Here the '\\frac' word means a Latex command, and should be not
translate, as '\\arabic{theorem}'... or can translate it?
No, it should not be translated.
Same question for:
No hor. line\t\\atop
is 'atop' a LaTeX command?
Yes.
Same question for:
Nice\t\\nicefrac
is 'nicefrac' a LaTeX command?
Yes.
And Nice would mean something like
'priority' ( used in UNIX systems to give a priority to a process), o it
senses like to be kind or beauty?
The latter.
BTW these strings come from the math dialog and are not correctly formatted
(tabs vs. spaces). We can not know at all the tab width used by qt, so the
alignment should be done with spaces.
What means exactly
Uncover
uncovered on slides
means to quit some cover from the slides? or to show something?
That comes probably from the beamer layout file. I suggest to have a look at
the beamer manual.
Georg
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
Georg Baum wrote: Helge Hafting wrote: One issue: Some of my paragraph styles have names with iso-8859-1 encoded names. I don't know if that really was supported before. Resymé for example. I don't think that it was supported, because it would mean that Resymé was parsed as something entirely different if you used it in documents with a different encoding than iso-8859-1. The display in the drop down box would probably also have looked different if you did run LyX with a locale with different encoding. That is reasonable. I only ever run lyx with a single encoding, so I used iso8859-1 in my layout file. You simply can't write Norwegian with ascii only. Therefore, I really hope the .layout files will support unicode in some way, and utf-8 is the easy way for me. That would allow Norwegian words, and of course this would help people making russian/greek/chinese .layout files too. Now such styles are replaced with standard when I load documents, because the style inside the document isn't found. The string in the document no longer match the string in the .layout file when they are non-ascii. Further, if I use the paragraph style dropdown, my non-ascii (and not unicode either) style is there with the nonascii character appearing as boxes. Actually selecting this style crashes lyx instantly. I have no problem renaming such styles - maybe it fixes the problem, maybe not. I have some ascii-named styles that also have problems, but perhaps the non-ascii one cause some kind of internal messup. I don't think so. Other styles should not be affected, but it would be nice if you could check that by renaming the latin1 styles. I removed all non-ascii from the .layout file - even stuff in comments and text supposed to go into the document. I can now select the Resyme style without crashing lyx, having a latin1 é in the word was a crasher. Perhaps not an important one, I have no problem cleaning up stuff that was supported only by accident before. The worse problem is that my sanitized .layout file still doesn't work - for the simple reason that no preamble stuff whatsoever goes into the produced .tex file. So my custom environments and tex commands go unrecognized because they aren't defined anywhere. I am trying to make a minimal .layout but this is tricky - a small layout file with a custom environment worked! I prefer utf8 in the .layout files, but that surely wasn't possible before. Currently layout files can only contain ASCII, but changing that to utf8 would not be much work. Then I hope for utf-8. .layout files. :-) Helge Hafting
Re: Some dudes on 1.5.0 messages
Thanks Georg :)
Jatorrizko mezua: az., 2006-11-08 11:13 +0100, egilea: Georg Baum
dooteo wrote:
Hi all,
I'm updating Basque translation for LyX 1.5.0 branch. But there are some
messages that i'm not sure bout their sense:
Standard\t\\frac
Here the '\\frac' word means a Latex command, and should be not
translate, as '\\arabic{theorem}'... or can translate it?
No, it should not be translated.
Same question for:
No hor. line\t\\atop
is 'atop' a LaTeX command?
Yes.
Same question for:
Nice\t\\nicefrac
is 'nicefrac' a LaTeX command?
Yes.
And Nice would mean something like
'priority' ( used in UNIX systems to give a priority to a process), o it
senses like to be kind or beauty?
The latter.
BTW these strings come from the math dialog and are not correctly formatted
(tabs vs. spaces). We can not know at all the tab width used by qt, so the
alignment should be done with spaces.
What means exactly
Uncover
uncovered on slides
means to quit some cover from the slides? or to show something?
That comes probably from the beamer layout file. I suggest to have a look at
the beamer manual.
Georg
[patch]docbook glossaries export
Attached is uglypatch/ugly for docbook glossaries export. Missing
features are:
- glossary entries in insets does not appear in glossary. I couldn't
find a chic way to include those.. (the current one is not so chic
anyway.. ) Any ideas??
- prefix is not working, therefore, you cannot change the sorting.
(any idea how to do it?)
- possible performance problems. (not tested)
Ugras
Index: src/paragraph.h
===
--- src/paragraph.h (revision 15801)
+++ src/paragraph.h (working copy)
@@ -158,6 +158,10 @@
LyXFont const outerfont,
pos_type initial = 0) const;
+ void simpleDocBookGlossary(Buffer const buf,
+ OutputParams const runparams,
+ odocstream ,
+ pos_type initial = 0) const;
///
bool hasSameLayout(Paragraph const par) const;
Index: src/paragraph.C
===
--- src/paragraph.C (revision 15801)
+++ src/paragraph.C (working copy)
@@ -1201,6 +1201,23 @@
}
+void Paragraph::simpleDocBookGlossary(Buffer const buf,
+OutputParams const runparams,
+odocstream os,
+pos_type initial) const
+{
+// pos_type initial = 0;
+
+ for (pos_type i = initial; i size(); ++i) {
+ if (isInset(i)) {
+ InsetBase const * inset = getInset(i);
+ if(inset-lyxCode() == InsetBase::NOMENCL_CODE )
+inset-docbook(buf, os, runparams);
+ }
+ }
+}
+
+
void Paragraph::simpleDocBookOnePar(Buffer const buf,
odocstream os,
OutputParams const runparams,
@@ -1233,6 +1250,7 @@
if (isInset(i)) {
InsetBase const * inset = getInset(i);
+ if(inset-lyxCode() != InsetBase::NOMENCL_CODE )
inset-docbook(buf, os, runparams);
} else {
value_type c = getChar(i);
@@ -1245,7 +1263,6 @@
}
font_old = font;
}
-
if (emph_flag) {
os /emphasis;
}
Index: src/insets/insetnomencl.C
===
--- src/insets/insetnomencl.C (revision 15801)
+++ src/insets/insetnomencl.C (working copy)
@@ -18,6 +18,10 @@
#include LaTeXFeatures.h
#include metricsinfo.h
#include sgml.h
+#include paragraph.h
+#include paragraph_funcs.h
+#include ParagraphList.h
+#include buffer.h
namespace lyx {
@@ -39,15 +43,15 @@
int InsetNomencl::docbook(Buffer const , odocstream os,
OutputParams const ) const
{
- // FIXME: This does not work, because the entry needs to be put
- // in the glossary.
-#if 0
- os glossentryglossterm
+ // FIXME: This does not work when nomencl entry put inside the insets,
+ os glossentry '\n'
+ glossterm
sgml::escapeString(getParam(symbol))
- /glosstermglossdefpara
- sgml::escapeString(getParam(description))
- /para/glossdef/glossentry;
-#endif
+ /glossterm '\n'
+ glossdefpara
+ sgml::escapeString(getParam(description)) '\n'
+ /para/glossdef '\n'
+ /glossentry '\n';
return 0;
}
@@ -75,11 +79,17 @@
}
-int InsetPrintNomencl::docbook(Buffer const , odocstream os,
- OutputParams const ) const
+int InsetPrintNomencl::docbook(Buffer const buf, odocstream os,
+ OutputParams const params) const
{
- // FIXME This does not work, we need to define the entries here.
- //os glossaryglossary/;
+ ParagraphList::const_iterator beg = buf.paragraphs().begin();
+ ParagraphList::const_iterator par = buf.paragraphs().begin();
+ ParagraphList::const_iterator end = buf.paragraphs().end();
+ os glossary '\n';
+ for (; par != end; ++par) {
+ par-simpleDocBookGlossary(buf,params,os);
+ }
+ os /glossary '\n';
return 0;
}
Index: lib/doc/Extended.lyx
===
--- lib/doc/Extended.lyx (revision 15801)
+++ lib/doc/Extended.lyx (working copy)
@@ -2677,7 +2677,7 @@
\noun on
Özgür U\i \~{g}
ra\i \c{s}
- Baram
+ Baran
\end_layout
\begin_layout Standard
@@ -2960,6 +2960,12 @@
\end_layout
+\begin_layout Standard
+ Docbook glossaries works in a similar way with a limitation. With the curent
+ version of lyx, glossary entries entered inside the insets (tables, notes,
+ etc.) are not processed.
+\end_layout
+
\begin_layout Section
Multipart Documents
\end_layout
AW: Re: 3 important bugs right now - more testing needed!
On Wednesday 08 November 2006 8:54 am, Jean-Marc Lasgouttes wrote: Ha! The spellchecker is such a mess that these bugs are horrible to fix. It needs at least a small facelift to be usable. I will shoot the first who disagrees with you about this. ;-) José Abílio And who is going to do this dirty job? Does the spell checker bug stop us from releasing alpha 1 next Monday? Michael
Re: AW: Re: 3 important bugs right now - more testing needed!
On Wednesday 08 November 2006 11:18 am, [EMAIL PROTECTED] wrote: And who is going to do this dirty job? Volunteers accepted. :-) Does the spell checker bug stop us from releasing alpha 1 next Monday? IMHO we should fix it for .0 version, for alpha if no solution is in sight I would prefer not to delay the first alpha because of this problem. What do you think? Michael -- José Abílio
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak The cursor and dociterator pist is a good one I think. I Abdelrazak attach again the test file. At the end of file, appending Abdelrazak characters at the end of the last line is _slow_ but Abdelrazak hitting return and typing in a new line is very quick (as Abdelrazak quick as usual I mean). So the relationship between two Abdelrazak consecutive paragraph is the key to our problem I think. And this slowness is visible in csrss.exe? I am not sure of what you mean... By slowness I mean that characters are slowly inserted. While inserting the characters one by one, csrss.exe occupies 50% of the CPU and lyx the rest. This behaviour is only visible for the paragraph immediately following the big formula. Insertion of characters in the following paragraph is rapid again. This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. Here some numbers, msvc/Release: when crss eats 100 seconds lyx only needs 32 seconds (cpu-time in the tsak manager). If these 100 sec are really wasted by lyxerr, the we waste 75% of the cpu time for nothing. -- Peter Kümmel
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak The cursor and dociterator pist is a good one I think. I Abdelrazak attach again the test file. At the end of file, appending Abdelrazak characters at the end of the last line is _slow_ but Abdelrazak hitting return and typing in a new line is very quick (as Abdelrazak quick as usual I mean). So the relationship between two Abdelrazak consecutive paragraph is the key to our problem I think. And this slowness is visible in csrss.exe? I am not sure of what you mean... By slowness I mean that characters are slowly inserted. While inserting the characters one by one, csrss.exe occupies 50% of the CPU and lyx the rest. This behaviour is only visible for the paragraph immediately following the big formula. Insertion of characters in the following paragraph is rapid again. This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. I've compared lyx 1.4 and 1.5svn (msvc/Release/Qt 4.1.2 -O2 optimized) with your file. I've done some more cp and scrolled it down and still 1.4 is faster: 60s versus 80s. :( Peter
Re: Can LyX handle large files ?
Peter Kümmel wrote: Abdelrazak Younes wrote: This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. I've compared lyx 1.4 and 1.5svn (msvc/Release/Qt 4.1.2 -O2 optimized) with your file. I've done some more cp and scrolled it down and still 1.4 is faster: 60s versus 80s. :( Ah but that's because you don't have my painting optimisation :-) Anyway, this csrss.exe problem is independent of the painting performance. To convince yourself, put you cursor at the last paragraph of the test file such that no formula is shown on screen at all, only the text of the last paragraph. Then begin to type in this last paragraph with 1.4 and 1.5svn. You will see that 1.4 is totally unresponsive for a long time while 1.5 will insert the characters, albeit slowly. Abdel.
Re: Can LyX handle large files ?
Peter Kümmel wrote: Abdelrazak Younes wrote: Here some numbers, msvc/Release: when crss eats 100 seconds lyx only needs 32 seconds (cpu-time in the tsak manager). If these 100 sec are really wasted by lyxerr, the we waste 75% of the cpu time for nothing. While it would be nice if someone steps up and implement JMarc' Macro based optimisation for lyxerr, I am pretty sure that lyxerr is not responsible for the slowness here. Here is my theory, following Georg and JMarc suggestions and my own investigation: I think that DocIterator is the culprit here. The fact that mathed uses a lot insets (especially in this test file!) is just a show case. Now, I still don't understand very well how csrss.exe enters the loop here. Another show case for DocIterator slowness: 1) Copy and paste the contents of UserGuide 4 or 5 times. 2) Break a section 3) Wait... This is because the section numbering code is another big user of the DocIterator class. Abdel.
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
On Wednesday 08 November 2006 10:39 am, Helge Hafting wrote: Currently layout files can only contain ASCII, but changing that to utf8 would not be much work. Then I hope for utf-8. .layout files. :-) I understand what you want and I agree with the goal, but not with the way to do it. Layout names should be ascii and we should be able to have translations of the layout names. Or else we are repeating the mistakes made by excell when the spreadsheet language was the same of the locale and it was not possible to exchange the documents between different languages, because the commands were naturally different. That is crazy... Helge Hafting -- José Abílio
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Anyway, this csrss.exe problem is independent of the painting performance. To convince yourself, put you cursor at the last paragraph of the test file such that no formula is shown on screen at all, only the text of the last paragraph. Then begin to type in this last paragraph with 1.4 and 1.5svn. You will see that 1.4 is totally unresponsive for a long time while 1.5 will insert the characters, albeit slowly. Another difference is that typing in a new paragraph after the last one will not exhibit the problem in 1.5 whereas it does in 1.4. So, if we don't solve this performance problem, a work-around it in 1.5 would be to insert an empty paragraph after a big inset. Maybe this can even be done at the code level... Abdel.
updated documentation for glossaries
attached is the updated documentation. Added howto change nomlabelwidth.
ugras
Index: src/insets/insetnomencl.h
===
--- src/insets/insetnomencl.h (revision 15801)
+++ src/insets/insetnomencl.h (working copy)
@@ -53,8 +53,7 @@
void validate(LaTeXFeatures features) const;
// FIXME: This should be editable to set the label width (stored
// in params_[labelwidth]).
- // Currently the width can be read from file and written, but not
- // changed.
+ // Currently the width can be altered in preamble (see documentation)
///
EDITABLE editable() const { return NOT_EDITABLE; }
///
Index: lib/doc/Extended.lyx
===
--- lib/doc/Extended.lyx (revision 15801)
+++ lib/doc/Extended.lyx (working copy)
@@ -2677,7 +2677,7 @@
\noun on
Özgür U\i \~{g}
ra\i \c{s}
- Baram
+ Baran
\end_layout
\begin_layout Standard
@@ -2956,10 +2956,25 @@
nomname}{List of Symbols}
\end_layout
+\begin_layout Standard
+ If you're unhappy with the amount of space for symbols, you can alter it by
+ adding following line to the preamble.
+\end_layout
+
\begin_layout LyX-Code
+\backslash
+renewcommand{
+\backslash
+nomlabelwidth}{3.0cm}
\end_layout
+\begin_layout Standard
+ Docbook glossaries works in a similar way with a limitation. With the curent
+ version of lyx, glossary entries entered inside the insets (tables, notes,
+ etc.) are not processed.
+\end_layout
+
\begin_layout Section
Multipart Documents
\end_layout
Re: r15805 - /lyx-devel/trunk/development/cmake/modules/FindQ...
[EMAIL PROTECTED] wrote: Author: kuemmel Date: Wed Nov 8 13:25:00 2006 New Revision: 15805 URL: http://www.lyx.org/trac/changeset/15805 Log: update to cmake's cvs version, fixes missing qtmain error on windows Hi Peter, Does that mean that I have to upgrade CMake? My version is 2.4-patch 2. Abdel.
Re: r15805 - /lyx-devel/trunk/development/cmake/modules/FindQ...
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: kuemmel Date: Wed Nov 8 13:25:00 2006 New Revision: 15805 URL: http://www.lyx.org/trac/changeset/15805 Log: update to cmake's cvs version, fixes missing qtmain error on windows Hi Peter, Does that mean that I have to upgrade CMake? My version is 2.4-patch 2. Abdel. No, this only updates the file which detects Qt4. If you don't have trouble with your current cmake version you don't need to update. -- Peter Kümmel
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. Nope... unfortunately the MSVC-optimized version presents the exact same behaviour :-( Abdel.
problems with lyx 1.5
i have tried to use 1.5 to revise cs docs and found these problems: * when opening already opened document(or document with newer backup), mouse pointer is switched into the clock, although it waits for confirmation dialog. * backuping works weirdly * environments when using czech translation doesnt work: e.g. itemize(Polozka) - ERROR (layoutSelected): layout not found! without this point working translation is unusable. * outputs, look and feel, language settings in tools/oreferences dialog cant be translated, and i dont see the corresponding strings in .po file although i rememeber translating them previously. the same with open recent in file menu and other menu items. it seems somebody unapropriately deleted items from .po files... * nobody answered my previous question about meaning of these items in .po #: src/frontends/qt4/ui/FloatPlacementUi.ui:16 msgid Form #: src/lengthcommon.C:39 msgid Line Width % (line in the sense of line of the table or row of text?) pavel
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Here some numbers, msvc/Release: when crss eats 100 seconds lyx only needs 32 seconds (cpu-time in the tsak manager). If these 100 sec are really wasted by lyxerr, the we waste 75% of the cpu time for nothing. While it would be nice if someone steps up and implement JMarc' Macro based optimisation for lyxerr, I am pretty sure that lyxerr is not responsible for the slowness here. Here is my theory, following Georg and JMarc suggestions and my own investigation: I think that DocIterator is the culprit here. The fact that mathed uses a lot insets (especially in this test file!) is just a show case. Now, I still don't understand very well how csrss.exe enters the loop here. I've found this searching the Platform SDK: Now we can see the reasons for the context switches. Solitaire is calling CSRSS constantly, and most of the time is spent in CSRSS running a single thread. The processor is not spending a great deal of time running the Solitaire program. It would appear that Windows NT that has the problem. By using the WAP profiling tool, no longer included with the Platform SDK, we discovered that Solitaire was making a lot of calls to the GetPixel and SetPixel functions. Maybe Qt calls csrss. Another show case for DocIterator slowness: 1) Copy and paste the contents of UserGuide 4 or 5 times. 2) Break a section 3) Wait... This is because the section numbering code is another big user of the DocIterator class. Abdel. -- Peter Kümmel
1.5.0 on Mac Update
Here's an update of issues for 1.5.0 on Mac, in rough order of importance. 1. Crashes -- both on open via the GUI and on quit. (See other threads for details.) I'd classify these as showstoppers. 2. Speed continues to get better, though it's still not as fast as 1.4.x, which itself is considerably slower than 1.3.x. On a fast machine, I don't notice a lag in typing in normal text or in insets. Opening the User's Guide and paging down takes about 46 seconds -- down from just over a minute before the painting optimizations. However, LyX-1.5.0 does use up over 60% of processor time when I type, compared to about 30% for LyX-1.4.x. (There is a noticeable lag when multiple windows are open.) 3. Cursor is still invisible. 4. Cannot drag-and-drop files on the LyX application icon (either in the Finder on in OS X's Dock) to open them. Instead, LyX becomes the frontmost application without opening the file. (Might this be related to the crash-on-open bug?) 5. Oddities drawing text mentioned before seem to be fixed. 6. Issues with toolbars remain: icons are spaced too widely and that changes in the visibility of the toolbars with the GUI do not stick after the screen is redrawn. 7. Problems with dialogs: Preferences dialog now opens the proper size the first time. However, it is still not possible to select buttons with the keyboard. 8. Dialogs generally seem to be drawn initially *behind* the main window, and only once they are drawn they take focus; perhaps related: dialogs appear much more slowly than they did in 1.4.x. This is true as well for the main window when switching to LyX by clicking on the main window: it first disappears behind visible windows of other applications, and then reappears taking focus. 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. 10. Menu bar still disappears (instead of being disabled) when dialogs appear. Bennett
Re: 1.5.0 on Mac Update
Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Joost
Re: 1.5.0 on Mac Update
On Wed, Nov 08, 2006 at 03:59:04PM +0100, Joost Verburg wrote: Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Then this must be another problem related to MSVC, as using GCC it works. Whatever viewer I define in lyxrc.dist is used, indeed. -- Enrico
Re: 1.5.0 on Mac Update
Am Mittwoch, 8. November 2006 16:17 schrieb Enrico Forestieri: On Wed, Nov 08, 2006 at 03:59:04PM +0100, Joost Verburg wrote: Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Then this must be another problem related to MSVC, as using GCC it works. Whatever viewer I define in lyxrc.dist is used, indeed. No, I had it too on linux. Uncommenting _all_ \format lines in preferences cured it. ( Not working: \format dvi dvi DVI D /opt/kde3/bin/kdvi working: \format dvi dvi DVI D /opt/kde3/bin/kdvi document,vector ) Kornel -- Kornel Benko [EMAIL PROTECTED] pgpD6kZIv5Xvy.pgp Description: PGP signature
Re: Can LyX handle large files ?
On Wed, 2006-11-08 at 10:54 +0100, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: ... This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? - Martin signature.asc Description: This is a digitally signed message part
Re: Can LyX handle large files ?
Martin Vermeer wrote: On Wed, 2006-11-08 at 10:54 +0100, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: ... This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? Well, there's a lot of things that can still be optimized in 1.4 but I am not sure it is worth spending sometimes there... I would prefer that you help me on optimizing 1.5 ;-) On windows, I think that the main reason why editing is quick again for the paragraph following the paragraph following the formula is the updateLabels() optimisation in 1.5. FYI I did this one to optimise new paragraph creation earlier this year. AFAIK, JMarc was interested in this optimisation but eventually it was forgotten. Hum... maybe I could extend it a bit if the previous paragraph is a math inset... Some other things might be worth optimizing in 1.4: 1) Full screen redraw on left mouse press 2) Full screen redraw on left mouse release (which means that a single mouse click redraw the screen two times.) 3) singlePar update within inset would be nice also but this seems difficult. Abdel.
Re: Can LyX handle large files ?
Martin Vermeer wrote: What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? With all the current optimizations, 1.4.3 is still more than twice as fast as 1.5 when scrolling the user guide on my system. The build settings are identical. Joost
Qt and window messages
Hi, I have a question about Qt on Windows: Is it possible to create a window procedure to capture standard window messages (not Qt events)? Regards, Joost
Re: 1.5.0 on Mac Update
On Nov 8, 2006, at 10:17 AM, Enrico Forestieri wrote: On Wed, Nov 08, 2006 at 03:59:04PM +0100, Joost Verburg wrote: Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Then this must be another problem related to MSVC, as using GCC it works. Whatever viewer I define in lyxrc.dist is used, indeed. To be clear, the issue is not with whether the converter/viewer gets used: entering Cmd-D will produce a .dvi file and open it in the viewer I've defined. The issue is merely with what items appear in the View menu. Bennett
Re: 1.5.0 on Mac Update
Bennett Helm wrote: On Nov 8, 2006, at 10:17 AM, Enrico Forestieri wrote: On Wed, Nov 08, 2006 at 03:59:04PM +0100, Joost Verburg wrote: Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Then this must be another problem related to MSVC, as using GCC it works. Whatever viewer I define in lyxrc.dist is used, indeed. To be clear, the issue is not with whether the converter/viewer gets used: entering Cmd-D will produce a .dvi file and open it in the viewer I've defined. The issue is merely with what items appear in the View menu. That (and Kornels example) rings a bell: You must put the document flag into the format line of the preferences file. Otherwise the format will not be shown in the view menu. This is changed from 1.4 (1.4 does not have a document flag). Note to packagers: You should add that flag to all formats in lyxrc.dist that should appear in the view menu. I believe that this is no bug, but the changed file format of the preferences file. We should probably write about that in the release notes. Georg
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
José Matos wrote: On Wednesday 08 November 2006 10:39 am, Helge Hafting wrote: Currently layout files can only contain ASCII, but changing that to utf8 would not be much work. Then I hope for utf-8. .layout files. :-) I understand what you want and I agree with the goal, but not with the way to do it. Layout names should be ascii and we should be able to have translations of the layout names. Or else we are repeating the mistakes made by excell when the spreadsheet language was the same of the locale and it was not possible to exchange the documents between different languages, because the commands were naturally different. That is crazy... Good point. Unfortunately I don't know ho to add user translations easily. Basically users would need to modify the lyx.mo file of their language and add the strings. Can that be done? Or would they need the .po file? Georg
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
Helge Hafting wrote: I removed all non-ascii from the .layout file - even stuff in comments and text supposed to go into the document. That should not be necessary. The stuff that goes into the document should be read as utf8, only the layout names need to be ascii. The worse problem is that my sanitized .layout file still doesn't work - for the simple reason that no preamble stuff whatsoever goes into the produced .tex file. So my custom environments and tex commands go unrecognized because they aren't defined anywhere. I am trying to make a minimal .layout but this is tricky - a small layout file with a custom environment worked! You could send me the file(s) privately if it contains something that you do not want to publish. In this case I don't think that a big layout file is problematic to debug. Georg
Re: Can LyX handle large files ?
Joost Verburg wrote: Martin Vermeer wrote: What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? With all the current optimizations, 1.4.3 is still more than twice as fast as 1.5 when scrolling the user guide on my system. The build settings are identical. Joost Isn't that bad here: official release 1.4.3: 20s cmake/Release 1.5svn : 28s -- Peter Kümmel
Re: Can LyX handle large files ?
Martin Vermeer wrote: On Wed, 2006-11-08 at 10:54 +0100, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: ... This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? - Martin Having a look at the scrolling times, normalized to Joost's 1.4 build Joost 1.4 : 1 Joost 1.5 : 2 cmake 1.5 : 1.4 indicates that some compiler flags and macro definitions could speed up the 1.4 without only further changes. -- Peter Kümmel
Re: cutandpaste.C simplifications
Michael Gerz [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | | Michael Gerz [EMAIL PROTECTED] writes: | | | Hi, | | | am I too stupid to see the brilliancy of the code | | yes. | (oh where did the friday go...) | | It is in the vein of prefere algorithms to manual constructs | | Anyway, I am going to commit my simplification. The manual construct | is a simple loop that is used only once. And you now have to add comments to tell what the loop is doing instead of having that implied by the name of the function for_each calls... -- Lgb
Re: Can LyX handle large files ?
Peter Kümmel wrote: Joost Verburg wrote: Martin Vermeer wrote: What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? With all the current optimizations, 1.4.3 is still more than twice as fast as 1.5 when scrolling the user guide on my system. The build settings are identical. Joost Isn't that bad here: official release 1.4.3: 20s cmake/Release 1.5svn : 28s It is better here (without my local optimisation): 1.4.3: 22s 1.5svn: 18s This is with Qt4.1.3, maybe Qt4.2 is the problem? Abdel.
Re: Can LyX handle large files ?
Asger Ottar Alstrup [EMAIL PROTECTED] writes: | So it's fair to conclude that debugstream is a piece of crap. I | suspect that even the tiniest lyxerr statement costs a billion | cycles. You mean that you systems console is completely crap. -- Lgb
Re: Can LyX handle large files ?
Joost Verburg wrote: Martin Vermeer wrote: What does this mean we should do for 1.4.4, if anything, to get it faster (I am happy with 1.4.3 speed, but... any low hanging fruit?)? With all the current optimizations, 1.4.3 is still more than twice as fast as 1.5 when scrolling the user guide on my system. The build settings are identical. Do you see csrss.exe taking half of the cpu while scrolling the UserGuide? Abdel.
Re: Can LyX handle large files ?
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
This is without gcc debug STL, right?
No but this is with MSVC STL debug which is normally quite slow.
You're right, I should rebuild in release mode and see if things
have improved after all the different micro-optimisations that have
already taken place.
Abdelrazak Nope... unfortunately the MSVC-optimized version presents
Abdelrazak the exact same behaviour :-(
What about this patch that I never applied (yes I know I should...)?
It should give a big speedup to code that goes from inset to inset.
JMarc
Index: src/dociterator.C
===
--- src/dociterator.C (revision 13535)
+++ src/dociterator.C (working copy)
@@ -440,8 +440,29 @@ void DocIterator::forwardChar()
void DocIterator::forwardInset()
{
forwardPos();
- while (!empty() (pos() == lastpos() || nextInset() == 0))
+
+#if 0
+ DocIterator cmp(*this);
+#endif
+
+ while (!empty() !nextInset()) {
+ if (inTexted()) {
+ pos_type const lastp = lastpos();
+ Paragraph const par = paragraph();
+ pos_type pos = top().pos();
+ while (pos lastp !par.isInset(pos))
+++pos;
+ if (pos lastp)
+break;
+ }
forwardPos();
+ }
+
+#if 0
+ while (!cmp.empty() (cmp.pos() == cmp.lastpos() || !cmp.nextInset()))
+ cmp.forwardPos();
+ BOOST_ASSERT(cmp == *this);
+#endif
}
Re: cutandpaste.C simplifications
Lars Gullik Bjønnes wrote: And you now have to add comments to tell what the loop is doing instead of having that implied by the name of the function for_each calls... C'mon Lars, there is a big fat comment inside of the loop! Do you want me to explain what a loop is? How many loop does LyX have that are not explained at all? Do you want all of them to become algorithms? Michael
BOOST_ASSERT
Hi,
why don't we stop LyX, if an assertion failed? I though this was the
overall purpose of assertions...
void assertion_failed(char const* a, char const* b, char const* c, long d)
{
lyx::lyxerr Assertion failed: a ' ' b ' ' c
' '
d '\n';
}
Michael
Re: Can LyX handle large files ?
Having a look at the scrolling times, normalized to Joost's 1.4 build Joost 1.4 : 1 Joost 1.5 : 2 cmake 1.5 : 1.4 indicates that some compiler flags and macro definitions could speed up the 1.4 without only further changes. I think it's more likely that it depends on the window size. We should compare performance both in a small / large windows. Joost
Re: BOOST_ASSERT
Michael == Michael Gerz [EMAIL PROTECTED] writes:
Michael Hi, why don't we stop LyX, if an assertion failed? I though
Michael this was the overall purpose of assertions...
Michael void assertion_failed(char const* a, char const* b, char
Michael const* c, long d) { lyx::lyxerr Assertion failed: a
Michael ' ' b ' ' c ' ' d '\n';
Michael }
We call support::abort(), don't we?
JMarc
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Do you see csrss.exe taking half of the cpu while scrolling the UserGuide? Not at all, usually only 1-2%. Joost
Re: Qt and window messages
Joost == Joost Verburg [EMAIL PROTECTED] writes: Joost Hi, I have a question about Qt on Windows: Is it possible to Joost create a window procedure to capture standard window messages Joost (not Qt events)? I guess you can use a winEventFilter in GuiApplication.C. JMarc
Re: BOOST_ASSERT
Jean-Marc Lasgouttes wrote: We call support::abort(), don't we? No, we don't. Shall I add this to function assertion_failed()? Michael
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. Abdelrazak Nope... unfortunately the MSVC-optimized version presents Abdelrazak the exact same behaviour :-( What about this patch that I never applied (yes I know I should...)? It should give a big speedup to code that goes from inset to inset. The patch is too old I guess, it does not apply cleanly. Abdel.
Re: 1.5.0 on Mac Update
On Wed, Nov 08, 2006 at 05:25:21PM +0100, Georg Baum wrote: Bennett Helm wrote: On Nov 8, 2006, at 10:17 AM, Enrico Forestieri wrote: On Wed, Nov 08, 2006 at 03:59:04PM +0100, Joost Verburg wrote: Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Then this must be another problem related to MSVC, as using GCC it works. Whatever viewer I define in lyxrc.dist is used, indeed. To be clear, the issue is not with whether the converter/viewer gets used: entering Cmd-D will produce a .dvi file and open it in the viewer I've defined. The issue is merely with what items appear in the View menu. That (and Kornels example) rings a bell: You must put the document flag into the format line of the preferences file. Otherwise the format will not be shown in the view menu. This is changed from 1.4 (1.4 does not have a document flag). Note to packagers: You should add that flag to all formats in lyxrc.dist that should appear in the view menu. It works for me even if I put the following lines in lyxrc.dist: \Format pdf pdf PDF (ps2pdf) P acroread \Format pdf2 pdf PDF (pdflatex) F acroread \Format pdf3 pdf PDF (dvipdfm) m acroread I see the entries in the View menu and the script acroread is used for viewing, indeed. I see no difference when using \Format pdf pdf PDF (ps2pdf) P acroread document,vector \Format pdf2 pdf PDF (pdflatex) F acroread document,vector \Format pdf3 pdf PDF (dvipdfm) m acroread document,vector or even \Format pdf pdf PDF (ps2pdf) P acroread \Format pdf2 pdf PDF (pdflatex) F acroread \Format pdf3 pdf PDF (dvipdfm) m acroread So, what's wrong? -- Enrico
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. Abdelrazak Nope... unfortunately the MSVC-optimized version presents Abdelrazak the exact same behaviour :-( What about this patch that I never applied (yes I know I should...)? It should give a big speedup to code that goes from inset to inset. Hum... unfortunately it makes lyx crash on the math test document. inset: 037895B0 idx: 0 par: 1 pos: 1 inset: 03846948 idx: 0 par: 0 pos: 0 Assertion failed: inTexted() class lyx::Paragraph __thiscall lyx::DocIterator:: paragraph(void) ..\..\..\src\dociterator.C 161 Abdel.
Re: BOOST_ASSERT
Michael == Michael Gerz [EMAIL PROTECTED] writes: Michael Jean-Marc Lasgouttes wrote: We call support::abort(), don't we? Michael No, we don't. Shall I add this to function Michael assertion_failed()? In which boost.C are you currently looking? There are several ones... The one I looked at is src/boost.C. It does use abort. JMarc
Re: Can LyX handle large files ?
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: What about this patch that I never applied (yes I know I should...)? It should give a big speedup to code that goes from inset to inset. Abdelrazak Hum... unfortunately it makes lyx crash on the math test Abdelrazak document. Abdelrazak inset: 037895B0 idx: 0 par: 1 pos: 1 inset: 03846948 idx: Abdelrazak 0 par: 0 pos: 0 So it uses less CPU cycles, in some way ;) This is unfortunate, I really thought I tested it well at the time. JMarc
Re: r15615 - in /lyx-devel/trunk/src: insets/insettabular.C m...
On Mon, Oct 30, 2006 at 02:19:02PM +0100, Abdelrazak Younes wrote:
- : qwa_(qwa)
-{
- //lyxerr QLPainter::start() endl;
- QPainter::begin(qwa_);
+QLPainter::QLPainter(QPaintDevice * device)
+ : QPainter(device), Painter()
+{
The empty Painter() contructor would be used even if it were not
explicitly specified.
Andre'
Re: Can LyX handle large files ?
On Wed, Nov 08, 2006 at 02:41:57PM +0100, Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Here some numbers, msvc/Release: when crss eats 100 seconds lyx only needs 32 seconds (cpu-time in the tsak manager). If these 100 sec are really wasted by lyxerr, the we waste 75% of the cpu time for nothing. While it would be nice if someone steps up and implement JMarc' Macro based optimisation for lyxerr, I am pretty sure that lyxerr is not responsible for the slowness here. Here is my theory, following Georg and JMarc suggestions and my own investigation: I think that DocIterator is the culprit here. The fact that mathed uses a lot insets (especially in this test file!) is just a show case. Now, I still don't understand very well how csrss.exe enters the loop here. I've found this searching the Platform SDK: Now we can see the reasons for the context switches. Solitaire is calling CSRSS constantly, and most of the time is spent in CSRSS running a single thread. The processor is not spending a great deal of time running the Solitaire program. It would appear that Windows NT that has the problem. By using the WAP profiling tool, no longer included with the Platform SDK, we discovered that Solitaire was making a lot of calls to the GetPixel and SetPixel functions. Maybe Qt calls csrss. It's not Qt per se. I compiled 1.3.7 using the same Qt version (3.3.5) as that used in 1.4.x, and I don't have any problem with this document: http://bugzilla.lyx.org/attachment.cgi?id=1296action=view I can easily scroll and edit it, despite csrss.exe eats a lot of cpu cycles, too. Also, in 1.3.7 I don't see the bug I mentioned at http://bugzilla.lyx.org/show_bug.cgi?id=2900 -- Enrico
Re: 1.5.0 on Mac Update
On Wed, Nov 08, 2006 at 06:50:00PM +0100, Enrico Forestieri wrote: On Wed, Nov 08, 2006 at 05:25:21PM +0100, Georg Baum wrote: Bennett Helm wrote: On Nov 8, 2006, at 10:17 AM, Enrico Forestieri wrote: On Wed, Nov 08, 2006 at 03:59:04PM +0100, Joost Verburg wrote: Bennett Helm wrote: 9. Some oddities with View menu remain: DVI does not appear in the menu, even though a converter and viewer are defined in Preferences. I have the same problem with PDF on Windows. Only the auto entires work. Then this must be another problem related to MSVC, as using GCC it works. Whatever viewer I define in lyxrc.dist is used, indeed. To be clear, the issue is not with whether the converter/viewer gets used: entering Cmd-D will produce a .dvi file and open it in the viewer I've defined. The issue is merely with what items appear in the View menu. That (and Kornels example) rings a bell: You must put the document flag into the format line of the preferences file. Otherwise the format will not be shown in the view menu. This is changed from 1.4 (1.4 does not have a document flag). Note to packagers: You should add that flag to all formats in lyxrc.dist that should appear in the view menu. It works for me even if I put the following lines in lyxrc.dist: \Format pdf pdf PDF (ps2pdf) P acroread \Format pdf2 pdf PDF (pdflatex) F acroread \Format pdf3 pdf PDF (dvipdfm) m acroread I see the entries in the View menu and the script acroread is used for viewing, indeed. I see no difference when using \Format pdf pdf PDF (ps2pdf) P acroread document,vector \Format pdf2 pdf PDF (pdflatex) F acroread document,vector \Format pdf3 pdf PDF (dvipdfm) m acroread document,vector or even \Format pdf pdf PDF (ps2pdf) P acroread \Format pdf2 pdf PDF (pdflatex) F acroread \Format pdf3 pdf PDF (dvipdfm) m acroread So, what's wrong? Me, I think. Never mind, I was experimenting with 1.4.4svn, not 1.5.0svn... -- Enrico
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: What about this patch that I never applied (yes I know I should...)? It should give a big speedup to code that goes from inset to inset. Abdelrazak Hum... unfortunately it makes lyx crash on the math test Abdelrazak document. Abdelrazak inset: 037895B0 idx: 0 par: 1 pos: 1 inset: 03846948 idx: Abdelrazak 0 par: 0 pos: 0 So it uses less CPU cycles, in some way ;) This is unfortunate, I really thought I tested it well at the time. No, it's not your patch. LyX crashes without it too! Use case: 1) Open the doc 2) PageDown 3) BOUM. Unfortunately, your patch doesn't seem to help with the test document. *But* it seems to help when breaking a section in a big document. I'd say apply it! Abdel.
Re: 1.5.0 on Mac Update
On Nov 8, 2006, at 11:25 AM, Georg Baum wrote: That (and Kornels example) rings a bell: You must put the document flag into the format line of the preferences file. Otherwise the format will not be shown in the view menu. This is changed from 1.4 (1.4 does not have a document flag). Note to packagers: You should add that flag to all formats in lyxrc.dist that should appear in the view menu. I believe that this is no bug, but the changed file format of the preferences file. We should probably write about that in the release notes. That did the trick. The lyxrc.example file should be updated with this info. Bennett
Re: 1.5.0 on Mac Update
Am Mittwoch, 8. November 2006 20:54 schrieb Bennett Helm: That did the trick. The lyxrc.example file should be updated with this info. That file is totally outdated. I will remove it if I don't get objections. Georg
Re: BOOST_ASSERT
Am Mittwoch, 8. November 2006 18:33 schrieb Michael Gerz: Hi, why don't we stop LyX, if an assertion failed? I though this was the overall purpose of assertions... Yes, and we did until some time ago. I don't know who changed it and why, thi should be changed back IMHO. Georg
Re: 1.5.0 on Mac Update
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Am Mittwoch, 8. November 2006 20:54 schrieb Bennett Helm: That did the trick. The lyxrc.example file should be updated with this info. Georg That file is totally outdated. I will remove it if I don't get Georg objections. Please remove it. JMarc
Re: Lyx1.5 crashes in preferences
i think i tracked down the troubles in the updating while
reorganizing (simplifying) the code a bit.
the patch is not very readable but here is what it does:
the first problem was due to qlistview emitting currentRowChanged(int)
signals when refilling it (and then triggering swicht_converter(int)
calls) and somehow that seemed to cause trouble.
i now block signals when updating it
second problem seemed to be due to a missing :
form_-converters().update(form_-formats());
when modifying a format.
while i was at it i also got rid of the pointer to PrefConverters in the
formats module and replaced the call
- formats-setConverters(converters);
with a signal
+ connect(formats, SIGNAL(formatsChanged()),
+ converters, SLOT(updateGui()));
...
this is not a part of the preferences dialog where i come often (ie
never) so if someone can give it a ride then that would be great
comments of course appreciated
lyx is better than sudoku
Index: src/frontends/qt4/QPrefsDialog.C
===
--- src/frontends/qt4/QPrefsDialog.C(revision 15807)
+++ src/frontends/qt4/QPrefsDialog.C(working copy)
@@ -858,11 +858,11 @@
setupUi(this);
connect(converterNewPB, SIGNAL(clicked()),
- this, SLOT(new_converter()));
+ this, SLOT(update_converter()));
connect(converterRemovePB, SIGNAL(clicked()),
this, SLOT(remove_converter()));
connect(converterModifyPB, SIGNAL(clicked()),
- this, SLOT(modify_converter()));
+ this, SLOT(update_converter()));
connect(convertersLW, SIGNAL(currentRowChanged(int)),
this, SLOT(switch_converter(int)));
connect(converterFromCO, SIGNAL(activated(const QString)),
@@ -909,17 +909,21 @@
converterToCO-addItem(toqstr(cit-prettyname()));
}
+ // currentRowChanged(int) is also triggered when updating the listwidget
+ // block signals to avoid unnecessary calls to switch_converter(int nr)
+ convertersLW-blockSignals(true);
convertersLW-clear();
Converters::const_iterator ccit = form_-converters().begin();
Converters::const_iterator cend = form_-converters().end();
for (; ccit != cend; ++ccit) {
- std::string const name = ccit-From-prettyname() + -
- +
ccit-To-prettyname();
- new QListWidgetItem(toqstr(name), convertersLW,
-
form_-converters().getNumber(ccit-From-name(), ccit-To-name()));
+ std::string const name =
+ ccit-From-prettyname() + - +
ccit-To-prettyname();
+ int type = form_-converters().getNumber(ccit-From-name(),
ccit-To-name());
+ new QListWidgetItem(toqstr(name), convertersLW, type);
}
convertersLW-sortItems(Qt::AscendingOrder);
+ convertersLW-blockSignals(false);
// restore selection
if (!current.isEmpty()) {
@@ -928,6 +932,7 @@
if (item.size()0)
convertersLW-setCurrentItem(item.at(0));
}
+
// select first element if restoring failed
if (convertersLW-currentRow() == -1)
convertersLW-setCurrentRow(0);
@@ -938,13 +943,7 @@
void PrefConverters::switch_converter(int nr)
{
- if (nr 0)
- return;
-
int const cnr = convertersLW-currentItem()-type();
- // FIXME: why is there now valid current item?
- if (cnr 0)
- return;
Converter const c(form_-converters().get(cnr));
converterFromCO-setCurrentIndex(form_-formats().getNumber(c.from));
converterToCO-setCurrentIndex(form_-formats().getNumber(c.to));
@@ -963,19 +962,14 @@
void PrefConverters::updateButtons()
{
- Format const from(form_-formats().get(
- converterFromCO-currentIndex()));
- Format const to(form_-formats().get(
- converterToCO-currentIndex()));
+ Format const
from(form_-formats().get(converterFromCO-currentIndex()));
+ Format const to(form_-formats().get(converterToCO-currentIndex()));
int const sel = form_-converters().getNumber(from.name(), to.name());
bool const known = !(sel 0);
bool const valid = !(converterED-text().isEmpty()
|| from.name() == to.name());
int const cnr = convertersLW-currentItem()-type();
- // FIXME: why is there now valid current item?
- if (cnr 0)
- return;
Converter const c(form_-converters().get(cnr));
string const old_command = c.command;
string const old_flag = c.flags;
@@ -992,49 +986,21 @@
// FIXME: user must
// specify unique from/to or it doesn't appear. This is really bad UI
-void PrefConverters::new_converter()
Restore window positions
Attached a patch to restore the
windows position correctly.
Once again a Qt bug.
Please test it if it becomes better on Linux.
Peter
Index: src/frontends/qt4/GuiView.C
===
--- src/frontends/qt4/GuiView.C (revision 15808)
+++ src/frontends/qt4/GuiView.C (working copy)
@@ -100,7 +100,10 @@
NameMap namemap;
WidgetWithTabBar* wt;
- GuiViewPrivate()
+ int posx_offset;
+ int posy_offset;
+
+ GuiViewPrivate() : wt(0), posx_offset(0), posy_offset(0)
{}
};
@@ -169,7 +172,7 @@
// Then also the moveEvent, resizeEvent, and the
// code for floatingGeometry_ can be removed;
// adjust GuiView::setGeometry()
-#ifdef Q_OS_WIN32
+#ifdef Q_OS_WIN
QRect geometry = normalGeometry();
#else
updateFloatingGeometry();
@@ -182,8 +185,8 @@
session.sessionInfo().save(WindowHeight,
convertstring(geometry.height()));
session.sessionInfo().save(WindowIsMaximized, (isMaximized() ? yes
: no));
if (lyxrc.geometry_xysaved) {
- session.sessionInfo().save(WindowPosX,
convertstring(geometry.x()));
- session.sessionInfo().save(WindowPosY,
convertstring(geometry.y()));
+ session.sessionInfo().save(WindowPosX,
convertstring(geometry.x() + d.posx_offset));
+ session.sessionInfo().save(WindowPosY,
convertstring(geometry.y() + d.posy_offset));
}
getToolbars().saveToolbarInfo();
}
@@ -203,10 +206,9 @@
QRect desk = dw.availableGeometry(dw.primaryScreen());
(posx = desk.width() ? posx = 50 : true);
(posy = desk.height()? posy = 50 : true);
-#ifdef Q_WS_WIN
- // FIXME: use only setGeoemtry when Trolltech has
- // fixed the qt4/X11 bug
- QMainWindow::setGeometry(posx, posy,width, height);
+#ifdef Q_OS_WIN
+ // FIXME: use setGeometry only when Trolltech has fixed
the qt4/X11 bug
+ QWidget::setGeometry(posx, posy, width, height);
#else
resize(width, height);
move(posx, posy);
@@ -218,12 +220,29 @@
if (maximize)
setWindowState(Qt::WindowMaximized);
}
-
+
show();
// For an unknown reason, the Window title update is not effective for
// the second windows up until it is shown on screen (Qt bug?).
updateWindowTitle();
+
+ // after show geometry() has changed (Qt bug?)
+ // we compensate the drift when storing the position
+ d.posx_offset = 0;
+ d.posy_offset = 0;
+ if (width != 0 height != 0)
+ if (posx != -1 posy != -1) {
+#ifdef Q_OS_WIN
+ d.posx_offset = posx - normalGeometry().x();
+ d.posy_offset = posy - normalGeometry().y();
+#else
+ if (!maximize) {
+ d.posx_offset = posx - geometry().x();
+ d.posy_offset = posy - geometry().y();
+ }
+#endif
+ }
}
scons error building LyX under Win
When I want to compile LyX using the
build_msvc.bat
script, I get the following error:
---
scons: Reading SConscript files ...
type 'exceptions.AttributeError': 'NoneType' object has no attribute
'split':
File D:\LyXSVN\lyx-devel\development\scons\SConstruct, line 425:
env.Tool('msvc')
File C:\Python25\scons-0.96.93\SCons\Environment.py, line 1306:
tool(self)
File C:\Python25\scons-0.96.93\SCons\Tool\__init__.py, line 154:
apply(self.generate, ( env, ) + args, kw)
File C:\Python25\scons-0.96.93\SCons\Tool\msvc.py, line 732:
env.PrependENVPath('INCLUDE', include_path)
File C:\Python25\scons-0.96.93\SCons\Environment.py, line 1220:
nv = SCons.Util.PrependPath(orig, newpath, sep)
File C:\Python25\scons-0.96.93\SCons\Util.py, line 677:
paths = string.split(paths, sep)
File C:\Python25\lib\string.py, line 290:
return s.split(sep, maxsplit)
---
Any ideas?
---
@ Joost:
The file
INSTALL.Win32
should mention that you have to add the following MSVC path to the PATH
variable when you use the free MSVC 2005 edition:
C:\Program Files\MSVC\Common7\IDE;
C:\Program Files\MSVC\VC\bin
regards Uwe
Re: scons error building LyX under Win
File C:\Python25\scons-0.96.93\SCons\Environment.py, line I can not investigate this now but you are using the newest scons-0.96.93, not 0.96.92. Maybe there is some backward compatibility problem. I will update SConstruct with 0.96.93 when I get back. Bo
Re: Restore window positions
On Wed, Nov 08, 2006 at 11:28:49PM +0100, Peter Kümmel wrote: Attached a patch to restore the windows position correctly. Please Peter, use Q_WS_WIN instead of Q_OS_WIN, as this is also relevant to a cygwin build without X11, where the former is defined but not the latter. -- Enrico
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: > I guess that's what the person who wrote debugstream thought. "This is > probably good enough." It is IMO a nice solution for outputting simple stuff without plastering the code with if(). The problem it has is that the right hand side is always computed, even if the output is discarded. But if one keeps that in mind it is a good debug utility. > But that person forgot to have a look at > nullstream. It is a piece of absolute crap. You can certainly backup that statement with measurements or other evidence? Otherwise it falls back on yourself. > So it boils down to a very simple message for all coders here: > > ** Don't use lyxerr[] in a critical code path. *** Wrong. Right is: Don't use any lyxerr in a critical code path at all, and don't use lyxerr[] anywhere if the right hand side is expensive to compute. lyxerr[Debug::PAINTING] << "Painting at x = " << x << ", y = " << y << '\n'; where x and y are simple numbers is pretty cheap. We have several commented lyxerr statements in the code in performance critical sections. They are commented and not used with [] exactly for performance reasons. I think the main problem is that many debug statements have been added lately by people who where not aware how lyxerr really works. Georg
Re: Can LyX handle large files ?
Asger Ottar Alstrup wrote: Abdelrazak Younes wrote: You misunderstood me. I don't deny you are right these are probably too expensive. I am just saying that I am not convinced that this is the major culprit for the slowness on Mac and on Windows for LyX file with a lot of big equation. But hey, every bit of speed we can gain is good :-) Try to make a test program that does nothing but allocate small pieces of memory, fill it up, and then free it again. Before you run it, guess how many allocations you can do in a second. Then run it and learn. Well, well, well... I am not sure if you are joking here or if you are arrogant but, anyway, I'll repeat that again in upper case in case you didn't hear me: THIS IS NOT THE MAJOR CULPRIT FOR THE OBSERVED SLOWNESS! That being said, thanks for the C++ lecture ;-) Abdel.
Re: [1.5 PATCH] Re: [Bug 2882] not possible to delete row in ERT inset
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes: >> Could someone test it too? Michael? Michael> I did some basic testing (=> OK!) and applied the patch. I Michael> will have a look at the CT-specific parts by the end of the Michael> week. Thanks. JMarc
Re: Let us remove the multi-window support !
> "José" == José Matos <[EMAIL PROTECTED]> writes: >> Instead of hard-coding this like on Mac OS X right now, the Windows >> / Mac installers can set a default in lyxrc.dist and users will >> always be able to change it. The OSX case is different : this is specified at OS level and we are not supposed to do it differently. JMarc
Re: 3 important bugs right now - more testing needed!
> "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: Asger> * Spell checking cannot be invoked a second time. This is Asger> probably a one-liner. Asger> * The first time the spell checker is started, an empty window Asger> shown instead of the first misspelled word. Probably also a Asger> one-liner. Ha! The spellchecker is such a mess that these bugs are horrible to fix. It needs at least a small facelift to be usable. JMarc
Re: 3 important bugs right now - more testing needed!
On Wednesday 08 November 2006 8:54 am, Jean-Marc Lasgouttes wrote: > > Ha! The spellchecker is such a mess that these bugs are horrible to > fix. It needs at least a small facelift to be usable. I will shoot the first who disagrees with you about this. ;-) > JMarc -- José Abílio
Re: missing qt-4 dependencies
> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes: Joost> Uwe Stöhr wrote: >> But this file is not available. The available >> lyx-windows-deps-msvc.zip doesn't include the qt-4 stuff, only >> qt-3. Abdel, could you please upload or send me a version that >> includes the files. Joost> I uploaded this file yesterday, along with the 1.4.3-5 release. Joost> Jean-Marc will soon move these files to ftp.lyx.org. The files are there now. JMarc
Re: Can LyX handle large files ?
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> It is IMO a nice solution for outputting simple stuff without Georg> plastering the code with if(). The problem it has is that the Georg> right hand side is always computed, even if the output is Georg> discarded. But if one keeps that in mind it is a good debug Georg> utility. Providing Asger can back up his claim with evidence, it may be time to try the preprocessor trick I proposed some time ago: #define LYXERR(flag) if (lyxerr.debugging(flag)) lyxerr or maybe (to avoid problems with nested ifs) #define LYXERR(flag) if (!lyxerr.debugging(flag)); else lyxerr Then LYXERR(Debug::PAINTING) << foo << bar will do the right thing. JMarc
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> It is IMO a nice solution for outputting simple stuff without Georg> plastering the code with if(). The problem it has is that the Georg> right hand side is always computed, even if the output is Georg> discarded. But if one keeps that in mind it is a good debug Georg> utility. Providing Asger can back up his claim with evidence, it may be time to try the preprocessor trick I proposed some time ago: #define LYXERR(flag) if (lyxerr.debugging(flag)) lyxerr or maybe (to avoid problems with nested ifs) #define LYXERR(flag) if (!lyxerr.debugging(flag)); else lyxerr Then LYXERR(Debug::PAINTING) << foo << bar will do the right thing. Even though I don't like much macro, I think that in this case, this is an excellent idea! This is an easy (but boring) task, anyone volunteers? Abdel.
Re: Can LyX handle large files ?
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> The cursor and dociterator pist is a good one I think. I Abdelrazak> attach again the test file. At the end of file, appending Abdelrazak> characters at the end of the last line is _slow_ but Abdelrazak> hitting return and typing in a new line is very quick (as Abdelrazak> quick as usual I mean). So the relationship between two Abdelrazak> consecutive paragraph is the key to our problem I think. And this slowness is visible in csrss.exe? This is without gcc debug STL, right? JMarc
Re: Can LyX handle large files ?
Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> The cursor and dociterator pist is a good one I think. I Abdelrazak> attach again the test file. At the end of file, appending Abdelrazak> characters at the end of the last line is _slow_ but Abdelrazak> hitting return and typing in a new line is very quick (as Abdelrazak> quick as usual I mean). So the relationship between two Abdelrazak> consecutive paragraph is the key to our problem I think. And this slowness is visible in csrss.exe? I am not sure of what you mean... By slowness I mean that characters are slowly inserted. While inserting the characters one by one, csrss.exe occupies 50% of the CPU and lyx the rest. This behaviour is only visible for the paragraph immediately following the big formula. Insertion of characters in the following paragraph is rapid again. This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel.
Some dudes on 1.5.0 messages
Hi all,
I'm updating Basque translation for LyX 1.5.0 branch. But there are some
messages that i'm not sure bout their sense:
"Standard\t\\frac"
Here the '\\frac' word means a Latex command, and should be not
translate, as '\\arabic{theorem}'... or can translate it?
Same question for:
"No hor. line\t\\atop"
is 'atop' a LaTeX command?
Same question for:
"Nice\t\\nicefrac"
is 'nicefrac' a LaTeX command? And Nice would mean something like
'priority' ( used in UNIX systems to give a priority to a process), o it
senses like to be kind or beauty?
What means exactly
"Uncover"
"uncovered on slides "
means to quit some cover from the slides? or to show something?
Thanks and best regards,
Dooteo
Re: Some dudes on 1.5.0 messages
dooteo wrote:
> Hi all,
>
> I'm updating Basque translation for LyX 1.5.0 branch. But there are some
> messages that i'm not sure bout their sense:
>
>
>
> "Standard\t\\frac"
>
> Here the '\\frac' word means a Latex command, and should be not
> translate, as '\\arabic{theorem}'... or can translate it?
No, it should not be translated.
> Same question for:
>
> "No hor. line\t\\atop"
>
> is 'atop' a LaTeX command?
Yes.
> Same question for:
>
> "Nice\t\\nicefrac"
>
> is 'nicefrac' a LaTeX command?
Yes.
> And Nice would mean something like
> 'priority' ( used in UNIX systems to give a priority to a process), o it
> senses like to be kind or beauty?
The latter.
BTW these strings come from the math dialog and are not correctly formatted
(tabs vs. spaces). We can not know at all the tab width used by qt, so the
alignment should be done with spaces.
> What means exactly
>
> "Uncover"
> "uncovered on slides "
>
> means to quit some cover from the slides? or to show something?
That comes probably from the beamer layout file. I suggest to have a look at
the beamer manual.
Georg
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
Georg Baum wrote: Helge Hafting wrote: One issue: Some of my paragraph styles have names with iso-8859-1 encoded names. I don't know if that really was supported before. "Resymé" for example. I don't think that it was supported, because it would mean that "Resymé" was parsed as something entirely different if you used it in documents with a different encoding than iso-8859-1. The display in the drop down box would probably also have looked different if you did run LyX with a locale with different encoding. That is reasonable. I only ever run lyx with a single encoding, so I used iso8859-1 in my layout file. You simply can't write Norwegian with ascii only. Therefore, I really hope the .layout files will support unicode in some way, and utf-8 is the easy way for me. That would allow Norwegian words, and of course this would help people making russian/greek/chinese .layout files too. Now such styles are replaced with "standard" when I load documents, because the style inside the document isn't found. The string in the document no longer match the string in the .layout file when they are non-ascii. Further, if I use the paragraph style dropdown, my non-ascii (and not unicode either) style is there with the nonascii character appearing as boxes. Actually selecting this style crashes lyx instantly. I have no problem renaming such styles - maybe it fixes the problem, maybe not. I have some ascii-named styles that also have problems, but perhaps the non-ascii one cause some kind of internal messup. I don't think so. Other styles should not be affected, but it would be nice if you could check that by renaming the latin1 styles. I removed all non-ascii from the .layout file - even stuff in comments and text supposed to go into the document. I can now select the "Resyme" style without crashing lyx, having a latin1 é in the word was a crasher. Perhaps not an important one, I have no problem cleaning up stuff that was supported only by accident before. The worse problem is that my sanitized .layout file still doesn't work - for the simple reason that no preamble stuff whatsoever goes into the produced .tex file. So my custom environments and tex commands go unrecognized because they aren't defined anywhere. I am trying to make a minimal .layout but this is tricky - a small layout file with a custom environment worked! I prefer utf8 in the .layout files, but that surely wasn't possible before. Currently layout files can only contain ASCII, but changing that to utf8 would not be much work. Then I hope for utf-8. .layout files. :-) Helge Hafting
Re: Some dudes on 1.5.0 messages
Thanks Georg :)
Jatorrizko mezua: az., 2006-11-08 11:13 +0100, egilea: Georg Baum
> dooteo wrote:
>
> > Hi all,
> >
> > I'm updating Basque translation for LyX 1.5.0 branch. But there are some
> > messages that i'm not sure bout their sense:
> >
> >
> >
> > "Standard\t\\frac"
> >
> > Here the '\\frac' word means a Latex command, and should be not
> > translate, as '\\arabic{theorem}'... or can translate it?
>
> No, it should not be translated.
>
> > Same question for:
> >
> > "No hor. line\t\\atop"
> >
> > is 'atop' a LaTeX command?
>
> Yes.
>
> > Same question for:
> >
> > "Nice\t\\nicefrac"
> >
> > is 'nicefrac' a LaTeX command?
>
> Yes.
>
> > And Nice would mean something like
> > 'priority' ( used in UNIX systems to give a priority to a process), o it
> > senses like to be kind or beauty?
>
> The latter.
>
> BTW these strings come from the math dialog and are not correctly formatted
> (tabs vs. spaces). We can not know at all the tab width used by qt, so the
> alignment should be done with spaces.
>
>
> > What means exactly
> >
> > "Uncover"
> > "uncovered on slides "
> >
> > means to quit some cover from the slides? or to show something?
>
> That comes probably from the beamer layout file. I suggest to have a look at
> the beamer manual.
>
>
> Georg
[patch]docbook glossaries export
Attached is patch for docbook glossaries export. Missing
features are:
- glossary entries in insets does not appear in glossary. I couldn't
find a "chic" way to include those.. (the current one is not so chic
anyway.. ) Any ideas??
- prefix is not working, therefore, you cannot change the sorting.
(any idea how to do it?)
- possible performance problems. (not tested)
Ugras
Index: src/paragraph.h
===
--- src/paragraph.h (revision 15801)
+++ src/paragraph.h (working copy)
@@ -158,6 +158,10 @@
LyXFont const & outerfont,
pos_type initial = 0) const;
+ void simpleDocBookGlossary(Buffer const & buf,
+ OutputParams const & runparams,
+ odocstream &,
+ pos_type initial = 0) const;
///
bool hasSameLayout(Paragraph const & par) const;
Index: src/paragraph.C
===
--- src/paragraph.C (revision 15801)
+++ src/paragraph.C (working copy)
@@ -1201,6 +1201,23 @@
}
+void Paragraph::simpleDocBookGlossary(Buffer const & buf,
+OutputParams const & runparams,
+odocstream & os,
+pos_type initial) const
+{
+// pos_type initial = 0;
+
+ for (pos_type i = initial; i < size(); ++i) {
+ if (isInset(i)) {
+ InsetBase const * inset = getInset(i);
+ if(inset->lyxCode() == InsetBase::NOMENCL_CODE )
+inset->docbook(buf, os, runparams);
+ }
+ }
+}
+
+
void Paragraph::simpleDocBookOnePar(Buffer const & buf,
odocstream & os,
OutputParams const & runparams,
@@ -1233,6 +1250,7 @@
if (isInset(i)) {
InsetBase const * inset = getInset(i);
+ if(inset->lyxCode() != InsetBase::NOMENCL_CODE )
inset->docbook(buf, os, runparams);
} else {
value_type c = getChar(i);
@@ -1245,7 +1263,6 @@
}
font_old = font;
}
-
if (emph_flag) {
os << "";
}
Index: src/insets/insetnomencl.C
===
--- src/insets/insetnomencl.C (revision 15801)
+++ src/insets/insetnomencl.C (working copy)
@@ -18,6 +18,10 @@
#include "LaTeXFeatures.h"
#include "metricsinfo.h"
#include "sgml.h"
+#include "paragraph.h"
+#include "paragraph_funcs.h"
+#include "ParagraphList.h"
+#include "buffer.h"
namespace lyx {
@@ -39,15 +43,15 @@
int InsetNomencl::docbook(Buffer const &, odocstream & os,
OutputParams const &) const
{
- // FIXME: This does not work, because the entry needs to be put
- // in the glossary.
-#if 0
- os << ""
+ // FIXME: This does not work when nomencl entry put inside the insets,
+ os << "" << '\n'
+ << ""
<< sgml::escapeString(getParam("symbol"))
- << ""
- << sgml::escapeString(getParam("description"))
- << "";
-#endif
+ << " " << '\n'
+ << ""
+ << sgml::escapeString(getParam("description")) << '\n'
+ << "" << '\n'
+ <<"" << '\n';
return 0;
}
@@ -75,11 +79,17 @@
}
-int InsetPrintNomencl::docbook(Buffer const &, odocstream & os,
- OutputParams const &) const
+int InsetPrintNomencl::docbook(Buffer const & buf, odocstream & os,
+ OutputParams const & params) const
{
- // FIXME This does not work, we need to define the entries here.
- //os << "";
+ ParagraphList::const_iterator beg = buf.paragraphs().begin();
+ ParagraphList::const_iterator par = buf.paragraphs().begin();
+ ParagraphList::const_iterator end = buf.paragraphs().end();
+ os << "" << '\n';
+ for (; par != end; ++par) {
+ par->simpleDocBookGlossary(buf,params,os);
+ }
+ os << "" << '\n';
return 0;
}
Index: lib/doc/Extended.lyx
===
--- lib/doc/Extended.lyx (revision 15801)
+++ lib/doc/Extended.lyx (working copy)
@@ -2677,7 +2677,7 @@
\noun on
Özgür U\i \~{g}
ra\i \c{s}
- Baram
+ Baran
\end_layout
\begin_layout Standard
@@ -2960,6 +2960,12 @@
\end_layout
+\begin_layout Standard
+ Docbook glossaries works in a similar way with a limitation. With the curent
+ version of lyx, glossary entries entered inside the insets (tables, notes,
+ etc.) are not processed.
+\end_layout
+
\begin_layout Section
Multipart Documents
\end_layout
AW: Re: 3 important bugs right now - more testing needed!
>On Wednesday 08 November 2006 8:54 am, Jean-Marc Lasgouttes wrote: >> >> Ha! The spellchecker is such a mess that these bugs are horrible to >> fix. It needs at least a small facelift to be usable. > > I will shoot the first who disagrees with you about this. ;-) > >José Abílio And who is going to do this dirty job? Does the spell checker bug stop us from releasing alpha 1 next Monday? Michael
Re: AW: Re: 3 important bugs right now - more testing needed!
On Wednesday 08 November 2006 11:18 am, [EMAIL PROTECTED] wrote: > > And who is going to do this dirty job? Volunteers accepted. :-) > Does the spell checker bug stop us from releasing alpha 1 next Monday? IMHO we should fix it for .0 version, for alpha if no solution is in sight I would prefer not to delay the first alpha because of this problem. What do you think? > Michael -- José Abílio
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: >>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> >> Abdelrazak> The cursor and dociterator pist is a good one I think. I >> Abdelrazak> attach again the test file. At the end of file, appending >> Abdelrazak> characters at the end of the last line is _slow_ but >> Abdelrazak> hitting return and typing in a new line is very quick (as >> Abdelrazak> quick as usual I mean). So the relationship between two >> Abdelrazak> consecutive paragraph is the key to our problem I think. >> >> And this slowness is visible in csrss.exe? > > I am not sure of what you mean... By slowness I mean that characters are > slowly inserted. While inserting the characters one by one, csrss.exe > occupies 50% of the CPU and lyx the rest. > This behaviour is only visible for the paragraph immediately following > the big formula. Insertion of characters in the following paragraph is > rapid again. > >> This is without gcc debug STL, right? > > No but this is with MSVC STL debug which is normally quite slow. You're > right, I should rebuild in release mode and see if things have improved > after all the different micro-optimisations that have already taken place. > There's a good chance that we have solved already most of the slowness > as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 > for this test document. > > Abdel. > > Here some numbers, msvc/Release: when crss eats 100 seconds lyx only needs 32 seconds (cpu-time in the tsak manager). If these 100 sec are really wasted by lyxerr, the we waste 75% of the cpu time for nothing. -- Peter Kümmel
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: > Jean-Marc Lasgouttes wrote: >>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> >> Abdelrazak> The cursor and dociterator pist is a good one I think. I >> Abdelrazak> attach again the test file. At the end of file, appending >> Abdelrazak> characters at the end of the last line is _slow_ but >> Abdelrazak> hitting return and typing in a new line is very quick (as >> Abdelrazak> quick as usual I mean). So the relationship between two >> Abdelrazak> consecutive paragraph is the key to our problem I think. >> >> And this slowness is visible in csrss.exe? > > I am not sure of what you mean... By slowness I mean that characters are > slowly inserted. While inserting the characters one by one, csrss.exe > occupies 50% of the CPU and lyx the rest. > This behaviour is only visible for the paragraph immediately following > the big formula. Insertion of characters in the following paragraph is > rapid again. > >> This is without gcc debug STL, right? > > No but this is with MSVC STL debug which is normally quite slow. You're > right, I should rebuild in release mode and see if things have improved > after all the different micro-optimisations that have already taken place. > There's a good chance that we have solved already most of the slowness > as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 > for this test document. > > Abdel. I've compared lyx 1.4 and 1.5svn (msvc/Release/Qt 4.1.2 -O2 optimized) with your file. I've done some more c and scrolled it down and still 1.4 is faster: 60s versus 80s. :( Peter
Re: Can LyX handle large files ?
Peter Kümmel wrote: Abdelrazak Younes wrote: This is without gcc debug STL, right? No but this is with MSVC STL debug which is normally quite slow. You're right, I should rebuild in release mode and see if things have improved after all the different micro-optimisations that have already taken place. There's a good chance that we have solved already most of the slowness as LyX-svn in debug mode is way faster than the (gcc-optimized) 1.4.3 for this test document. Abdel. I've compared lyx 1.4 and 1.5svn (msvc/Release/Qt 4.1.2 -O2 optimized) with your file. I've done some more c and scrolled it down and still 1.4 is faster: 60s versus 80s. :( Ah but that's because you don't have my painting optimisation :-) Anyway, this csrss.exe problem is independent of the painting performance. To convince yourself, put you cursor at the last paragraph of the test file such that no formula is shown on screen at all, only the text of the last paragraph. Then begin to type in this last paragraph with 1.4 and 1.5svn. You will see that 1.4 is totally unresponsive for a long time while 1.5 will insert the characters, albeit slowly. Abdel.
Re: Can LyX handle large files ?
Peter Kümmel wrote: Abdelrazak Younes wrote: Here some numbers, msvc/Release: when crss eats 100 seconds lyx only needs 32 seconds (cpu-time in the tsak manager). If these 100 sec are really wasted by lyxerr, the we waste 75% of the cpu time for nothing. While it would be nice if someone steps up and implement JMarc' Macro based optimisation for lyxerr, I am pretty sure that lyxerr is not responsible for the slowness here. Here is my theory, following Georg and JMarc suggestions and my own investigation: I think that DocIterator is the culprit here. The fact that mathed uses a lot insets (especially in this test file!) is just a show case. Now, I still don't understand very well how csrss.exe enters the loop here. Another show case for DocIterator slowness: 1) Copy and paste the contents of UserGuide 4 or 5 times. 2) Break a section 3) Wait... This is because the section numbering code is another big user of the DocIterator class. Abdel.
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
On Wednesday 08 November 2006 10:39 am, Helge Hafting wrote: > > Currently layout files can only contain ASCII, but changing that to utf8 > > would not be much work. > > Then I hope for utf-8. .layout files. :-) I understand what you want and I agree with the goal, but not with the way to do it. Layout names should be ascii and we should be able to have translations of the layout names. Or else we are repeating the mistakes made by excell when the spreadsheet language was the same of the locale and it was not possible to exchange the documents between different languages, because the commands were naturally different. That is crazy... > Helge Hafting -- José Abílio
Re: Can LyX handle large files ?
Abdelrazak Younes wrote: Anyway, this csrss.exe problem is independent of the painting performance. To convince yourself, put you cursor at the last paragraph of the test file such that no formula is shown on screen at all, only the text of the last paragraph. Then begin to type in this last paragraph with 1.4 and 1.5svn. You will see that 1.4 is totally unresponsive for a long time while 1.5 will insert the characters, albeit slowly. Another difference is that typing in a new paragraph after the last one will not exhibit the problem in 1.5 whereas it does in 1.4. So, if we don't solve this performance problem, a work-around it in 1.5 would be to insert an empty paragraph after a big inset. Maybe this can even be done at the code level... Abdel.
updated documentation for glossaries
attached is the updated documentation. Added howto change nomlabelwidth.
ugras
Index: src/insets/insetnomencl.h
===
--- src/insets/insetnomencl.h (revision 15801)
+++ src/insets/insetnomencl.h (working copy)
@@ -53,8 +53,7 @@
void validate(LaTeXFeatures & features) const;
// FIXME: This should be editable to set the label width (stored
// in params_["labelwidth"]).
- // Currently the width can be read from file and written, but not
- // changed.
+ // Currently the width can be altered in preamble (see documentation)
///
EDITABLE editable() const { return NOT_EDITABLE; }
///
Index: lib/doc/Extended.lyx
===
--- lib/doc/Extended.lyx (revision 15801)
+++ lib/doc/Extended.lyx (working copy)
@@ -2677,7 +2677,7 @@
\noun on
Özgür U\i \~{g}
ra\i \c{s}
- Baram
+ Baran
\end_layout
\begin_layout Standard
@@ -2956,10 +2956,25 @@
nomname}{List of Symbols}
\end_layout
+\begin_layout Standard
+ If you're unhappy with the amount of space for symbols, you can alter it by
+ adding following line to the preamble.
+\end_layout
+
\begin_layout LyX-Code
+\backslash
+renewcommand{
+\backslash
+nomlabelwidth}{3.0cm}
\end_layout
+\begin_layout Standard
+ Docbook glossaries works in a similar way with a limitation. With the curent
+ version of lyx, glossary entries entered inside the insets (tables, notes,
+ etc.) are not processed.
+\end_layout
+
\begin_layout Section
Multipart Documents
\end_layout
Re: r15805 - /lyx-devel/trunk/development/cmake/modules/FindQ...
[EMAIL PROTECTED] wrote: Author: kuemmel Date: Wed Nov 8 13:25:00 2006 New Revision: 15805 URL: http://www.lyx.org/trac/changeset/15805 Log: update to cmake's cvs version, fixes missing qtmain error on windows Hi Peter, Does that mean that I have to upgrade CMake? My version is 2.4-patch 2. Abdel.
