RE: shared paragraph parameters patch
On 03-Mar-2001 Lars Gullik Bjnnes wrote: Comments? (I think some small mathed stuff sneaked in...) Well and you had THOUGHTS about the small move of LyxFunc::Functions over to BufferView!? ;) I think it's a good move, cleans up some stuff! Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3
Re: Serbo-Croatian support in LyX
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: But if we read a latex file (through reLyX) using one of these encoding, we need to understand it, right? Dekel You can always change the encoding of a file using an external Dekel program (e.g. recode) so this should not be a problem. Yes, but having LyX support the encoding seems much simpler to me. Why do you think this will be a problem? JMarc
Re: shared paragraph parameters patch
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars The problem is that these methods have to be "handwritten" Lars anyway, they can't be operators since not all the members of the Lars ParameterStruct participate in set setting or comparison. And could these members be partitionned into several substructs, depending on whether we want to copy them or not. OK, I have not re-read the code, so I do not really know what I am talking about, so... JMarc
findreplace patch
Hi, I attach the patch that moves find/replace to frontends. It also moves some stuff out ouf LyXText. The files src/lyxfr1.[Ch] and src/lyxfr0.[Ch] can be removed. Could someone check and/or apply it? Thanks for your help. Greetings, Ed. ps. could someone apply the qt2 character patch? http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg19935.html findreplace.diff.gz
mathed39.diff
This splits MathedRowSt into the "real" structure holding the actual data
and the "list" part. The idea is do replace the list part with std::list or
std::vector later. Having proper assignment could help in the Dark Parts...
Andre'
--
Andr Pnitz [EMAIL PROTECTED]
Index: math_rowst.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_rowst.h,v
retrieving revision 1.2
diff -u -p -r1.2 math_rowst.h
--- math_rowst.h2001/02/16 09:25:43 1.2
+++ math_rowst.h2001/03/05 09:31:58
@@ -8,7 +8,8 @@
It allows to manage the extra info independently of the paragraph data.
Only used for multiline paragraphs.
*/
-class MathedRowSt
+
+class MathedRowStruct
{
public:
///
@@ -16,14 +17,10 @@ public:
///
explicit
- MathedRowSt(int n)
+ MathedRowStruct(int n)
: asc_(0), desc_(0), y_(0), widths_(n + 1, 0),
- numbered_(true), next_(0)
+ numbered_(true)
{}
- /// Should be const but...
- MathedRowSt * getNext() const;
- /// ...we couldn't use this.
- void setNext(MathedRowSt * n);
///
string const getLabel() const;
///
@@ -48,7 +45,9 @@ public:
void setNumbered(bool nf);
///
void setTab(int i, int t);
-private:
+ ///
+ friend class MathedRowSt;
+protected:
/// Vericals
int asc_;
///
@@ -61,6 +60,19 @@ private:
string label_;
///
bool numbered_;
+};
+
+class MathedRowSt : public MathedRowStruct {
+public:
+ ///
+ explicit MathedRowSt(int n)
+ : MathedRowStruct(n), next_(0)
+ {}
+ /// Should be const but...
+ MathedRowSt * getNext() const;
+ /// ...we couldn't use this.
+ void setNext(MathedRowSt * n);
+private:
///
MathedRowSt * next_;
};
@@ -81,84 +93,84 @@ void MathedRowSt::setNext(MathedRowSt *
inline
-string const MathedRowSt::getLabel() const
+string const MathedRowStruct::getLabel() const
{
return label_;
}
inline
-bool MathedRowSt::isNumbered() const
+bool MathedRowStruct::isNumbered() const
{
return numbered_;
}
inline
-int MathedRowSt::getBaseline() const
+int MathedRowStruct::getBaseline() const
{
return y_;
}
inline
-void MathedRowSt::setBaseline(int b)
+void MathedRowStruct::setBaseline(int b)
{
y_ = b;
}
inline
-int MathedRowSt::ascent() const
+int MathedRowStruct::ascent() const
{
return asc_;
}
inline
-int MathedRowSt::descent() const
+int MathedRowStruct::descent() const
{
return desc_;
}
inline
-void MathedRowSt::ascent(int a)
+void MathedRowStruct::ascent(int a)
{
asc_ = a;
}
inline
-void MathedRowSt::descent(int d)
+void MathedRowStruct::descent(int d)
{
desc_ = d;
}
inline
-int MathedRowSt::getTab(int i) const
+int MathedRowStruct::getTab(int i) const
{
return widths_[i];
}
inline
-void MathedRowSt::setLabel(string const l)
+void MathedRowStruct::setLabel(string const l)
{
label_ = l;
}
inline
-void MathedRowSt::setNumbered(bool nf)
+void MathedRowStruct::setNumbered(bool nf)
{
numbered_ = nf;
}
inline
-void MathedRowSt::setTab(int i, int t)
+void MathedRowStruct::setTab(int i, int t)
{
widths_[i] = t;
}
Re: mvc patch
On Saturday 03 March 2001 09:43, Lars Gullik Bjnnes wrote: Use this if you want to. Content-Type: text/x-patch; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: use scoped_ptr + some other small things Many thanks, Lars. I'm looking at it now. I have a #pragma question for you. I don't use g++, so don't know anything about them. Anyway, in the patch you have (see bottom). Is this a general rule? Ie, move system header files before the #pragma directive and local header files after it? Angus Index: src/frontends/xforms/Color.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/Color.C,v retrieving revision 1.5 diff -u -p -r1.5 Color.C --- src/frontends/xforms/Color.C2000/11/21 15:46:10 1.5 +++ src/frontends/xforms/Color.C2001/03/03 09:32:04 @@ -10,14 +10,16 @@ *==*/ #include config.h + +#include algorithm // max +#include cmath // floor + #include FORMS_H_LOCATION #ifdef __GNUG_ #pragma implementation #endif -#include algorithm // max -#include cmath // floor #include "Color.h"
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjnnes wrote: | | | This patch includes the previous one and adds the same memore saving | as with the paragraph parameters, but now also for LyXFont. | | It raises binary size a bit more than I would like, but the memory | footprint for Userguide is now ~500 Kb. | | Comments? | | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). Yes, I see the same here. So we have to decide if this is a slow down that we can live with. (on the cell phone the numbers above came out as 218 and 27 and I got really worried...) btw. by also having language in fontbits we can save 4 bytes more for each LyXFont in use. This brings the size of LyXFont down from 44 bytes to 8 bytes. Lgb
Re: Inset include behaviour.
Andre Poenitz [EMAIL PROTECTED] writes: | When you have 512 MB that is not a problem. ;-) | | Does LyX still compile with just 512 MB? I mean, taking under an hour or | so? I really don't have any recent evidence... Sure it does. ~18 minutes on PIII 700 with 128 Mb (gcc 2.96, 2.95 should be faster, 3.0 is slower, but that is probably due to the conforming c++ lib gcc people is working on this.) Lgb
Re: shared paragraph parameters patch
Juergen Vigna [EMAIL PROTECTED] writes: | On 03-Mar-2001 Lars Gullik Bjnnes wrote: | | Comments? | (I think some small mathed stuff sneaked in...) | | Well and you had THOUGHTS about the small move of LyxFunc::Functions over | to BufferView!? ;) Yes, but the plan was to clean it up in the process... Lgb
Re: mvc patch
Angus Leeming [EMAIL PROTECTED] writes: | On Saturday 03 March 2001 09:43, Lars Gullik Bjnnes wrote: | Use this if you want to. | | Content-Type: text/x-patch; name="Attachment: 1" | Content-Transfer-Encoding: 7bit | Content-Description: use scoped_ptr + some other small things | | | | Many thanks, Lars. I'm looking at it now. | | I have a #pragma question for you. I don't use g++, so don't know anything | about them. Anyway, in the patch you have (see bottom). | | Is this a general rule? Ie, move system header files before the #pragma | directive and local header files after it? No, not really. #pragma interface can be placed wherever you want to. #pragma implementation must be place in before the include that it corresponds to. but I like to separate system headers from local headers... Lgb
Re: shared paragraph parameters patch
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars The problem is that these methods have to be "handwritten" | Lars anyway, they can't be operators since not all the members of the | Lars ParameterStruct participate in set setting or comparison. | | And could these members be partitionned into several substructs, | depending on whether we want to copy them or not. OK, I have not | re-read the code, so I do not really know what I am talking about, | so... Perhaps... but some of the are up for deletion anyway (with new insets), so I don't really see the point in this. Lgb
Re: findreplace patch
On Monday 05 March 2001 09:36, Edwin Leuven wrote: Hi, ps. could someone apply the qt2 character patch? Ed, I thought I'd try and compile it, but configure fails because I have qt 2.2.1 here and configure looks for 2.2.3. Is this really needed or will I still be able to compile. from configure: #if (QT_VERSION 223) break_me_(//); #endif Angus
Re: [PATCH] xforms small changes
John Levon [EMAIL PROTECTED] writes: | This should help the iconify situation in xforms. | It also fixes a qt2 compile problem, changes Splash, | and removes the DEFAULT_LANGUAGE thing in docdlg.C Have this been comitted? Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Yes, I see the same here. So we have to decide if this is a slow Lars down that we can live with. (on the cell phone the numbers above Lars came out as 218 and 27 and I got really worried...) Where does the slowdown come from? The ShareContainer::get method? Concerning this ShareContainer template, an obvious question: isn't there a better container than vector for this kind of stuff (a map?). Or could we order the contents of the container so that the most requested items come first? All in all, the patch looks nice, but the slow down (especially on UserGuide.lyx, which is a useful file in its own right) is a problem... JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars Yes, I see the same here. So we have to decide if this is a slow | Lars down that we can live with. (on the cell phone the numbers above | Lars came out as 218 and 27 and I got really worried...) | | Where does the slowdown come from? The ShareContainer::get method? | Concerning this ShareContainer template, an obvious question: isn't | there a better container than vector for this kind of stuff (a map?). | Or could we order the contents of the container so that the most | requested items come first? A map is not very good since we don't have a obvious key (for the same reason a hash_map would be hard to use since a hash function would be hard to get fast/right/uniue). I agree that the linear search is not good. (and this is what causes the slowdown I belive, (also that we clean the container very often)) Prefferably the clean should be moved into the get, but I am a bit afraid that this can cause wrong behaviour, I have to think a bit more on that. Lgb
Re: [PATCH] xforms small changes
On Monday 05 March 2001 10:25, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | This should help the iconify situation in xforms. | It also fixes a qt2 compile problem, changes Splash, | and removes the DEFAULT_LANGUAGE thing in docdlg.C Have this been comitted? I committed all but the Splash stuff; John is reworking that. Angus
Re: findreplace patch
On Monday 05 March 2001 10:21, Angus Leeming wrote: On Monday 05 March 2001 09:36, Edwin Leuven wrote: Hi, ps. could someone apply the qt2 character patch? Ed, I thought I'd try and compile it, but configure fails because I have qt 2.2.1 here and configure looks for 2.2.3. Is this really needed or will I still be able to compile. from configure: #if (QT_VERSION 223) break_me_(//); #endif I see that Lars has beaten me to it and committed this patch. I'd just report that it compiles on my box, so I think the configure test should be changed to #if (QT_VERSION 221) at least. One small point. Launching the copyright dialog, I see that the program is now called KLyX Angus
Re: findreplace patch
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 05 March 2001 10:21, Angus Leeming wrote: | On Monday 05 March 2001 09:36, Edwin Leuven wrote: | |Hi, | | ps. could someone apply the qt2 character patch? | | Ed, | | I thought I'd try and compile it, but configure fails because I have qt | 2.2.1 | here and configure looks for 2.2.3. Is this really needed or will I still | be | able to compile. | | from configure: | #if (QT_VERSION 223) | | break_me_(//); | #endif | | | I see that Lars has beaten me to it and committed this patch. I'd just report | that it compiles on my box, so I think the configure test should be changed | to #if (QT_VERSION 221) at least. | | One small point. Launching the copyright dialog, I see that the program is | now called KLyX yes, remove that... Lgb
Re: mathed38.diff
Can you redo this patch? It crashes slighly with what I had in my tree
(that I just committed).
I attach a new diff.
Andre'
--
Andr Pnitz [EMAIL PROTECTED]
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.53
diff -u -p -r1.53 ChangeLog
--- ChangeLog 2001/03/05 10:18:36 1.53
+++ ChangeLog 2001/03/05 10:46:13
@@ -1,3 +1,10 @@
+
+2001-02-14 Andr Pnitz [EMAIL PROTECTED]
+ * math_macrotemplate.[Ch]:
+math_macro.C: move update() functionality to the macro
+
+ * math_rowst.h: split MathedRowSt into "data" and "list"
+
2001-03-01 Lars Gullik Bjnnes [EMAIL PROTECTED]
* math_macrotemplate.C (update): use MathMacro::getArg, and
Index: math_macro.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macro.C,v
retrieving revision 1.49
diff -u -p -r1.49 math_macro.C
--- math_macro.C2001/03/05 10:18:36 1.49
+++ math_macro.C2001/03/05 10:46:13
@@ -74,8 +74,8 @@ MathedInset * MathMacro::Clone()
void MathMacro::Metrics()
{
- if (args_.size() 0)
- tmplate_-update(*this);
+ for (int i = 0; i args_.size(); ++i)
+tmplate_-args_[i] = getArg(i);
tmplate_-SetStyle(size());
tmplate_-Metrics();
width = tmplate_-Width();
Index: math_macrotemplate.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.C,v
retrieving revision 1.12
diff -u -p -r1.12 math_macrotemplate.C
--- math_macrotemplate.C2001/03/05 10:18:36 1.12
+++ math_macrotemplate.C2001/03/05 10:46:13
@@ -116,14 +116,6 @@ void MathMacroTemplate::Metrics()
}
-void MathMacroTemplate::update(MathMacro const macro)
-{
- for (int i = 0; i nargs_; ++i) {
- args_[i] = macro.getArg(i);
- }
-}
-
-
void MathMacroTemplate::WriteDef(ostream os, bool fragile)
{
os "\n\\newcommand{\\" name "}";
@@ -158,6 +150,13 @@ MathParInset * MathMacroTemplate::getMac
} else
return 0;
}
+
+void MathMacroTemplate::setMacroPar(int i, MathedArray const ar)
+{
+ if (i = 0 i nargs_)
+ args_[i].setData(ar);
+}
+
void MathMacroTemplate::SetMacroFocus(int idx, int x, int y)
Index: math_macrotemplate.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.h,v
retrieving revision 1.8
diff -u -p -r1.8 math_macrotemplate.h
--- math_macrotemplate.h2001/03/05 10:18:36 1.8
+++ math_macrotemplate.h2001/03/05 10:46:13
@@ -43,12 +43,11 @@ public:
///
MathParInset * getMacroPar(int) const;
///
+ void setMacroPar(int, MathedArray const );
+ ///
void SetMacroFocus(int , int, int);
///
void setEditMode(bool);
-
- /// Replace the appropriate arguments with a specific macro's data
- void update(MathMacro const m);
private:
/// Are we in edit mode or not?
bool edit_;
Re: mvc patch
A! This one slipped through! Thanks, Lars. I commented out this line because I'm using xforms 0.89.0 or 0.88.1 here and I get a segfault when deleting a group of FL_OBJECTs such as the RadioButtonGroup here. The correct code is back in. Are you happy with the branch? Shall I make a patch against HEAD and submit? Angus Index: src/frontends/xforms/FormGraphics.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormGraphics.C,v retrieving revision 1.15.8.2 diff -u -p -r1.15.8.2 FormGraphics.C --- src/frontends/xforms/FormGraphics.C 2001/03/02 13:17:51 1.15.8.2 +++ src/frontends/xforms/FormGraphics.C 2001/03/03 09:32:31 @@ -56,6 +56,7 @@ FormGraphics::~FormGraphics() // Free the form. // delete dialog_; +#warning where is the dialog_ deleted? (Lgb) }
Re: findreplace patch
Edwin Leuven [EMAIL PROTECTED] writes: | Hi, | | I attach the patch that moves find/replace to frontends. It also moves some | stuff out ouf LyXText. The files src/lyxfr1.[Ch] and src/lyxfr0.[Ch] can be | removed. Could someone check and/or apply it? | | Thanks for your help. + bool const casesens, peculiar spelling... wouldn't "caseness" be better? Lgb
Re: mvc patch
On Monday 05 March 2001 10:55, Angus Leeming wrote: Lars, I'll follow your lead and use scoped_ptrs for the remaining xforms/Form*.[Ch] files. Ie, FormGraphics.h FormPrint.h FormRef.h FormSplash.h FormTabular.h FormTabularCreate.h FormToc.h FormUrl.h Angus
Re: Inset include behaviour.
On 5 Mar 2001, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | When you have 512 MB that is not a problem. ;-) | | Does LyX still compile with just 512 MB? I mean, taking under an hour or | so? I really don't have any recent evidence... Sure it does. ~18 minutes on PIII 700 with 128 Mb (gcc 2.96, 2.95 should be faster, 3.0 is slower, but that is probably due to the conforming c++ lib gcc people is working on this.) Lgb It only takes 3 or so hours for a full build with 2.91.66 (much faster than 2.95.2 and infinitely faster than gcc CVS of a acouple of months ago), on a P200 with 40Mb of memory. Times are cut down a lot by cutting out -g and -O, and replacing the final collect2 with ld. CVS gcc was unusable on that machine but as Lgb says they are working on that ... john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: findreplace patch
On Mon, 5 Mar 2001, Angus Leeming wrote: I see that Lars has beaten me to it and committed this patch. I'd just report that it compiles on my box, so I think the configure test should be changed to #if (QT_VERSION 221) at least. I changed this. Hmm. Ah yes ... I see what's gone on I think. I think that the uic for 2.2.1 wouldn't work for me. If it compiles fine otherwise, then yes, it should be backed down to 221 I did it just because 2.2.1 wasn't working, and 2.2.3 did ... I'll try it again when I have a moment thanks john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: findreplace patch
On Monday 05 March 2001 10:44, Lars Gullik Bjønnes wrote: | One small point. Launching the copyright dialog, I see that the program is | now called KLyX yes, remove that... Done. A
Re: Inset include behaviour.
It only takes 3 or so hours for a full build with 2.91.66 (much faster than 2.95.2 and infinitely faster than gcc CVS of a acouple of months ago), on a P200 with 40Mb of memory. So memory is the thing that really matters... as I mentioned it took me 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not scale very well above a certain level ;-} Times are cut down a lot by cutting out -g and -O, and replacing the final collect2 with ld. Do you have some automated way to do this? Andre' -- Andr Pnitz [EMAIL PROTECTED]
Re: Inset include behaviour.
On Mon, 5 Mar 2001, Andre Poenitz wrote: It only takes 3 or so hours for a full build with 2.91.66 (much faster than 2.95.2 and infinitely faster than gcc CVS of a acouple of months ago), on a P200 with 40Mb of memory. So memory is the thing that really matters... as I mentioned it took me 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not scale very well above a certain level ;-} I recommend using 2.91.66 instead, it is a lot less heavy on memory usage. Times are cut down a lot by cutting out -g and -O, and replacing the final collect2 with ld. Do you have some automated way to do this? no, I just had a little script ... john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: Inset include behaviour.
John Levon [EMAIL PROTECTED] writes: | On Mon, 5 Mar 2001, Andre Poenitz wrote: | | It only takes 3 or so hours for a full build with 2.91.66 (much faster | than 2.95.2 and infinitely faster than gcc CVS of a acouple of months | ago), on a P200 with 40Mb of memory. | | So memory is the thing that really matters... as I mentioned it took me | 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not | scale very well above a certain level ;-} | | I recommend using 2.91.66 instead, it is a lot less heavy on memory usage. And the C++ compiler is way behind... I prefere gcc 3.0, but usually use 2.96. Lgb
Re: mvc patch
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 05 March 2001 10:55, Angus Leeming wrote: | | Lars, I'll follow your lead and use scoped_ptrs for the remaining | xforms/Form*.[Ch] files. Ie, | | FormGraphics.h | FormPrint.h | FormRef.h | FormSplash.h | FormTabular.h | FormTabularCreate.h | FormToc.h | FormUrl.h Ok, don't forget to commit to the branch when finished so that I can try it. Lgb
Re: Inset include behaviour.
On 5 Mar 2001, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Mon, 5 Mar 2001, Andre Poenitz wrote: | | It only takes 3 or so hours for a full build with 2.91.66 (much faster | than 2.95.2 and infinitely faster than gcc CVS of a acouple of months | ago), on a P200 with 40Mb of memory. | | So memory is the thing that really matters... as I mentioned it took me | 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not | scale very well above a certain level ;-} | | I recommend using 2.91.66 instead, it is a lot less heavy on memory usage. And the C++ compiler is way behind... I prefere gcc 3.0, but usually use 2.96. Lgb Well in an ideal world, but this version is literally unusable on a low memory machine when compiling LyX. As in, left-for-a-day-compiling-lyxfunc.C unusable. Hopefully the work they are doing now will sort it out to the only moderately slower 2.95.2 performance john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: [PATCH] 1.1.6 install patch
"John" == John Levon [EMAIL PROTECTED] writes: John JMarc, here it is, with your suggestions. John I've tested it, it seems ok I commit a slightly modified version of the patch where the default suffix is "-VERSION", so that the default behaviour is the nice one we had before, but it is possible to have any suffix. JMarc
Re: Inset include behaviour.
John Levon [EMAIL PROTECTED] writes: | Well in an ideal world, but this version is literally unusable on a low memory |machine | when compiling LyX. As in, left-for-a-day-compiling-lyxfunc.C unusable. | | Hopefully the work they are doing now will sort it out to the only moderately | slower 2.95.2 performance I suspect that the move of parts of lyxfunc to bufferview has made things a bit better. Lgb
Re: [PATCH] 1.1.6 install patch
On 5 Mar 2001, Jean-Marc Lasgouttes wrote: "John" == John Levon [EMAIL PROTECTED] writes: John JMarc, here it is, with your suggestions. John I've tested it, it seems ok I commit a slightly modified version of the patch where the default suffix is "-VERSION", so that the default behaviour is the nice one we had before, but it is possible to have any suffix. JMarc Can you apply the 1.2.0 update one too, obviously with your small change as well ? thanks john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: [PATCH] 1.1.6 install patch
"John" == John Levon [EMAIL PROTECTED] writes: John Can you apply the 1.2.0 update one too, obviously with your John small change as well ? I am currently doing that. Concerning the reLyX issue I see a solution, which is to export a variable like VERSION suffix that the reLyX configure will read. However, I tend to think that we should remove the reLyX configure script altogether, since we will certainly never want to update reLyX independently from LyX (this was the initial reason). However, this is small stuff which can wait. JMarc
Re: ERT inset long rumored
"larry" == larry [EMAIL PROTECTED] writes: larry Just following up on the long-rumored ERT inset. After some larry minor commotion and even a lead LDN story about this a few larry months ago, I haven't heard anything. larry Is it true that there is support for the inset today, larry accessible by typing a command by hand in the control window? larry How is this done? Just type "M-x ert-insert". You can have a personal binding for it, or add it to your menus (for example insert) by adding in defaults.ui a line like Item "ERT" "ert-insert" larry What is the status of efforts to bring more formal, menu-based larry support into 1.2cvs? Not sure yet. JMarc
Re: ERT inset long rumored
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "larry" == larry [EMAIL PROTECTED] writes: | | larry Just following up on the long-rumored ERT inset. After some | larry minor commotion and even a lead LDN story about this a few | larry months ago, I haven't heard anything. | | larry Is it true that there is support for the inset today, | larry accessible by typing a command by hand in the control window? | larry How is this done? | | Just type "M-x ert-insert". You can have a personal binding for it, or | add it to your menus (for example insert) by adding in defaults.ui a | line like | | Item "ERT" "ert-insert" but remember that it is not officially supported yet... Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Yes, I see the same here. So we have to decide if this is a slow
Lars down that we can live with. (on the cell phone the numbers above
Lars came out as 218 and 27 and I got really worried...)
Where does the slowdown come from? The ShareContainer::get method?
Concerning this ShareContainer template, an obvious question: isn't
there a better container than vector for this kind of stuff (a map?).
Or could we order the contents of the container so that the most
requested items come first?
The problem is that the data in a LyXText instance is changed frequently
(in the LyXParagraph::GetFont and LyXText::GetFont methods).
The solution is perhaps to keep the LyXFont class unchanged, but in
LyXParagraph::FontTable store a boost::shared_ptrLyXFont
instead of a LyXFont.
btw. by also having language in fontbits we can save 4 bytes more for
each LyXFont in use. This brings the size of LyXFont down from 44
bytes to 8 bytes.
Another option (without using shared_ptr) is to change the members in
FontBits to chars (i.e. struct FontBits { char family; char series; ...})
This is a bit ugly, but at least it will give a memory reduction, without a
slowdown.
Re: findreplace patch
+ bool const casesens, peculiar spelling... wouldn't "caseness" be better? Whatever you want, I can also add "itive" to make it "casesensitive". You want a new patch, or is it ok as is for the moment? Ed.
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars Yes, I see the same here. So we have to decide if this is a slow
| Lars down that we can live with. (on the cell phone the numbers above
| Lars came out as 218 and 27 and I got really worried...)
|
| Where does the slowdown come from? The ShareContainer::get method?
| Concerning this ShareContainer template, an obvious question: isn't
| there a better container than vector for this kind of stuff (a map?).
| Or could we order the contents of the container so that the most
| requested items come first?
|
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptrLyXFont
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
| btw. by also having language in fontbits we can save 4 bytes more for
| each LyXFont in use. This brings the size of LyXFont down from 44
| bytes to 8 bytes.
|
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
Lgb
ChkTeX
Hi, very recently, I became aware of ChkTeX which is supported by LyX. However, it seems like the user has to find and compile ChkTeX on his own (no rpm file available). Would it be possible to include ChkTeX in the LyX distribution? Its development seems to have come to a complete stop so the effort for its maintainance should be minimal. Kind regards, Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: another patch...
On Mon, Mar 05, 2001 at 01:24:24PM +0100, Lars Gullik Bjønnes wrote:
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptrLyXFont
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
Why?
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
IIRC, we had something else: all the data was packed into a single unsigned
int, and that was indeed horrible.
With my suggestion it is not harder to maintain than the current code.
And you don't loose the type information because the interface method
(family(), series() etc.) do return the correct type.
Re: ButtonController questions
Please enlighten me why you think you have to implement it the way you suggest. Ok, here goes. If I leave out the all important line in ButtonController::input(): if (ButtonPolicy::SMI_NOOP == in) return; then the up,down,add,delete buttons in the Citation dialog become active when a entry is clicked on in the two browsers. I think this occurs because their state is controlled by the dialog rather than by the ButtonController, but I'm not sure about this. Of course, you could always extend ButtonController so that it can control _everything_, but that's definitely your baby not mine! Incidentally, this stuff is now in BRANCH_MVC. Wait a day or so and it'll be in HEAD, so you won't need to check out anything to experiment. I've got too many other things I'd like to address without modifying the ButtonController too. I consider this working code; fine to improve, but low priority. Angus
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | A map is not very good since we don't have a obvious key (for the same | reason a hash_map would be hard to use since a hash function would be | hard to get fast/right/uniue). | | I agree that the linear search is not good. (and this is what causes | the slowdown I belive, (also that we clean the container very | often)) we can sort the vector on the use_count of the shared_ptr. Then the items that is used by the most will be found first. Hmm... but we cannot use any of the other std::containers... but we can perhaps use a priority_queue (with a deque underneath). I'll do some other small changes first and then I will try that. I will send new patches as I make progress. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | Oh, we had that earlier, the code was close to impossible to maintain, | won't happen. and I'd hate to loose the type information. btw. clever | compilers are free to use a byte for most of those enums. | | IIRC, we had something else: all the data was packed into a single unsigned | int, and that was indeed horrible. (I know) | With my suggestion it is not harder to maintain than the current code. | And you don't loose the type information because the interface method | (family(), series() etc.) do return the correct type. You loose type information inside the LyXFont class. besides, I think I can speed it up quite a lot by changing when clean is done, and using a bit more clever container. Let's do that first. Lgb
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes: | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.495s user0m5.880s sys 0m0.030s On a PIII 700Mhz (with primed cache) without the primed cache it is ~13s. This is by moving the clean to another place. Lgb
Re: another patch...
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x 'lyx-quit' | | real0m8.495s | user0m5.880s | sys 0m0.030s | | On a PIII 700Mhz (with primed cache) With braindead use of push_heap: time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx About to handle -x 'lyx-quit' real0m8.515s user0m6.010s sys 0m0.050s Lgb
Re: another patch...
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x Lars lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x Lars 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | Lars On a PIII 700Mhz (with primed cache) Lars With braindead use of push_heap: Lars time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx Lars About to handle -x 'lyx-quit' Lars real 0m8.515s user 0m6.010s sys 0m0.050s I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... JMarc
Re: another patch...
"Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I tried the "benchmark" a bit here, and the times in Jean-Marc successive rune fluctuate enough that I do not see how you Jean-Marc can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs JMarc
Re: another patch...
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: | | Lars [EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | time ./src/lyx -x | Lars lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x | Lars 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | | | Lars On a PIII 700Mhz (with primed cache) | | Lars With braindead use of push_heap: | | Lars time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx | Lars About to handle -x 'lyx-quit' | | Lars real 0m8.515s user 0m6.010s sys 0m0.050s | | I tried the "benchmark" a bit here, and the times in successive rune | fluctuate enough that I do not see how you can interpret them... I never tried more than two runs in a row :-) Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
About to handle -x 'lyx-quit'
real0m8.515s
user0m6.010s
sys 0m0.050s
It still looks slow.
I still don't understand why we can't use my previous suggestion:
class FontTable {
public:
FontTable(size_type p, LyXFont const f) {
font_ = container.get(f);
container.clean();
}
LyXFont const font();
size_type pos();
private:
boost::shared_ptrLyXFont font_;
size_type pos_;
static ShareContainerLyXFont container;
};
Re: another patch...
Dekel Tsur [EMAIL PROTECTED] writes:
| On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjnnes wrote:
| time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| About to handle -x 'lyx-quit'
|
| real0m8.515s
| user0m6.010s
| sys 0m0.050s
|
| It still looks slow.
|
| I still don't understand why we can't use my previous suggestion:
|
| class FontTable {
| public:
| FontTable(size_type p, LyXFont const f) {
| font_ = container.get(f);
| container.clean();
| }
| LyXFont const font();
| size_type pos();
| private:
| boost::shared_ptrLyXFont font_;
| size_type pos_;
| static ShareContainerLyXFont container;
| };
Because I want to see if I can make the broader case faster first.
And your solution would benefit from this too.
Lgb
Re: another patch...
On 05-Mar-2001 Jean-Marc Lasgouttes wrote: Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs But this doesn't load a LyXText instance, does it? And there the Fonts are used most, isn't it? Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ By failing to prepare, you are preparing to fail.
Re: findreplace patch
On 05-Mar-2001 Edwin Leuven wrote: Whatever you want, I can also add "itive" to make it "casesensitive". You want a new patch, or is it ok as is for the moment? Ed. Well I tried the patch here and got a segfault on search. Here is the backtrace: (gdb) bt #0 0x401b2a21 in __kill () from /lib/libc.so.6 #1 0x401b2799 in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x401b3e04 in abort () at ../sysdeps/generic/abort.c:88 #3 0x817d4e7 in lyx::abort () at abort.C:9 #4 0x817fdb3 in lyxstring::operator[] (this=0xb548, pos=4) at LAssert.h:24 #5 0x80aed90 in IsStringInText (par=0x82eaba0, pos=7, str=@0xb548, cs=@0xb546, mw=@0xb547) at /usr/include/ctype.h:176 #6 0x80aef7c in SearchForward (bv=0x828da78, str=@0xb548, cs=@0xb546, mw=@0xb547) at lyxfind.C:154 #7 0x80aecb9 in LyXFind (bv=0x828da78, searchstr=@0xb548, casesens=@0xb546, matchwrd=@0xb547, forward=@0xb57c) at lyxfind.C:93 #8 0x816a1ae in FormSearch::Find (this=0x8293b70, next=true) at FormSearch.C:93 #9 0x816a0db in FormSearch::input (this=0x8293b70, obj=0x82cb5d0) at FormSearch.C:80 #10 0x8178810 in FormBase::InputCB (ob=0x82cb5d0, data=0) at FormBase.C:181 #11 0x8178065 in C_FormBaseInputCB (ob=0x82cb5d0, d=0) at FormBase.C:44 #12 0x819224f in fl_object_qread () at ../sigc++/slot.h:111 #13 0x8190ee9 in fl_check_forms () at ../sigc++/slot.h:111 #14 0x8137f18 in GUIRunTime::runTime () at GUIRunTime.C:79 #15 0x80a7570 in LyXGUI::runTime (this=0x8261d80) at lyx_gui.C:312 #16 0x80a873c in LyX::LyX (this=0xb730, argc=0xb770, argv=0xb7d4) at ../src/lyx_main.C:168 #17 0x80c0558 in main (argc=1, argv=0xb7d4) at ../src/main.C:40 #18 0x401a1b5c in __libc_start_main (main=0x80c0488 main, argc=1, ubp_av=0xb7d4, init=0x804d564 _init, fini=0x8200e38 _fini, rtld_fini=0x4000d634 _dl_fini, stack_end=0xb7cc) at ../sysdeps/generic/libc-start.c:129 I can reproduce this as often as I want. I just have to press 2 or 3 times the "" button with the same searchstring then I'll get this! Jrgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The San Diego Freeway. Official Parking Lot of the 1984 Olympics!
Re: findreplace patch
Well I tried the patch here and got a segfault on search.
Here is the backtrace:
I can reproduce this as often as I want. I just have to press 2 or 3
times the "" button with the same searchstring then I'll get this!
That's strange. I don't have this.
Apparantly (correct me if I'm wrong) it happens in IsStringInText() when it
uses lyxstring::operator[].
Which would mean that it happens here:
while (pos + i par-Last()
string::size_type(i) size
cs ? str[i] == par-GetChar(pos + i)
: toupper(str[i]) == toupper(par-GetChar(pos + i))) {
before it was like this:
while (pos + i par-Last()
string::size_type(i) size
str[i] == par-GetChar(pos + i) ) {
I am not doing anything funky or am I? Is this string trouble?
Can someone confirm Jurgens report? As I said, over here it functions fine
and the only way I can get it to crash is to throw my computer out of the
window :)
gr.ed.
Re: another patch...
On Mon, Mar 05, 2001 at 03:28:11PM +0100, Jean-Marc Lasgouttes wrote: "Jean-Marc" == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc I tried the "benchmark" a bit here, and the times in Jean-Marc successive rune fluctuate enough that I do not see how you Jean-Marc can interpret them... Something like time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx seems to give more consistent results across runs But this will not time the rendering pipeline (spiting the text to rows etc.) which is the part that causes the slowdown (I think).
FormParagraph question
Jrgen,
I was browsing through FormParagraph and I've come across something that
confuses me. Do you really mean to "activate" the lines below that I've
highlighted with a "?", or should they be "deactivate"?
The reason I ask is because I have a little helper function that I thought
would simplify the source considerably.
void setEnabled(FL_OBJECT * ob, bool enable)
{
if (enable) {
fl_activate_object(ob);
fl_set_object_lcol(ob, FL_BLACK);
} else {
fl_deactivate_object(ob);
fl_set_object_lcol(ob, FL_INACTIVE);
}
}
Angus
bool FormParagraph::input(FL_OBJECT * ob, long)
{
...
} else if (ob == extra_-radio_pextra_minipage) {
int n = fl_get_button(extra_-radio_pextra_minipage);
if (n) {
fl_set_button(extra_-radio_pextra_indent, 0);
fl_set_button(extra_-radio_pextra_floatflt, 0);
fl_activate_object(extra_-input_pextra_width);
fl_set_object_lcol(extra_-input_pextra_width, FL_BLACK);
fl_activate_object(extra_-input_pextra_widthp);
fl_set_object_lcol(extra_-input_pextra_widthp, FL_BLACK);
fl_activate_object(extra_-radio_pextra_top);
fl_set_object_lcol(extra_-radio_pextra_top, FL_BLACK);
fl_activate_object(extra_-radio_pextra_middle);
fl_set_object_lcol(extra_-radio_pextra_middle, FL_BLACK);
fl_activate_object(extra_-radio_pextra_bottom);
fl_set_object_lcol(extra_-radio_pextra_bottom, FL_BLACK);
fl_activate_object(extra_-radio_pextra_hfill);
fl_set_object_lcol(extra_-radio_pextra_hfill, FL_BLACK);
fl_activate_object(extra_-radio_pextra_startmp);
fl_set_object_lcol(extra_-radio_pextra_startmp, FL_BLACK);
} else {
fl_deactivate_object(extra_-input_pextra_width);
fl_set_object_lcol(extra_-input_pextra_width, FL_INACTIVE);
fl_deactivate_object(extra_-input_pextra_widthp);
fl_set_object_lcol(extra_-input_pextra_widthp, FL_INACTIVE);
fl_deactivate_object(extra_-radio_pextra_top);
fl_set_object_lcol(extra_-radio_pextra_top, FL_INACTIVE);
fl_deactivate_object(extra_-radio_pextra_middle);
fl_set_object_lcol(extra_-radio_pextra_middle, FL_INACTIVE);
fl_deactivate_object(extra_-radio_pextra_bottom);
fl_set_object_lcol(extra_-radio_pextra_bottom, FL_INACTIVE);
? fl_activate_object(extra_-radio_pextra_hfill);
fl_set_object_lcol(extra_-radio_pextra_hfill, FL_INACTIVE);
? fl_activate_object(extra_-radio_pextra_startmp);
fl_set_object_lcol(extra_-radio_pextra_startmp, FL_INACTIVE);
}
} else if (ob == extra_-radio_pextra_floatflt) {
int n = fl_get_button(extra_-radio_pextra_floatflt);
if (n) {
fl_set_button(extra_-radio_pextra_indent, 0);
fl_set_button(extra_-radio_pextra_minipage, 0);
fl_activate_object(extra_-input_pextra_width);
fl_set_object_lcol(extra_-input_pextra_width, FL_BLACK);
fl_activate_object(extra_-input_pextra_widthp);
fl_set_object_lcol(extra_-input_pextra_widthp, FL_BLACK);
} else {
fl_deactivate_object(extra_-input_pextra_width);
fl_set_object_lcol(extra_-input_pextra_width, FL_INACTIVE);
fl_deactivate_object(extra_-input_pextra_widthp);
fl_set_object_lcol(extra_-input_pextra_widthp, FL_INACTIVE);
}
fl_deactivate_object(extra_-radio_pextra_top);
fl_set_object_lcol(extra_-radio_pextra_top, FL_INACTIVE);
fl_deactivate_object(extra_-radio_pextra_middle);
fl_set_object_lcol(extra_-radio_pextra_middle, FL_INACTIVE);
fl_deactivate_object(extra_-radio_pextra_bottom);
fl_set_object_lcol(extra_-radio_pextra_bottom, FL_INACTIVE);
? fl_activate_object(extra_-radio_pextra_hfill);
fl_set_object_lcol(extra_-radio_pextra_hfill, FL_INACTIVE);
? fl_activate_object(extra_-radio_pextra_startmp);
fl_set_object_lcol(extra_-radio_pextra_startmp, FL_INACTIVE);
}
final patch (ShareContainer)
Ok, I have removed the ShareContainer from LyXFont and use it on LyXParagraph::FontTable::font instead. I am not sure if ShareContainer is optimal yet, probably not. Last test said: time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.l yx About to handle -x 'lyx-quit' real0m7.264s user0m4.510s sys 0m0.070s Lgb one more
Re: another patch...
Regarding improving the performance: I can only recommend using gprof. It's very easy, and it really helps when you want to find and address bottlenecks. Also, I must confess that it was me that introduced the ugly integer packed representation of the font information a long time ago. That was done because profiling showed it to be a huge gain, and at that point in time, it did in fact help. I understand that the structure is different today, so hopefully you won't have to revert to such a scheme again. Greets, Asger
Re: another patch...
On 5 Mar 2001, Jean-Marc Lasgouttes wrote: I tried the "benchmark" a bit here, and the times in successive rune fluctuate enough that I do not see how you can interpret them... This wins the "Cool Typo" award. When reading your (the developers') discussions of compilers, pragmas, etc. my head spins enough that you may as well be benchmarking in "successive runes", because I am certain that you are practicing spells and engaged in the black arts. Maybe it's time to support Peter Wilson's excellent archaic fonts, e.g. ctan:/tex-archive/fonts/archaic/runic. :-) Happy Monday! Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: ERT inset long rumored
On Mon, Mar 05, 2001 at 01:03:15PM +0100, Jean-Marc Lasgouttes wrote: Just type "M-x ert-insert". You can have a personal binding for it, or add it to your menus (for example insert) by adding in defaults.ui a line like Item "ERT" "ert-insert" Sweet! Thanks.
Re: FormParagraph question
On Mon, 5 Mar 2001, Angus Leeming wrote: Jrgen, I was browsing through FormParagraph and I've come across something that confuses me. Do you really mean to "activate" the lines below that I've highlighted with a "?", or should they be "deactivate"? Possibly wrong. Although the handling within FormParagraph is peculiar because there are chunks of widgets that get activated or deactivated by radio buttons. This is where the stuff I was working on to extend ButtonController and RadioButtonGroup come in. I should try to get it running soon (hopefully this weekend I might be able to do something other than build W2k images/boxes for the Uni). Allan.
RE: shared paragraph parameters patch
On 03-Mar-2001 Lars Gullik Bjønnes wrote: > > Comments? > (I think some small mathed stuff sneaked in...) Well and you had THOUGHTS about the small move of LyxFunc::Functions over to BufferView!? ;) I think it's a good move, cleans up some stuff! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Totally illogical, there was no chance. -- Spock, "The Galileo Seven", stardate 2822.3
Re: Serbo-Croatian support in LyX
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: >> But if we read a latex file (through reLyX) using one of these >> encoding, we need to understand it, right? Dekel> You can always change the encoding of a file using an external Dekel> program (e.g. recode) so this should not be a problem. Yes, but having LyX support the encoding seems much simpler to me. Why do you think this will be a problem? JMarc
Re: shared paragraph parameters patch
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> The problem is that these methods have to be "handwritten" Lars> anyway, they can't be operators since not all the members of the Lars> ParameterStruct participate in set setting or comparison. And could these members be partitionned into several substructs, depending on whether we want to copy them or not. OK, I have not re-read the code, so I do not really know what I am talking about, so... JMarc
findreplace patch
Hi, I attach the patch that moves find/replace to frontends. It also moves some stuff out ouf LyXText. The files src/lyxfr1.[Ch] and src/lyxfr0.[Ch] can be removed. Could someone check and/or apply it? Thanks for your help. Greetings, Ed. ps. could someone apply the qt2 character patch? http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg19935.html findreplace.diff.gz
mathed39.diff
This splits MathedRowSt into the "real" structure holding the actual data
and the "list" part. The idea is do replace the list part with std::list<> or
std::vector later. Having proper assignment could help in the Dark Parts...
Andre'
--
André Pönitz [EMAIL PROTECTED]
Index: math_rowst.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_rowst.h,v
retrieving revision 1.2
diff -u -p -r1.2 math_rowst.h
--- math_rowst.h2001/02/16 09:25:43 1.2
+++ math_rowst.h2001/03/05 09:31:58
@@ -8,7 +8,8 @@
It allows to manage the extra info independently of the paragraph data.
Only used for multiline paragraphs.
*/
-class MathedRowSt
+
+class MathedRowStruct
{
public:
///
@@ -16,14 +17,10 @@ public:
///
explicit
- MathedRowSt(int n)
+ MathedRowStruct(int n)
: asc_(0), desc_(0), y_(0), widths_(n + 1, 0),
- numbered_(true), next_(0)
+ numbered_(true)
{}
- /// Should be const but...
- MathedRowSt * getNext() const;
- /// ...we couldn't use this.
- void setNext(MathedRowSt * n);
///
string const & getLabel() const;
///
@@ -48,7 +45,9 @@ public:
void setNumbered(bool nf);
///
void setTab(int i, int t);
-private:
+ ///
+ friend class MathedRowSt;
+protected:
/// Vericals
int asc_;
///
@@ -61,6 +60,19 @@ private:
string label_;
///
bool numbered_;
+};
+
+class MathedRowSt : public MathedRowStruct {
+public:
+ ///
+ explicit MathedRowSt(int n)
+ : MathedRowStruct(n), next_(0)
+ {}
+ /// Should be const but...
+ MathedRowSt * getNext() const;
+ /// ...we couldn't use this.
+ void setNext(MathedRowSt * n);
+private:
///
MathedRowSt * next_;
};
@@ -81,84 +93,84 @@ void MathedRowSt::setNext(MathedRowSt *
inline
-string const & MathedRowSt::getLabel() const
+string const & MathedRowStruct::getLabel() const
{
return label_;
}
inline
-bool MathedRowSt::isNumbered() const
+bool MathedRowStruct::isNumbered() const
{
return numbered_;
}
inline
-int MathedRowSt::getBaseline() const
+int MathedRowStruct::getBaseline() const
{
return y_;
}
inline
-void MathedRowSt::setBaseline(int b)
+void MathedRowStruct::setBaseline(int b)
{
y_ = b;
}
inline
-int MathedRowSt::ascent() const
+int MathedRowStruct::ascent() const
{
return asc_;
}
inline
-int MathedRowSt::descent() const
+int MathedRowStruct::descent() const
{
return desc_;
}
inline
-void MathedRowSt::ascent(int a)
+void MathedRowStruct::ascent(int a)
{
asc_ = a;
}
inline
-void MathedRowSt::descent(int d)
+void MathedRowStruct::descent(int d)
{
desc_ = d;
}
inline
-int MathedRowSt::getTab(int i) const
+int MathedRowStruct::getTab(int i) const
{
return widths_[i];
}
inline
-void MathedRowSt::setLabel(string const & l)
+void MathedRowStruct::setLabel(string const & l)
{
label_ = l;
}
inline
-void MathedRowSt::setNumbered(bool nf)
+void MathedRowStruct::setNumbered(bool nf)
{
numbered_ = nf;
}
inline
-void MathedRowSt::setTab(int i, int t)
+void MathedRowStruct::setTab(int i, int t)
{
widths_[i] = t;
}
Re: mvc patch
On Saturday 03 March 2001 09:43, Lars Gullik Bjønnes wrote: Use this if you want to. Content-Type: text/x-patch; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description: use scoped_ptr + some other small things Many thanks, Lars. I'm looking at it now. I have a #pragma question for you. I don't use g++, so don't know anything about them. Anyway, in the patch you have (see bottom). Is this a general rule? Ie, move system header files before the #pragma directive and local header files after it? Angus Index: src/frontends/xforms/Color.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/Color.C,v retrieving revision 1.5 diff -u -p -r1.5 Color.C --- src/frontends/xforms/Color.C2000/11/21 15:46:10 1.5 +++ src/frontends/xforms/Color.C2001/03/03 09:32:04 @@ -10,14 +10,16 @@ *==*/ #include + +#include // max +#include // floor + #include FORMS_H_LOCATION #ifdef __GNUG_ #pragma implementation #endif -#include // max -#include // floor #include "Color.h"
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote: | > | > | > This patch includes the previous one and adds the same memore saving | > as with the paragraph parameters, but now also for LyXFont. | > | > It raises binary size a bit more than I would like, but the memory | > footprint for Userguide is now ~500 Kb. | > | > Comments? | | With the new patch, the Userguide loads very slowly: ~18 sec | while with the old code (or the old patch) the UG loads in ~7sec | (timed with 'time lyx -x lyx-quit UserGuide.lyx'). Yes, I see the same here. So we have to decide if this is a slow down that we can live with. (on the cell phone the numbers above came out as 218 and 27 and I got really worried...) btw. by also having language in fontbits we can save 4 bytes more for each LyXFont in use. This brings the size of LyXFont down from 44 bytes to 8 bytes. Lgb
Re: Inset include behaviour.
Andre Poenitz <[EMAIL PROTECTED]> writes: | > When you have 512 MB that is not a problem. ;-) | | Does LyX still compile with just 512 MB? I mean, taking under an hour or | so? I really don't have any recent evidence... Sure it does. ~18 minutes on PIII 700 with 128 Mb (gcc 2.96, 2.95 should be faster, 3.0 is slower, but that is probably due to the conforming c++ lib gcc people is working on this.) Lgb
Re: shared paragraph parameters patch
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 03-Mar-2001 Lars Gullik Bjønnes wrote: | > | > Comments? | > (I think some small mathed stuff sneaked in...) | | Well and you had THOUGHTS about the small move of LyxFunc::Functions over | to BufferView!? ;) Yes, but the plan was to clean it up in the process... Lgb
Re: mvc patch
Angus Leeming <[EMAIL PROTECTED]> writes: | On Saturday 03 March 2001 09:43, Lars Gullik Bjønnes wrote: | Use this if you want to. | | Content-Type: text/x-patch; name="Attachment: 1" | Content-Transfer-Encoding: 7bit | Content-Description: use scoped_ptr + some other small things | | | | Many thanks, Lars. I'm looking at it now. | | I have a #pragma question for you. I don't use g++, so don't know anything | about them. Anyway, in the patch you have (see bottom). | | Is this a general rule? Ie, move system header files before the #pragma | directive and local header files after it? No, not really. #pragma interface can be placed wherever you want to. #pragma implementation must be place in before the include that it corresponds to. but I like to separate system headers from local headers... Lgb
Re: shared paragraph parameters patch
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> The problem is that these methods have to be "handwritten" | Lars> anyway, they can't be operators since not all the members of the | Lars> ParameterStruct participate in set setting or comparison. | | And could these members be partitionned into several substructs, | depending on whether we want to copy them or not. OK, I have not | re-read the code, so I do not really know what I am talking about, | so... Perhaps... but some of the are up for deletion anyway (with new insets), so I don't really see the point in this. Lgb
Re: findreplace patch
On Monday 05 March 2001 09:36, Edwin Leuven wrote: > > Hi, > > ps. could someone apply the qt2 character patch? Ed, I thought I'd try and compile it, but configure fails because I have qt 2.2.1 here and configure looks for 2.2.3. Is this really needed or will I still be able to compile. from configure: #if (QT_VERSION < 223) break_me_(//); #endif Angus
Re: [PATCH] xforms small changes
John Levon <[EMAIL PROTECTED]> writes: | This should help the iconify situation in xforms. | It also fixes a qt2 compile problem, changes Splash, | and removes the DEFAULT_LANGUAGE thing in docdlg.C Have this been comitted? Lgb
Re: another patch...
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Yes, I see the same here. So we have to decide if this is a slow Lars> down that we can live with. (on the cell phone the numbers above Lars> came out as 218 and 27 and I got really worried...) Where does the slowdown come from? The ShareContainer::get method? Concerning this ShareContainer template, an obvious question: isn't there a better container than vector for this kind of stuff (a map?). Or could we order the contents of the container so that the most requested items come first? All in all, the patch looks nice, but the slow down (especially on UserGuide.lyx, which is a useful file in its own right) is a problem... JMarc
Re: another patch...
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Yes, I see the same here. So we have to decide if this is a slow | Lars> down that we can live with. (on the cell phone the numbers above | Lars> came out as 218 and 27 and I got really worried...) | | Where does the slowdown come from? The ShareContainer::get method? | Concerning this ShareContainer template, an obvious question: isn't | there a better container than vector for this kind of stuff (a map?). | Or could we order the contents of the container so that the most | requested items come first? A map is not very good since we don't have a obvious key (for the same reason a hash_map would be hard to use since a hash function would be hard to get fast/right/uniue). I agree that the linear search is not good. (and this is what causes the slowdown I belive, (also that we clean the container very often)) Prefferably the clean should be moved into the get, but I am a bit afraid that this can cause wrong behaviour, I have to think a bit more on that. Lgb
Re: [PATCH] xforms small changes
On Monday 05 March 2001 10:25, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | This should help the iconify situation in xforms. > | It also fixes a qt2 compile problem, changes Splash, > | and removes the DEFAULT_LANGUAGE thing in docdlg.C > > Have this been comitted? I committed all but the Splash stuff; John is reworking that. Angus
Re: findreplace patch
On Monday 05 March 2001 10:21, Angus Leeming wrote: > On Monday 05 March 2001 09:36, Edwin Leuven wrote: > > > > Hi, > > > > ps. could someone apply the qt2 character patch? > > Ed, > > I thought I'd try and compile it, but configure fails because I have qt 2.2.1 > here and configure looks for 2.2.3. Is this really needed or will I still be > able to compile. > > from configure: > #if (QT_VERSION < 223) > break_me_(//); > #endif I see that Lars has beaten me to it and committed this patch. I'd just report that it compiles on my box, so I think the configure test should be changed to #if (QT_VERSION < 221) at least. One small point. Launching the copyright dialog, I see that the program is now called KLyX Angus
Re: findreplace patch
Angus Leeming <[EMAIL PROTECTED]> writes: | On Monday 05 March 2001 10:21, Angus Leeming wrote: | > On Monday 05 March 2001 09:36, Edwin Leuven wrote: | > | > > > Hi, | > > | > > ps. could someone apply the qt2 character patch? | > | > Ed, | > | > I thought I'd try and compile it, but configure fails because I have qt | 2.2.1 | > here and configure looks for 2.2.3. Is this really needed or will I still | be | > able to compile. | > | > from configure: | > #if (QT_VERSION < 223) | | > break_me_(//); | > #endif | | | I see that Lars has beaten me to it and committed this patch. I'd just report | that it compiles on my box, so I think the configure test should be changed | to #if (QT_VERSION < 221) at least. | | One small point. Launching the copyright dialog, I see that the program is | now called KLyX yes, remove that... Lgb
Re: mathed38.diff
> Can you redo this patch? It crashes slighly with what I had in my tree
> (that I just committed).
I attach a new diff.
Andre'
--
André Pönitz [EMAIL PROTECTED]
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/ChangeLog,v
retrieving revision 1.53
diff -u -p -r1.53 ChangeLog
--- ChangeLog 2001/03/05 10:18:36 1.53
+++ ChangeLog 2001/03/05 10:46:13
@@ -1,3 +1,10 @@
+
+2001-02-14 André Pönitz <[EMAIL PROTECTED]>
+ * math_macrotemplate.[Ch]:
+math_macro.C: move update() functionality to the macro
+
+ * math_rowst.h: split MathedRowSt into "data" and "list"
+
2001-03-01 Lars Gullik Bjønnes <[EMAIL PROTECTED]>
* math_macrotemplate.C (update): use MathMacro::getArg, and
Index: math_macro.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macro.C,v
retrieving revision 1.49
diff -u -p -r1.49 math_macro.C
--- math_macro.C2001/03/05 10:18:36 1.49
+++ math_macro.C2001/03/05 10:46:13
@@ -74,8 +74,8 @@ MathedInset * MathMacro::Clone()
void MathMacro::Metrics()
{
- if (args_.size() > 0)
- tmplate_->update(*this);
+ for (int i = 0; i < args_.size(); ++i)
+tmplate_->args_[i] = getArg(i);
tmplate_->SetStyle(size());
tmplate_->Metrics();
width = tmplate_->Width();
Index: math_macrotemplate.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.C,v
retrieving revision 1.12
diff -u -p -r1.12 math_macrotemplate.C
--- math_macrotemplate.C2001/03/05 10:18:36 1.12
+++ math_macrotemplate.C2001/03/05 10:46:13
@@ -116,14 +116,6 @@ void MathMacroTemplate::Metrics()
}
-void MathMacroTemplate::update(MathMacro const & macro)
-{
- for (int i = 0; i < nargs_; ++i) {
- args_[i] = macro.getArg(i);
- }
-}
-
-
void MathMacroTemplate::WriteDef(ostream & os, bool fragile)
{
os << "\n\\newcommand{\\" << name << "}";
@@ -158,6 +150,13 @@ MathParInset * MathMacroTemplate::getMac
} else
return 0;
}
+
+void MathMacroTemplate::setMacroPar(int i, MathedArray const & ar)
+{
+ if (i >= 0 && i < nargs_)
+ args_[i].setData(ar);
+}
+
void MathMacroTemplate::SetMacroFocus(int , int x, int y)
Index: math_macrotemplate.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_macrotemplate.h,v
retrieving revision 1.8
diff -u -p -r1.8 math_macrotemplate.h
--- math_macrotemplate.h2001/03/05 10:18:36 1.8
+++ math_macrotemplate.h2001/03/05 10:46:13
@@ -43,12 +43,11 @@ public:
///
MathParInset * getMacroPar(int) const;
///
+ void setMacroPar(int, MathedArray const &);
+ ///
void SetMacroFocus(int &, int, int);
///
void setEditMode(bool);
-
- /// Replace the appropriate arguments with a specific macro's data
- void update(MathMacro const & m);
private:
/// Are we in edit mode or not?
bool edit_;
Re: mvc patch
A! This one slipped through! Thanks, Lars. I commented out this line because I'm using xforms 0.89.0 or 0.88.1 here and I get a segfault when deleting a group of FL_OBJECTs such as the RadioButtonGroup here. The correct code is back in. Are you happy with the branch? Shall I make a patch against HEAD and submit? Angus Index: src/frontends/xforms/FormGraphics.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormGraphics.C,v retrieving revision 1.15.8.2 diff -u -p -r1.15.8.2 FormGraphics.C --- src/frontends/xforms/FormGraphics.C 2001/03/02 13:17:51 1.15.8.2 +++ src/frontends/xforms/FormGraphics.C 2001/03/03 09:32:31 @@ -56,6 +56,7 @@ FormGraphics::~FormGraphics() // Free the form. // delete dialog_; +#warning where is the dialog_ deleted? (Lgb) }
Re: findreplace patch
Edwin Leuven <[EMAIL PROTECTED]> writes: | Hi, | | I attach the patch that moves find/replace to frontends. It also moves some | stuff out ouf LyXText. The files src/lyxfr1.[Ch] and src/lyxfr0.[Ch] can be | removed. Could someone check and/or apply it? | | Thanks for your help. + bool const & casesens, peculiar spelling... wouldn't "caseness" be better? Lgb
Re: mvc patch
On Monday 05 March 2001 10:55, Angus Leeming wrote: Lars, I'll follow your lead and use scoped_ptrs for the remaining xforms/Form*.[Ch] files. Ie, FormGraphics.h FormPrint.h FormRef.h FormSplash.h FormTabular.h FormTabularCreate.h FormToc.h FormUrl.h Angus
Re: Inset include behaviour.
On 5 Mar 2001, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | > When you have 512 MB that is not a problem. ;-) > | > | Does LyX still compile with just 512 MB? I mean, taking under an hour or > | so? I really don't have any recent evidence... > > Sure it does. ~18 minutes on PIII 700 with 128 Mb > (gcc 2.96, 2.95 should be faster, 3.0 is slower, but that is probably > due to the conforming c++ lib gcc people is working on this.) > > Lgb > It only takes 3 or so hours for a full build with 2.91.66 (much faster than 2.95.2 and infinitely faster than gcc CVS of a acouple of months ago), on a P200 with 40Mb of memory. Times are cut down a lot by cutting out -g and -O, and replacing the final collect2 with ld. CVS gcc was unusable on that machine but as Lgb says they are working on that ... john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: findreplace patch
On Mon, 5 Mar 2001, Angus Leeming wrote: > I see that Lars has beaten me to it and committed this patch. I'd just report > that it compiles on my box, so I think the configure test should be changed > to #if (QT_VERSION < 221) at least. I changed this. Hmm. Ah yes ... I see what's gone on I think. I think that the uic for 2.2.1 wouldn't work for me. If it compiles fine otherwise, then yes, it should be backed down to 221 I did it just because 2.2.1 wasn't working, and 2.2.3 did ... I'll try it again when I have a moment thanks john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: findreplace patch
On Monday 05 March 2001 10:44, Lars Gullik Bjønnes wrote: > | One small point. Launching the copyright dialog, I see that the program is > | now called KLyX > > yes, remove that... Done. A
Re: Inset include behaviour.
> It only takes 3 or so hours for a full build with 2.91.66 (much faster > than 2.95.2 and infinitely faster than gcc CVS of a acouple of months > ago), on a P200 with 40Mb of memory. So memory is the thing that really matters... as I mentioned it took me 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not scale very well above a certain level ;-} > Times are cut down a lot by cutting out -g and -O, and replacing the > final collect2 with ld. Do you have some automated way to do this? Andre' -- André Pönitz [EMAIL PROTECTED]
Re: Inset include behaviour.
On Mon, 5 Mar 2001, Andre Poenitz wrote: > > It only takes 3 or so hours for a full build with 2.91.66 (much faster > > than 2.95.2 and infinitely faster than gcc CVS of a acouple of months > > ago), on a P200 with 40Mb of memory. > > So memory is the thing that really matters... as I mentioned it took me > 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not > scale very well above a certain level ;-} I recommend using 2.91.66 instead, it is a lot less heavy on memory usage. > > > Times are cut down a lot by cutting out -g and -O, and replacing the > > final collect2 with ld. > > Do you have some automated way to do this? > no, I just had a little script ... john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: Inset include behaviour.
John Levon <[EMAIL PROTECTED]> writes: | On Mon, 5 Mar 2001, Andre Poenitz wrote: | | > > It only takes 3 or so hours for a full build with 2.91.66 (much faster | > > than 2.95.2 and infinitely faster than gcc CVS of a acouple of months | > > ago), on a P200 with 40Mb of memory. | > | > So memory is the thing that really matters... as I mentioned it took me | > 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not | > scale very well above a certain level ;-} | | I recommend using 2.91.66 instead, it is a lot less heavy on memory usage. And the C++ compiler is way behind... I prefere gcc 3.0, but usually use 2.96. Lgb
Re: mvc patch
Angus Leeming <[EMAIL PROTECTED]> writes: | On Monday 05 March 2001 10:55, Angus Leeming wrote: | | Lars, I'll follow your lead and use scoped_ptrs for the remaining | xforms/Form*.[Ch] files. Ie, | | FormGraphics.h | FormPrint.h | FormRef.h | FormSplash.h | FormTabular.h | FormTabularCreate.h | FormToc.h | FormUrl.h Ok, don't forget to commit to the branch when finished so that I can try it. Lgb
Re: Inset include behaviour.
On 5 Mar 2001, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Mon, 5 Mar 2001, Andre Poenitz wrote: > | > | > > It only takes 3 or so hours for a full build with 2.91.66 (much faster > | > > than 2.95.2 and infinitely faster than gcc CVS of a acouple of months > | > > ago), on a P200 with 40Mb of memory. > | > > | > So memory is the thing that really matters... as I mentioned it took me > | > 82 minutes with 2.95.2 on a P133 with 48 MB... Unfortunately, it does not > | > scale very well above a certain level ;-} > | > | I recommend using 2.91.66 instead, it is a lot less heavy on memory usage. > > And the C++ compiler is way behind... > > I prefere gcc 3.0, but usually use 2.96. > > Lgb > Well in an ideal world, but this version is literally unusable on a low memory machine when compiling LyX. As in, left-for-a-day-compiling-lyxfunc.C unusable. Hopefully the work they are doing now will sort it out to the only moderately slower 2.95.2 performance john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: [PATCH] 1.1.6 install patch
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> JMarc, here it is, with your suggestions. John> I've tested it, it seems ok I commit a slightly modified version of the patch where the default suffix is "-VERSION", so that the default behaviour is the nice one we had before, but it is possible to have any suffix. JMarc
Re: Inset include behaviour.
John Levon <[EMAIL PROTECTED]> writes: | Well in an ideal world, but this version is literally unusable on a low memory |machine | when compiling LyX. As in, left-for-a-day-compiling-lyxfunc.C unusable. | | Hopefully the work they are doing now will sort it out to the only moderately | slower 2.95.2 performance I suspect that the move of parts of lyxfunc to bufferview has made things a bit better. Lgb
Re: [PATCH] 1.1.6 install patch
On 5 Mar 2001, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> JMarc, here it is, with your suggestions. > > John> I've tested it, it seems ok > > I commit a slightly modified version of the patch where the default > suffix is "-VERSION", so that the default behaviour is the nice one we > had before, but it is possible to have any suffix. > > JMarc Can you apply the 1.2.0 update one too, obviously with your small change as well ? thanks john -- "History is the slaughter-bench at which the happiness of peoples, the wisdom of states and the virtue of individuals have been sacrificed." - Hegel
Re: [PATCH] 1.1.6 install patch
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Can you apply the 1.2.0 update one too, obviously with your John> small change as well ? I am currently doing that. Concerning the reLyX issue I see a solution, which is to export a variable like VERSION suffix that the reLyX configure will read. However, I tend to think that we should remove the reLyX configure script altogether, since we will certainly never want to update reLyX independently from LyX (this was the initial reason). However, this is small stuff which can wait. JMarc
Re: ERT inset long rumored
> "larry" == larry <[EMAIL PROTECTED]> writes: larry> Just following up on the long-rumored ERT inset. After some larry> minor commotion and even a lead LDN story about this a few larry> months ago, I haven't heard anything. larry> Is it true that there is support for the inset today, larry> accessible by typing a command by hand in the control window? larry> How is this done? Just type "M-x ert-insert". You can have a personal binding for it, or add it to your menus (for example insert) by adding in defaults.ui a line like Item "ERT" "ert-insert" larry> What is the status of efforts to bring more formal, menu-based larry> support into 1.2cvs? Not sure yet. JMarc
Re: ERT inset long rumored
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "larry" == larry <[EMAIL PROTECTED]> writes: | | larry> Just following up on the long-rumored ERT inset. After some | larry> minor commotion and even a lead LDN story about this a few | larry> months ago, I haven't heard anything. | | larry> Is it true that there is support for the inset today, | larry> accessible by typing a command by hand in the control window? | larry> How is this done? | | Just type "M-x ert-insert". You can have a personal binding for it, or | add it to your menus (for example insert) by adding in defaults.ui a | line like | | Item "ERT" "ert-insert" but remember that it is not officially supported yet... Lgb
Re: another patch...
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Yes, I see the same here. So we have to decide if this is a slow
> Lars> down that we can live with. (on the cell phone the numbers above
> Lars> came out as 218 and 27 and I got really worried...)
>
> Where does the slowdown come from? The ShareContainer::get method?
> Concerning this ShareContainer template, an obvious question: isn't
> there a better container than vector for this kind of stuff (a map?).
> Or could we order the contents of the container so that the most
> requested items come first?
The problem is that the data in a LyXText instance is changed frequently
(in the LyXParagraph::GetFont and LyXText::GetFont methods).
The solution is perhaps to keep the LyXFont class unchanged, but in
LyXParagraph::FontTable store a boost::shared_ptr
instead of a LyXFont.
> btw. by also having language in fontbits we can save 4 bytes more for
> each LyXFont in use. This brings the size of LyXFont down from 44
> bytes to 8 bytes.
Another option (without using shared_ptr) is to change the members in
FontBits to chars (i.e. struct FontBits { char family; char series; ...})
This is a bit ugly, but at least it will give a memory reduction, without a
slowdown.
Re: findreplace patch
> > + bool const & casesens, > > peculiar spelling... wouldn't "caseness" be better? > Whatever you want, I can also add "itive" to make it "casesensitive". You want a new patch, or is it ok as is for the moment? Ed.
Re: another patch...
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Yes, I see the same here. So we have to decide if this is a slow
| > Lars> down that we can live with. (on the cell phone the numbers above
| > Lars> came out as 218 and 27 and I got really worried...)
| >
| > Where does the slowdown come from? The ShareContainer::get method?
| > Concerning this ShareContainer template, an obvious question: isn't
| > there a better container than vector for this kind of stuff (a map?).
| > Or could we order the contents of the container so that the most
| > requested items come first?
|
| The problem is that the data in a LyXText instance is changed frequently
| (in the LyXParagraph::GetFont and LyXText::GetFont methods).
| The solution is perhaps to keep the LyXFont class unchanged, but in
| LyXParagraph::FontTable store a boost::shared_ptr
| instead of a LyXFont.
afaics it will be a lot harder then to localize the SharedContainer
(functionality that will be needed to really save anything.)
| > btw. by also having language in fontbits we can save 4 bytes more for
| > each LyXFont in use. This brings the size of LyXFont down from 44
| > bytes to 8 bytes.
|
| Another option (without using shared_ptr) is to change the members in
| FontBits to chars (i.e. struct FontBits { char family; char series; ...})
| This is a bit ugly, but at least it will give a memory reduction, without a
| slowdown.
Oh, we had that earlier, the code was close to impossible to maintain,
won't happen. and I'd hate to loose the type information. btw. clever
compilers are free to use a byte for most of those enums.
Lgb
