Re: 1.2.0 compilation report
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Thomas == Thomas Anders [EMAIL PROTECTED] writes: | Thomas Jean-Marc Lasgouttes wrote: Jean-Marc Lasgouttes wrote: Is | Thomas there a way around this? FWIW, linking also fails on a decent | Thomas Tru64 Unix 5.1A machine (ld 5.1 while 4.0D has ld 3.11). As I said, --with-included-string helps. | Thomas Has this changed recently? As reported for 1.2.0pre5 on | Thomas 2002-05-21, linking also failed with --with-included-string. | Thomas Okay, I will try again for 1.2.0 now. Sorry, I missed your message because I was away for some time. | Thomas Nevertheless I gave it a try again (Tru64 4.0D, gcc 3.1), but | Thomas it fails even worse: | Thomas .deps/lyxstring.TPlo lyxstring.C: In function `std::istream | Thomas operator(std::istream, lyxstring)': lyxstring.C:1764: no | Thomas matching function for call to `std::basic_istreamchar, | Thomas std::char_traitschar ::ipfx0()' lyxstring.C:1786: no | Thomas matching function for call to `std::basic_istreamchar, | Thomas std::char_traitschar ::isfx()' | Lars, would it be possible to get rid of these ipfx0() and isfx()? Yes, we then should use one of the functions Dekel had instead. Dekel do you still have them? | What are they good for? Making it work... they are both sentries and does the remove all whitespace before extracting stuff. | I thought we used to have a working | operator a few months ago? Well it just seemed to be ok... it had a serious bug. -- Lgb
Re: The complexity of GUI.h
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars The rest of the lines changed: | Lars 3615409 827848 52084 4495341 4497ed src/lyx | All of these are with gcc 3.2? Yes, it seems that the GC folks has a boo-boo that makes the binary overly large. But that is not what I am showing, it is the recudtion in size that matters. -- Lgb
Re: Speeding up file parsing
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | [Nothing] | Hmm, sending the patch but not the message is a new interesting thing | to do... I wonder why this happened. Here it is anyway. Seems ok to me. -- Lgb
Re: Speeding up file parsing
On Tue, May 28, 2002 at 07:18:22PM +0200, Jean-Marc Lasgouttes wrote: Of course, buffer loading is something as 20% of total time when the reformatingof paragraph takes place. This part is more difficult to improve, unless we have a working paragraph iterator which can cache current font. I still believe that we are handling fonts wrongly. We do it basically as every other word processor does whereas I think font changes should be represented by insets that just happen to display their contents a bit differently... I have a (largish) patch to make that change for mathed. Maybe I should just commit it and we can try to make it work smoothly and than we can can decide whether my believe is sound or not? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS compile failed: preview.h
On Tue, May 28, 2002 at 03:41:20PM -0700, Kayvan A. Sylvan wrote: g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../../boost -isystem +/usr/X11R6/include -O2 -m486 -fno-strength-reduce -W -Wall -c formula.C +-Wp,-MD,.deps/formula.TPlo formula.C:45: preview.h: No such file or directory but this file _is_ in CVS. Well, cvs log preview.h gives: Working file: preview.h head: 1.1 branch: locks: strict access list: symbolic names: MERGE_1_TO_GUII: 1.1 keyword substitution: kv total revisions: 1; selected revisions: 1 description: revision 1.1 date: 2002/05/28 11:13:01; author: poenitz; state: Exp; add missing using's start with 'preview' (not activated) I am not sure what this says, but it looks as CVS knows about the file... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: WorkArea
John Levon [EMAIL PROTECTED] writes: | So I take it my only chance to get WorkArea accepted is to make it a | pimpl ? No what about split implementation similar to Dialogs.h Dialogs.C and xforms/Dialogs.C? You only have to explore the different possibilities a bit, and do a real argument for the one that seems to be best. -- Lgb
Re: Failed to follow CVS docs ...
John Levon [EMAIL PROTECTED] writes: | Well I read both documents, and they both say that : | cvs rtag MERGE_1_TO_GUII lyx-devel (in HEAD) | cvs update -j BRANCH_POINT_GUII -j MERGE_1_TO_GUII lyx-devel (in branch) | should work for the first merge. I get : | cvs [server aborted]: no such tag MERGE_1_TO_GUII Hmm... cvs log -r MERGE_1_TO_GUII configure.in works So, no, I have no ideas. -- Lgb
Re: graphics stuff continued
Andre Poenitz [EMAIL PROTECTED] writes: | On Tue, May 28, 2002 at 01:00:09PM +0100, Angus Leeming wrote: Unrelated question: Why are there boost::shared_ptr al over the place? Sort of 'pimpl'? Where. I don't have the source to hand remember. | | /// The cache contains data of this type. | typedef boost::shared_ptrGCacheItem CacheItemType; | /** The cache contains one item per file, so use a map to find the |* cache item quickly by filename. |* Note that each cache item can have multiple views, potentially one |* per inset that references the original file. |*/ | typedef std::mapstring, CacheItemType CacheType; Next question: Why is GCacheItem derived from SigC::Object? Shouldn't it rather have signals as members? Because the graphics converter emits a signal when the file is converted to a loadable format. We want to know when to load it don't we? | Ok. I probably just don't understand the significance of being an | SigC::Object. | Being an SigC::Object means I can receive signals? One or any number? | [How does this relate to the boost signals (of which I read | something _very_ recently...;-}] boost::trackable is the equivalent of SigC::Object. Have a look at the signals.patch that I posted some days ago. -- Lgb
Re: [PATCH]: trivial fix for bug #415.
Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | On Wed, 22 May 2002, Lars Gullik Bjønnes wrote: Boost signals however delegates creation of functions objects and binding to two other libs, with sigc++ this is integrated in the signal/slot code. | Not quite as nice then. What is not quite as nice? I'd argue that SigC is not as nice, since it mixes idoms. boost::signals has them separated so that you can both change the bining lib without telling boost::signals, and the same with the boost::function lib (library for delayed calling of functions). Am I correct in beliving that gtkmm cannot exist without sigc++, and that if gtkmm is installed then a libsigc++ will also be installed? (so we won't have to provide sigc++ with lyx as we do now) | Now that libsigc++ is more wide spread (ie. when it was included few | major distros had a useful version of it) I want to remove it from the | dist -- whether we require it for all signals or just for the gtk | stuff. It seems to not be disted with RH. What about other platforms? DEC, Sun, ... -- [EMAIL PROTECTED] | beusen Solutions GmbH fon: +49 30 549932-426 | Landsberger Allee 366 fax: +49 30 549932-921 | 12681 Berlin, Germany
Re: CVS compile failed: preview.h
On Wed, May 29, 2002 at 09:48:47AM +0100, Angus Leeming wrote: I think that this means that the file is not in Makefile.am. Bingo. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: WorkArea
On Wed, May 29, 2002 at 09:50:36AM +0200, Lars Gullik Bjønnes wrote: No what about split implementation similar to Dialogs.h Dialogs.C and xforms/Dialogs.C? There is no Dialogs.C there is only xforms/Dialogs.C All you're asking for is pimpl with a slightly different layout, since xforms needs somewhere to put FL_OBJECT * scrollbar_ etc. So this suggestion is no different except there will be more duplicated code per-frontend You only have to explore the different possibilities a bit, and do a real argument for the one that seems to be best. I don't how to argue the obvious any further :( Have you actually /read/ the source yet ? Where does this go : /// FL_OBJECT * backgroundbox; /// FL_OBJECT * work_area; /// FL_OBJECT * scrollbar; where does this go : /// handles SelectionRequest X Event, to fill the clipboard int event_cb(XEvent * xev); where does this go : /// scroll bar QScrollBar * scrollbar_; /// content QContentPane * content_; You've nowhere to put it under your scheme with out introducing a pimpl And you've still yet to describe the elusive benefits of such a design. Well ? john -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
Re: Could someone try out lyxserver?
On Wed, May 29, 2002 at 01:24:05PM +0200, Jean-Marc Lasgouttes wrote: I commited yesterday a patch to lyxserver for fix a problem reported on the lyx-docs (why?) list, which was basically that it did not work with sixpack. Why did it break ? I tested it the last time I broke lyxserver (with gbib I think) john -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
Re: WorkArea
John Levon [EMAIL PROTECTED] writes:
| On Wed, May 29, 2002 at 09:50:36AM +0200, Lars Gullik Bjønnes wrote:
No what about split implementation similar to Dialogs.h Dialogs.C
and xforms/Dialogs.C?
| There is no Dialogs.C there is only xforms/Dialogs.C
frontends/Dialogs.C is there.
| All you're asking for is pimpl with a slightly different layout, since
| xforms needs somewhere to put FL_OBJECT * scrollbar_ etc.
| So this suggestion is no different except there will be more duplicated
| code per-frontend
You only have to explore the different possibilities a bit, and do a
real argument for the one that seems to be best.
| I don't how to argue the obvious any further :(
| Have you actually /read/ the source yet ? Where does this go :
| ///
| FL_OBJECT * backgroundbox;
| ///
| FL_OBJECT * work_area;
| ///
| FL_OBJECT * scrollbar;
| where does this go :
| /// handles SelectionRequest X Event, to fill the clipboard
| int event_cb(XEvent * xev);
| where does this go :
| /// scroll bar
| QScrollBar * scrollbar_;
| /// content
| QContentPane * content_;
| You've nowhere to put it under your scheme with out introducing a pimpl
Unless you do a
stuct workarea_traits {};
template class WorkTraits
class WorkArea {
private:
WorkTraits worktraits;
};
| And you've still yet to describe the elusive benefits of such a
| design. Well ?
As said I want to explore the possibilities.
--
Lgb
Re: WorkArea
On Wed, May 29, 2002 at 01:29:22PM +0200, Lars Gullik Bjønnes wrote:
| There is no Dialogs.C there is only xforms/Dialogs.C
frontends/Dialogs.C is there.
oops oh yes. I see, you want to split a single class over two C files.
OK
| You've nowhere to put it under your scheme with out introducing a pimpl
Unless you do a
stuct workarea_traits {};
template class WorkTraits
class WorkArea {
private:
WorkTraits worktraits;
};
Hmm, that's perhaps a bit better. It certainly avoids the raw :
Pimpl * pimpl_;
that would be needed otherwise. Hmm, but wouldn't this still leave us
the same problem concerning toolkit headers ?
Namely how does the core code refer to / construct an actual workarea
instance without getting incestuous with the frontends ?
| And you've still yet to describe the elusive benefits of such a
| design. Well ?
As said I want to explore the possibilities.
Sure ... I'm just blustering ...
(And a bit worried I can't merge changes to the branch :)
john
--
Time is a great teacher, but unfortunately it kills all its pupils.
- Hector Louis Berlioz
Re: Could someone try out lyxserver?
John == John Levon [EMAIL PROTECTED] writes: John On Wed, May 29, 2002 at 01:24:05PM +0200, Jean-Marc Lasgouttes John wrote: I commited yesterday a patch to lyxserver for fix a problem reported on the lyx-docs (why?) list, which was basically that it did not work with sixpack. John Why did it break ? I tested it the last time I broke lyxserver John (with gbib I think) I think I broke it when I introduced the LyXFuncc::verboseDispatch stuff (in december/january). Anyway, I think the current code is cleaner than before, provided that it works :) Can you try it? JMarc
Re: WorkArea
On Wednesday 29 May 2002 12:39 pm, John Levon wrote: (And a bit worried I can't merge changes to the branch :) You mean merge changes in the trunk into the branch? I found that following Lars' prescription worked perfectly for me with BRANCH_NATBIB. I think I kept a log; will dig it out and post it on. Angus
Re: WorkArea
On Wed, May 29, 2002 at 01:03:25PM +0100, Angus Leeming wrote: You mean merge changes in the trunk into the branch? I found that following Lars' prescription worked perfectly for me with BRANCH_NATBIB. I think I kept a log; will dig it out and post it on. Please do: I must be doing something stupid. thanks john -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
Re: WorkArea
On Wednesday 29 May 2002 1:22 pm, John Levon wrote: On Wed, May 29, 2002 at 01:03:25PM +0100, Angus Leeming wrote: You mean merge changes in the trunk into the branch? I found that following Lars' prescription worked perfectly for me with BRANCH_NATBIB. I think I kept a log; will dig it out and post it on. Please do: I must be doing something stupid. thanks john This prescription worked perfectly for me. I used to cut and paste the commands. Angus In detail with CVS commands: Step 1. Create your branch and tag the HEAD where it was made. Then check out a copy of your module that is on the branch. cvs rtag TAG_CREATE_branch name lyx-devel cvs rtag -b -r TAG_CREATE_branch name BRANCH_branch name lyx-devel cvs checkout -r BRANCH_branch name lyx-devel Step 2. Merge changes in the HEAD the first time. First tag the HEAD to establish a merge point. Then do the merge. cvs rtag TAG_HEAD_MERGE_TO_branch name lyx-devel cvs update -jHEAD Step 3. Correct conflicts and commit. After the commit, tag the branch. [Concurrency issue: This step assumes that no one is making changes on the branch from the time of the update in the past step to te cvs rtag operation in this one. If that cannot be assured, tag the working area instead of the repository (that is, use cvs tag instead of cvs rtag).] cvs rtag -r BRANCH_branch name TAG_branch name_MERGE_FROM_HEAD lyx-devel Step 4. Continue working on the branch until you want to merge in changes from the HEAD again. Step 5. Merge changes in the HEAD that occurred between your last merge and now. This is the important step to understand. Merge from the old tag on the HEAD to the present. cvs update -jTAG_HEAD_MERGE_TO_branch name -jHEAD Move the tag. The same concurrency issue from Step 3 applies here as well. cvs rtag -F TAG_HEAD_MERGE_TO_branch name lyx-devel Fix conflicts and commit. Update the tag on the branch: cvs rtag -F -r BRANCH_branch name TAG_branch name_MERGE_FROM_HEAD lyx-devel Step 6. If more work is to be done on the branch, go to step 4. Otherwise go to the next step. Step 7. When done with the branch, merge changes from the branch to the HEAD. cd to lyx-devel that is checked-out on HEAD (not BRANCH_branch name) cvs update -jBRANCH_branch name Step 8. Fix conflicts. You will likely see a lot of conflicts here that you dealt with already on the side branch. The second choice conflict is the one that came from the branch and usually is the one you want to choose. This should be straightforward. Fix all conflicts and commit. Advise others that the side branch is no longer to be used. Of course before we continue from step 6 a patch should be created that can be used for review of the changes. And if any changes are needed we should move to step 4 and do them and continue from there.
Re: Could someone try out lyxserver?
Jean-Marc Lasgouttes wrote: Can somebody with such a lyxserver-aware program tell me whether current 1.3.0cvs works? Pybliographer - LyX works here via pipe But it works with 1.2.0, too Regards, Juergen. JMarc
Re: WorkArea
On Wed, May 29, 2002 at 01:25:57PM +0100, Angus Leeming wrote: cvs rtag TAG_HEAD_MERGE_TO_branch name lyx-devel cvs update -jHEAD Ah, this is different from the instructions recently sent. This seems to be working. Step 5. Merge changes in the HEAD that occurred between your last merge and now. This is the important step to understand. Merge from the old tag on the HEAD to the present. cvs update -jTAG_HEAD_MERGE_TO_branch name -jHEAD Is this going to work now there's been changes between the tagging of HEAD and the cvs update on the branch ... john -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
[Patch] text.diff
Only white spaces and comment changes, but I thought I'd better ask, lest
somebody else is working in that area...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
? graphics/.GraphicsCache.h.swp
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.730
diff -u -p -r1.730 ChangeLog
--- ChangeLog 28 May 2002 23:04:56 - 1.730
+++ ChangeLog 29 May 2002 12:41:46 -
@@ -1,3 +1,10 @@
+
+2002-05-29 André Pönitz [EMAIL PROTECTED]
+
+ * text.C:
+ * sp_pspell.h:
+ * sp_ispell.h: whitespace change
+
2002-05-29 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* lyxserver.C (callback): tentative fix of lyxserver. Does not use
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.252
diff -u -p -r1.252 text.C
--- text.C 24 May 2002 14:34:26 - 1.252
+++ text.C 29 May 2002 12:41:47 -
@@ -215,8 +215,8 @@ int LyXText::singleWidth(BufferView * bv
return font_metrics::width(c, font);
} else if (IsHfillChar(c)) {
- return 3; /* Because of the representation
-* as vertical lines */
+ // Because of the representation as vertical lines
+ return 3;
} else if (c == Paragraph::META_INSET) {
Inset * tmpinset = par-getInset(pos);
if (tmpinset) {
@@ -951,12 +951,12 @@ int LyXText::labelEnd(BufferView * bview
Row tmprow;
tmprow = *row;
tmprow.pos(row-par()-size());
- return leftMargin(bview, tmprow); /* just the beginning
- of the main body */
- } else
- return 0; /* LabelEnd is only needed, if the
- layout fills a flushleft
- label. */
+ // just the beginning of the main body
+ return leftMargin(bview, tmprow);
+ } else {
+ // LabelEnd is only needed, if the layout fills a flushleft label.
+ return 0;
+ }
}
@@ -983,7 +983,7 @@ LyXText::nextBreakPoint(BufferView * bvi
pos_type i = pos;
if (layout.margintype == MARGIN_RIGHT_ADDRESS_BOX) {
- /* special code for right address boxes, only newlines count */
+ // special code for right address boxes, only newlines count
while (i par-size()) {
if (par-isNewline(i)) {
last_separator = i;
@@ -1153,8 +1153,8 @@ int LyXText::labelFill(BufferView * bvie
// environment with a manual label. (Asger)
if (last 0) last = 0;
- if (row-par()-isLineSeparator(last)) /* a sepearator at this end
- does not count */
+ // a separator at this end does not count
+ if (row-par()-isLineSeparator(last))
--last;
int w = 0;
@@ -1200,8 +1200,8 @@ int LyXText::numberOfHfills(Buffer const
pos_type const last = rowLast(row);
pos_type first = row-pos();
- if (first) { /* hfill *DO* count at the beginning
- * of paragraphs! */
+ if (first) {
+ // hfill *DO* count at the beginning of paragraphs!
while (first = last row-par()-isHfill(first)) {
++first;
}
@@ -1225,8 +1225,8 @@ int LyXText::numberOfLabelHfills(Buffer
{
pos_type last = rowLast(row);
pos_type first = row-pos();
- if (first) { /* hfill *DO* count at the beginning
- * of paragraphs! */
+ if (first) {
+ // hfill *DO* count at the beginning of paragraphs!
while (first last row-par()-isHfill(first))
++first;
}
@@ -1297,7 +1297,7 @@ LColor::color LyXText::backgroundColor()
void LyXText::setHeightOfRow(BufferView * bview, Row * row_ptr) const
{
- /* get the maximum ascent and the maximum descent */
+ // get the maximum ascent and the maximum descent
int asc = 0;
int desc = 0;
float layoutasc = 0;
@@ -1306,17 +1306,18 @@ void LyXText::setHeightOfRow(BufferView
LyXFont tmpfont;
Inset * tmpinset = 0;
- /* ok , let us initialize the maxasc and maxdesc value.
-* This depends in LaTeX of the font of the last character
-* in the paragraph. The hack below is necessary because
-* of the possibility of open footnotes */
+ // ok , let us initialize the maxasc and maxdesc value.
+ // This depends in LaTeX of the font of the last character
+ // in
Re: Could someone try out lyxserver?
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: Can somebody with such a lyxserver-aware program tell me whether current 1.3.0cvs works? Juergen Pybliographer - LyX works here via pipe But it works with Juergen 1.2.0, too Ahh, you mean I was too fast? ;) Could you test whether the current 1.3.0cvs code still work? It seems better to me, but... JMarc
Re: defaults
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen Jean-Marc Lasgouttes wrote: I _think_ the preamble is saved in there. It is a document property, after all. Juergen Well, I don't dare to argue against you, because you know the Juergen internals better than me ;-) It was you after all who created Juergen the function, while I only moved it into document. But Juergen actually, it seems not to be saved (at least my test did not Juergen save it). So is this a bug? It was a bug, and it is fixed now. And I think the preamble should be a new tab of the document layout popup. Juergen Agreed. I could even have a go if others don't object on Juergen this. The only problem that I see is that OK is the default button in this dialog, so that one will not be able to use Return in the preamble (which someone reduces its appeal :) JMarc
ChangeLog entry
On Wed, May 29, 2002 at 01:29:41PM +0100, John Levon wrote: Log message: remove unneeded #include and part of comment that's no in insets/ ChangeLogs ? :) Yesterday's entry still applies. Shall I duplicate that? Andre'
Re: lyx-devel src/graphics/: GraphicsImage.C GraphicsParams.h
On Wed, May 29, 2002 at 02:44:29PM +0200, Andre Poenitz wrote: Yesterday's entry still applies. Shall I duplicate that? Oh OK, sorry john -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
Re: WorkArea
On Wednesday 29 May 2002 1:33 pm, John Levon wrote: On Wed, May 29, 2002 at 01:25:57PM +0100, Angus Leeming wrote: cvs rtag TAG_HEAD_MERGE_TO_branch name lyx-devel cvs update -jHEAD Ah, this is different from the instructions recently sent. This seems to be working. Lars, shall I put your original (and working!) prescription into the repository as development/branches.html? Angus
Re: Could someone try out lyxserver?
Jean-Marc Lasgouttes wrote: Juergen Pybliographer - LyX works here via pipe But it works with Juergen 1.2.0, too Ahh, you mean I was too fast? ;) Could you test whether the current 1.3.0cvs code still work? It seems better to me, but... Yes, I have tested it with recent CVS (including your changes), too. It works AFAICS. The only thing is that you have to start pyblio after LyX. If I start LyX after pyblio, it complains about broken pipe (but that's in 1.2.0, too). Regards, Juergen.
Re: lyx-devel src/graphics/: GraphicsImage.C GraphicsParams.h
On Wed, May 29, 2002 at 01:47:07PM +0100, John Levon wrote: Yesterday's entry still applies. Shall I duplicate that? Oh OK, sorry No, that was a real question. How much trust put people in ChangeLog entries? I.e. do people think if there is no entry for dd.mm., nothing changed on that day? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: WorkArea
Angus Leeming [EMAIL PROTECTED] writes: | On Wednesday 29 May 2002 1:33 pm, John Levon wrote: On Wed, May 29, 2002 at 01:25:57PM +0100, Angus Leeming wrote: cvs rtag TAG_HEAD_MERGE_TO_branch name lyx-devel cvs update -jHEAD Ah, this is different from the instructions recently sent. This seems to be working. | Lars, shall I put your original (and working!) prescription into the | repository as development/branches.html? Yes, do that. -- Lgb
Re: [Patch] text.diff
Andre Poenitz [EMAIL PROTECTED] writes: | Only white spaces and comment changes, but I thought I'd better ask, lest | somebody else is working in that area... Fine with me. -- Lgb
Re: lyx-devel src/graphics/: GraphicsImage.C GraphicsParams.h
On Wed, May 29, 2002 at 02:54:28PM +0200, Andre Poenitz wrote: No, that was a real question. How much trust put people in ChangeLog entries? I.e. do people think if there is no entry for dd.mm., nothing changed on that day? How silly for them to think that :) i.e. I hope not. Sometimes changelogs get forgotten, and when does the day start/end anyway ? regards john -- Time is a great teacher, but unfortunately it kills all its pupils. - Hector Louis Berlioz
Re: lyx-devel src/graphics/: GraphicsImage.C GraphicsParams.h
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 01:47:07PM +0100, John Levon wrote: Yesterday's entry still applies. Shall I duplicate that? Oh OK, sorry | No, that was a real question. How much trust put people in ChangeLog | entries? I.e. do people think if there is no entry for dd.mm., | nothing changed on that day? Yes. You should duplicate. -- Lgb
Re: defaults
Jean-Marc Lasgouttes wrote: Juergen Well, I don't dare to argue against you, because you know the Juergen internals better than me ;-) It was you after all who created Juergen the function, while I only moved it into document. But Juergen actually, it seems not to be saved (at least my test did not Juergen save it). So is this a bug? It was a bug, and it is fixed now. Obviously it was (and me confused again :-) Thanks! And I think the preamble should be a new tab of the document layout popup. Juergen Agreed. I could even have a go if others don't object on Juergen this. The only problem that I see is that OK is the default button in this dialog, so that one will not be able to use Return in the preamble (which someone reduces its appeal :) I will have a look eventually and we'll see what happens. Anyway, I think Angus is about to mvc the document dialog, and I don't want to step on his toes. I'll probably wait for that. Juergen. JMarc
Re: lyx-devel src/graphics/: GraphicsImage.C GraphicsParams.h
On Wed, May 29, 2002 at 01:57:13PM +0100, John Levon wrote: ... and when does the day start/end anyway ? From dawn till dusk used to be a quite popular definition for some time... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Why is 1.2.0 not announced yet??
I think the subject says it all. I think that if we want something in tomorrow's lwn, for example, we should do it today. Lars? JMarc
BRANCH_GUII question?
John Brwosing through viewcvs, I see that LFUN_AUTOSAVE has disappeared from commandtags.h et al in BRANCH_GUII. Why? Regards, Angus
speedup buffer parsing by a factor of 3
This tranlates to 15% overall performance boost when simply loading the UserGuide? Not bad... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: speedup buffer parsing by a factor of 3
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre This tranlates to 15% overall performance boost when simply Andre loading the UserGuide? Andre Not bad... It should. Note that there is a lot of time needed to load the fonts from the X server that gprof does not take in account. I tried to install the gprof-aware libc packages, but I do not know how to use this. I mainly did it because it was so easy... It should be possible to win another 20% on rescaling with a simple hack (cache last font index in paragraph), but solving the real problem is more difficult. JMarc
Re: BRANCH_GUII question?
On Wed, May 29, 2002 at 03:45:34PM +0100, Angus Leeming wrote: Brwosing through viewcvs, I see that LFUN_AUTOSAVE has disappeared from commandtags.h et al in BRANCH_GUII. Why? Well two answers ... 1) I accidentally merged a non-GUII change 2) what use is LFUN_AUTOSAVE ? regards john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 04:53:56PM +0200, Jean-Marc Lasgouttes wrote: It should. Note that there is a lot of time needed to load the fonts from the X server that gprof does not take in account. I tried to install the gprof-aware libc packages, but I do not know how to use this. export LD_PROFILE=libX11.so ./lyx blah.lyx sprof libX11.so /var/tmp/*.profile should do it (unless your sprof has a bug, in which case you will need to use LD_PRELOAD to load the libraries libX11 depends upon first, otherwise sprof's dlopen() will fail). Of course, you'll need a profile version of libX11 regards john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: Why is 1.2.0 not announced yet??
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I think the subject says it all. I think that if we want something in | tomorrow's lwn, for example, we should do it today. | Lars? You you will do the announcement, be my guest! -- Lgb
Re: BRANCH_GUII question?
On Wednesday 29 May 2002 3:56 pm, John Levon wrote: On Wed, May 29, 2002 at 03:45:34PM +0100, Angus Leeming wrote: Brwosing through viewcvs, I see that LFUN_AUTOSAVE has disappeared from commandtags.h et al in BRANCH_GUII. Why? Well two answers ... 1) I accidentally merged a non-GUII change 2) what use is LFUN_AUTOSAVE ? Well don't we use it to save documents automatically every 5 mins or so? regards john
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 04:53:56PM +0200, Jean-Marc Lasgouttes wrote: It should. Note that there is a lot of time needed to load the fonts from the X server that gprof does not take in account. I tried to install the gprof-aware libc packages, but I do not know how to use this. LyXTextClass::operator[] is pretty expensive. I wonder if we should replace the layout vector by a map indexed by the layout name... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: speedup buffer parsing by a factor of 3
John == John Levon [EMAIL PROTECTED] writes: John On Wed, May 29, 2002 at 04:53:56PM +0200, Jean-Marc Lasgouttes John wrote: It should. Note that there is a lot of time needed to load the fonts from the X server that gprof does not take in account. I tried to install the gprof-aware libc packages, but I do not know how to use this. John export LD_PROFILE=libX11.so ./lyx blah.lyx sprof libX11.so John /var/tmp/*.profile John should do it (unless your sprof has a bug, in which case you John will need to use LD_PRELOAD to load the libraries libX11 depends John upon first, otherwise sprof's dlopen() will fail). John Of course, you'll need a profile version of libX11 I almost forgot you were our profiler guru :) This would be useful to actually profile libX11, no? All I want is see the time spent in loading fonts from the server. JMarc
Re: Why is 1.2.0 not announced yet??
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I think Lars the subject says it all. I think that if we want something in | Lars tomorrow's lwn, for example, we should do it today. Lars | Lars? Lars You you will do the announcement, be my guest! OK. John, you have an announcement somewhere, don't you? JMarc
Re: BRANCH_GUII question?
On Wed, May 29, 2002 at 04:01:02PM +0100, Angus Leeming wrote: Well don't we use it to save documents automatically every 5 mins or so? nope, we use autoSave / AutoSave regards john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: speedup buffer parsing by a factor of 3
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Wed, May 29, 2002 at 04:53:56PM +0200, Jean-Marc Lasgouttes
Andre wrote:
It should. Note that there is a lot of time needed to load the
fonts from the X server that gprof does not take in account. I
tried to install the gprof-aware libc packages, but I do not know
how to use this.
Andre LyXTextClass::operator[] is pretty expensive.
This is because of string comparisons which are done for the cached
value. I do not think we can go much faster, except if we used a
smarter operator== for strings (of course we can't, since we do not
have the right to use our own strings :).
Something like
bool operator==(string const s1, string const s2) {
return s1.size() == s2.size()
!strncmp(s1.data(), s2.data(), s1.size());
}
Or even checking whether s1.srep == s2.srep (it would be easy to have
most layout strings be shared instances).
Andre I wonder if we should replace the layout vector by a map
Andre indexed by the layout name...
I am under the impression that most of the time spent is in line 524:
if (name == lastLayoutName)
return layoutlist[lastLayoutIndex];
You can't be much faster than that, if this is really the bottleneck.
JMarc
Re: BRANCH_GUII question?
John Levon [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 03:45:34PM +0100, Angus Leeming wrote: Brwosing through viewcvs, I see that LFUN_AUTOSAVE has disappeared from commandtags.h et al in BRANCH_GUII. Why? | Well two answers ... | 1) I accidentally merged a non-GUII change | 2) what use is LFUN_AUTOSAVE ? run the autosave feature manually? -- Lgb
Re: speedup buffer parsing by a factor of 3
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 04:53:56PM +0200, Jean-Marc Lasgouttes wrote: It should. Note that there is a lot of time needed to load the fonts from the X server that gprof does not take in account. I tried to install the gprof-aware libc packages, but I do not know how to use this. | LyXTextClass::operator[] is pretty expensive. | I wonder if we should replace the layout vector by a map indexed by the | layout name... Can you wait a bit with this one? I am planning on working on this next, after the signals stuff. -- Lgb
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 05:10:16PM +0200, Jean-Marc Lasgouttes wrote: This would be useful to actually profile libX11, no? All I want is see the time spent in loading fonts from the server. Well this will show you where time was spent inside libX11, so if you only use LyX when you do it, it'll show the most time-expensive X11 calls LyX (or xforms etc.) makes. Without symbols though you can only get a vague idea : 5000 0.493318(no symbol) /usr/X11R6/lib/libX11.so.6.1 So whatever we are doing inside libX11 it only takes up 0.5% of the time taken to load UserGuide.lyx (unoptimised build blah blah blah) regards john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: BRANCH_GUII question?
On Wed, May 29, 2002 at 05:12:13PM +0200, Lars Gullik Bjønnes wrote: run the autosave feature manually? Can you explain why somebody might want to do this ? Anyway, I'm not that bothered, it can stay if somebody wants it john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: Why is 1.2.0 not announced yet??
On Wed, May 29, 2002 at 05:10:50PM +0200, Jean-Marc Lasgouttes wrote: OK. John, you have an announcement somewhere, don't you? Below - please fill in the FIXME gaps :) Now I can stop getting hate mail for not updating freshmeat entry :) regards john After too long a wait, the LyX team are pleased to announce the new stable release, 1.2.0. This release has far too many bugfixes and new features to list comprehensively, but some are listed below. You can download LyX 1.2.0 here : ftp://ftp.lyx.org/pub/lyx/stable/lyx-1.2.0.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/lyx-1.2.0.tar.gz (FIXME: RPMs etc.) If you find what you think is a bug in LyX 1.2.0, you may either e-mail the LyX user's mailing list, or open a bug report at http://bugzilla.lyx.org If you're having trouble using the new version of LyX, or have a question, first check out http://www.lyx.org/help/, and e-mail the LyX user's list if you can't find an answer there. New features Major improvements have been made to the handling of insets such as footnotes, margin notes, and figure floats. A new minipage facility has been added to make minipage management easy and powerful. Float parameters can be set on a per-float basis now. Notes insets can contain arbitrary objects. A new ERT mode replaces the old LaTeX font and LaTeX environment method of 1.1.6. This allows the user to fold LaTeX text away just like a float, and supports both short and long sections of LaTeX commands in an intuitive manner. The speed and usability problems with tables that remained in 1.1.6 have almost all been fixed. A powerful new graphics system has been included. This allows the user to set up converters to allow previews of any input format (for example, LyX can display inline previews of figures generated from Grace). Many other improvements to the graphics code has been made. Support for natbib citations has been added, and more facilities have been added (such as the ability to search). The math editor has been mostly rewritten, leading to many new features, such as : - possibility to display all standard latex and amsmath symbols (and also the \mathcal, \mathbb, and \mathfrak fonts)as long as the relevant fonts have been made available to the X server - support for many amsmath features - GUI support provided for many more features - (Better) support for nested macros Many dialogs and other LyX features have had major usability improvements. Other new features include document bookmarks, parsing LaTeX pre-ambles on LaTeX import, ligature break support, an English thesaurus, and more. New document classes dtk, ltugboat, spie and svprobth. Bug fixes - A large number of math editor fixes have been made. A number of obscure drawing errors and crash problems have been fixed, and several problems with LaTeX output from LyX documents no longer occur. The problems affecting figure previews, due to ghostscript and xforms, no longer apply. A work around for long tab names in dialogs has been included. Various miscellaneous fixes. Upgrading from earlier LyX versions --- You should have no problems upgrading from LyX versions 1.1.5 and 1.1.6. It is nevertheless recommended that you keep backups of important documents. Most documents will load in 1.2.0 without problems. Older versions of LyX cannot read documents saved with LyX 1.2.0. If you are having problems displaying figures in LyX, make sure you have a recent version of the ImageMagick package installed. There are some (rare) problems with older documents, especially concerning floating figures and the use of minipages. Please read the UPGRADING file for more information on this. (FIXME: put UPGRADING on website somewhere and link to it ??)
Re: speedup buffer parsing by a factor of 3
John == John Levon [EMAIL PROTECTED] writes: John On Wed, May 29, 2002 at 05:10:16PM +0200, Jean-Marc Lasgouttes John wrote: This would be useful to actually profile libX11, no? All I want is see the time spent in loading fonts from the server. John Well this will show you where time was spent inside libX11, so John if you only use LyX when you do it, it'll show the most John time-expensive X11 calls LyX (or xforms etc.) makes. John Without symbols though you can only get a vague idea : John 5000 0.493318 (no symbol) /usr/X11R6/lib/libX11.so.6.1 John So whatever we are doing inside libX11 it only takes up 0.5% of John the time taken to load UserGuide.lyx (unoptimised build blah John blah blah) This seems realy strange: when eon loads the user guide, I would say hat the messages about loading fonts are visible more than 0.5% of the time... JMarc
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 05:28:52PM +0200, Jean-Marc Lasgouttes wrote: This seems realy strange: when eon loads the user guide, I would say hat the messages about loading fonts are visible more than 0.5% of the time... I suppose I should build an optimised build and some X11 libraries with symbols and see ... Another option is to use a simple timing harness like lfp.sf.net around the X calls in question to see the time actually taken to finish each call... regards john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: speedup buffer parsing by a factor of 3
John == John Levon [EMAIL PROTECTED] writes: John On Wed, May 29, 2002 at 05:28:52PM +0200, Jean-Marc Lasgouttes John wrote: This seems realy strange: when eon loads the user guide, I would say hat the messages about loading fonts are visible more than 0.5% of the time... John I suppose I should build an optimised build and some X11 John libraries with symbols and see ... There is not much we can do about these font loading thing anyway. So maybe we can do as if they were not present :) John Another option is to use a simple timing harness like lfp.sf.net John around the X calls in question to see the time actually taken to John finish each call... There is not much on this site. JMarc
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 05:19:08PM +0200, Jean-Marc Lasgouttes wrote: Andre LyXTextClass::operator[] is pretty expensive. This is because of string comparisons which are done for the cached value. I do not think we can go much faster, except if we used a smarter operator== for strings (of course we can't, since we do not have the right to use our own strings :). Ok. I just tried a map. It does make things neither better nor worse... Andre I wonder if we should replace the layout vector by a map Andre indexed by the layout name... I am under the impression that most of the time spent is in line 524: if (name == lastLayoutName) return layoutlist[lastLayoutIndex]; You can't be much faster than that, if this is really the bottleneck. I think we have a right to use a const_string class... Apart from that: Why does a paragraph carry its layout as string and not as index in the layout table? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Why is 1.2.0 not announced yet??
John == John Levon [EMAIL PROTECTED] writes: John On Wed, May 29, 2002 at 05:10:50PM +0200, Jean-Marc Lasgouttes John wrote: OK. John, you have an announcement somewhere, don't you? John Below - please fill in the FIXME gaps :) I filled them, except for the UPGRADING stuff. I know I am lazy too. If nobody complains, this is what I will send to the lyx lists. Who else? What is the address of LWN? JMarc After too long a wait, the LyX team are pleased to announce the new stable release, 1.2.0. This release has far too many bugfixes and new features to list comprehensively, but some are listed below. You can download LyX 1.2.0 here : ftp://ftp.lyx.org/pub/lyx/stable/lyx-1.2.0.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/lyx-1.2.0.tar.gz Prebuild binaries (mainly rpms for linux distributions) are available at ftp://ftp.lyx.org/pub/lyx/bin/1.2.0 Note that there is no patch, due to the amount of changes. If you find what you think is a bug in LyX 1.2.0, you may either e-mail the LyX user's mailing list ([EMAIL PROTECTED]), or open a bug report at http://bugzilla.lyx.org If you're having trouble using the new version of LyX, or have a question, first check out http://www.lyx.org/help/, and e-mail the LyX user's list if you can't find an answer there. New features Major improvements have been made to the handling of insets such as footnotes, margin notes, and figure floats. A new minipage facility has been added to make minipage management easy and powerful. Float parameters can be set on a per-float basis now. Notes insets can contain arbitrary objects. A new ERT mode replaces the old LaTeX font and LaTeX environment method of 1.1.6. This allows the user to fold LaTeX text away just like a float, and supports both short and long sections of LaTeX commands in an intuitive manner. The speed and usability problems with tables that remained in 1.1.6 have almost all been fixed. A powerful new graphics system has been included. This allows the user to set up converters to allow previews of any input format (for example, LyX can display inline previews of figures generated from Grace). Many other improvements to the graphics code has been made. Support for natbib citations has been added, and more facilities have been added (such as the ability to search). The math editor has been mostly rewritten, leading to many new features, such as : - possibility to display all standard latex and amsmath symbols (and also the \mathcal, \mathbb, and \mathfrak fonts) as long as the relevant fonts have been made available to the X server - support for many amsmath features - GUI support provided for many more features - (Better) support for nested macros Many dialogs and other LyX features have had major usability improvements. Other new features include document bookmarks, parsing LaTeX pre-ambles on LaTeX import, ligature break support, an English thesaurus, and more. New document classes dtk, ltugboat, spie and svprobth. Bug fixes - A large number of math editor fixes have been made. A number of obscure drawing errors and crash problems have been fixed, and several problems with LaTeX output from LyX documents no longer occur. The problems affecting figure previews, due to ghostscript and xforms, no longer apply. A work around for long tab names in dialogs has been included. Various miscellaneous fixes. Upgrading from earlier LyX versions --- You should have no problems upgrading from LyX versions 1.1.5 and 1.1.6. It is nevertheless recommended that you keep backups of important documents. Most documents will load in 1.2.0 without problems. Older versions of LyX cannot read documents saved with LyX 1.2.0. If you are having problems displaying figures in LyX, make sure you have a recent version of the ImageMagick package installed. There are some (rare) problems with older documents, especially concerning floating figures and the use of minipages. Please read the UPGRADING file for more information on this.
Re: speedup buffer parsing by a factor of 3
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Andre == Andre Poenitz [EMAIL PROTECTED] writes: | Andre On Wed, May 29, 2002 at 04:53:56PM +0200, Jean-Marc Lasgouttes | Andre wrote: It should. Note that there is a lot of time needed to load the fonts from the X server that gprof does not take in account. I tried to install the gprof-aware libc packages, but I do not know how to use this. | Andre LyXTextClass::operator[] is pretty expensive. | This is because of string comparisons which are done for the cached | value. I do not think we can go much faster, except if we used a | smarter operator== for strings (of course we can't, since we do not | have the right to use our own strings :). We have other thing to do to speed up things before we begin with tricks like these... _and_ we must assume that the string implementation that we use will use the fastest way of comparing two strings. | I am under the impression that most of the time spent is in line 524: | if (name == lastLayoutName) | return layoutlist[lastLayoutIndex]; | You can't be much faster than that, if this is really the bottleneck. I have some ideas on how to speed this up. - dynamic cache - map - hash_map - storing actual pointer to layout in buffer/paragraph - etc. -- Lgb
Re: BRANCH_GUII question?
John Levon [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 05:12:13PM +0200, Lars Gullik Bjønnes wrote: run the autosave feature manually? | Can you explain why somebody might want to do this ? from the lyxserver perhaps... | Anyway, I'm not that bothered, it can stay if somebody wants it let it stay. -- Lgb
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 05:14:21PM +0200, Lars Gullik Bjønnes wrote: | I wonder if we should replace the layout vector by a map indexed by the | layout name... Can you wait a bit with this one? Too late. But it does not improve things, so I won't bother you with a patch... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 05:40:06PM +0200, Jean-Marc Lasgouttes wrote: There is not much on this site. Check the CVS ... it's /very/ simple i.e. just rdtsc calls (only useful if you've x86/Linux of course ...) regards john -- A Mini Cooper ? I wouldn't be seen dead in one of those ! - Mickey Finn
Re: Why is 1.2.0 not announced yet??
On Wed, May 29, 2002 at 05:40:33PM +0200, Jean-Marc Lasgouttes wrote: If nobody complains, this is what I will send to the lyx lists. Who else? What is the address of LWN? [EMAIL PROTECTED] http://linuxtoday.com/contribute.php3 After too long a wait, the LyX team are pleased to announce the new stable release, 1.2.0. CJK-1.2.0 is done as well no ? regards john
signals patch (take 2)
signals.diff.gz Description: Change SigC to boost::signals patch.
Re: speedup buffer parsing by a factor of 3
Andre Poenitz [EMAIL PROTECTED] writes: You can't be much faster than that, if this is really the bottleneck. | I think we have a right to use a const_string class... | Apart from that: Why does a paragraph carry its layout as string and not as | index in the layout table? Why does it not carry a pointer to the actual layout object? -- Lgb
Re: signals patch (take 2)
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: I see that the text I added got lost... anyway Unless somebody objects this patch will go in, in just a short while (minutes, not days). -- Lgb
Re: Why is 1.2.0 not announced yet??
John Levon [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 05:40:33PM +0200, Jean-Marc Lasgouttes wrote: If nobody complains, this is what I will send to the lyx lists. Who else? What is the address of LWN? | [EMAIL PROTECTED] | http://linuxtoday.com/contribute.php3 After too long a wait, the LyX team are pleased to announce the new stable release, 1.2.0. | CJK-1.2.0 is done as well no ? Let the CJK people announce that one. -- Lgb
Re: signals patch (take 2)
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: I see that the text Lars I added got lost... anyway I am happy to see I am not alone. I reported the problem to mate. Lars Unless somebody objects this patch will go in, in just a short Lars while (minutes, not days). Go ahead, we'll see what happens. JMarc
Re: Why is 1.2.0 not announced yet??
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Let the CJK people announce that one. Yes, I'll add a separate announcement on the web site. JMarc
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 05:51:25PM +0200, Lars Gullik Bjønnes wrote: | Apart from that: Why does a paragraph carry its layout as string and not as | index in the layout table? Why does it not carry a pointer to the actual layout object? I don't know ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: signals patch (take 2)
On Wednesday 29 May 2002 4:55 pm, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: I see that the text I added got lost... anyway Unless somebody objects this patch will go in, in just a short while (minutes, not days). Not objecting but could you explain (since you're now the expert ;-) - workarea_.scrollCB.connect(slot(this, BufferView::Pimpl::scrollCB)); + workarea_.scrollCB.connect(boost::bind(BufferView::Pimpl::scrollCB, this, _1)); What's the _1? Index: src/BufferView_pimpl.h +#include frontends/key_state.h why is this added? You have changed nothing in the header file that requires it? Angus
Re: signals patch (take 2)
On Wednesday 29 May 2002 5:06 pm, Angus Leeming wrote: On Wednesday 29 May 2002 4:55 pm, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: I see that the text I added got lost... anyway Unless somebody objects this patch will go in, in just a short while (minutes, not days). Not objecting but could you explain (since you're now the expert ;-) - workarea_.scrollCB.connect(slot(this, BufferView::Pimpl::scrollCB)); + workarea_.scrollCB.connect(boost::bind(BufferView::Pimpl::scrollCB, this, _1)); What's the _1? One more question: sometimes you have signal.connect(boost::bind(...)); and sometimes you have signal = boost::bind(...); Any particular reason? Angus
Re: speedup buffer parsing by a factor of 3
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Wed, May 29, 2002 at 05:51:25PM +0200, Lars Gullik Bjønnes Andre wrote: | Apart from that: Why does a paragraph carry its layout as string and not as | index in the layout table? Why does it not carry a pointer to the actual layout object? Andre I don't know ;-) I think it was the whole point of Lars layout-as-string patch. This helps when you want to change buffer class or cut-and-paste between classes. Retrospectively, I am not sure it was the best solution (seeing how expensive it is in terms of performance). JMarc
Re: speedup buffer parsing by a factor of 3
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars We have other thing to do to speed up things before we begin Lars with tricks like these... Probably. Lars _and_ we must assume that the string implementation that we Lars use will use the fastest way of comparing two strings. So you think that the fact that operator== calls a generic compare function that is able to catter for strings with different sizes and all does not matter? I think that in the (string,string) case, it is possible to do better. Lars | You can't be much faster than that, if this is really the Lars bottleneck. Lars I have some ideas on how to speed this up. - dynamic cache - map Lars - hash_map - storing actual pointer to layout in Lars buffer/paragraph - etc. So you are going to undo all your layout-as-string stuff?? JMarc
Re: signals patch (take 2)
Angus Leeming [EMAIL PROTECTED] writes:
| On Wednesday 29 May 2002 4:55 pm, Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
I see that the text I added got lost... anyway
Unless somebody objects this patch will go in, in just a short while
(minutes, not days).
| Not objecting but could you explain (since you're now the expert ;-)
| - workarea_.scrollCB.connect(slot(this, BufferView::Pimpl::scrollCB));
| + workarea_.scrollCB.connect(boost::bind(BufferView::Pimpl::scrollCB, this,
| _1));
| What's the _1?
:-)
void foo(int a) {
... some code using a ...
}
functionvoid f = bind(foo, 5);
f() calls foo(5);
functionvoid, int g = bind(foo, _1);
g(5) calls foo(5);
g() will not work. missing argument.
_1 is a place holder argument.
| Index: src/BufferView_pimpl.h
| +#include frontends/key_state.h
| why is this added? You have changed nothing in the header file that requires
| it?
I got a warning at some point about some missing stuff, then adding
this fixed it.
I'll try to remove it after the patch is in.
--
Lgb
Re: signals patch (take 2)
Angus Leeming [EMAIL PROTECTED] writes: | On Wednesday 29 May 2002 5:06 pm, Angus Leeming wrote: On Wednesday 29 May 2002 4:55 pm, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: I see that the text I added got lost... anyway Unless somebody objects this patch will go in, in just a short while (minutes, not days). Not objecting but could you explain (since you're now the expert ;-) -workarea_.scrollCB.connect(slot(this, BufferView::Pimpl::scrollCB)); +workarea_.scrollCB.connect(boost::bind(BufferView::Pimpl::scrollCB, this, _1)); What's the _1? | One more question: | sometimes you have | signal.connect(boost::bind(...)); | and sometimes you have | signal = boost::bind(...); | Any particular reason? Yes, I also changed a lot of the signals in frontend/Dialogs.C to be boost::functions in stead. It seemed to me that these signals would _always_ be connected, and _never_ have more than one connectee. Thus a callback is better. -- Lgb
Re: speedup buffer parsing by a factor of 3
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Andre == Andre Poenitz [EMAIL PROTECTED] writes: | Andre On Wed, May 29, 2002 at 05:51:25PM +0200, Lars Gullik Bjønnes | Andre wrote: | Apart from that: Why does a paragraph carry its layout as string and not as | index in the layout table? Why does it not carry a pointer to the actual layout object? | Andre I don't know ;-) | I think it was the whole point of Lars layout-as-string patch. This | helps when you want to change buffer class or cut-and-paste between | classes. Retrospectively, I am not sure it was the best solution | (seeing how expensive it is in terms of performance). I'd say that the performance hit is negligible, and most of it can be fixed with some more clever structurs and algorithms. -- Lgb
Re: speedup buffer parsing by a factor of 3
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars We have other thing to do to speed up things before we begin | Lars with tricks like these... | Probably. | Lars _and_ we must assume that the string implementation that we | Lars use will use the fastest way of comparing two strings. | So you think that the fact that operator== calls a generic compare | function that is able to catter for strings with different sizes and | all does not matter? I think that in the (string,string) case, it is | possible to do better. | Lars | You can't be much faster than that, if this is really the | Lars bottleneck. | Lars I have some ideas on how to speed this up. - dynamic cache - map | Lars - hash_map - storing actual pointer to layout in | Lars buffer/paragraph - etc. | So you are going to undo all your layout-as-string stuff?? No, that will not be my first option. I will try other things first. One nice thing about the layout string though, is that we now does not rely on hardcoded layout names or indices anywhere. -- Lgb
Announcement
The webpage announcement links to 1_1_6.txt Cut and paste error, sheez :) john -- If you look 'round the table and can't tell who the sucker is, it's you. - Quiz Show
Re: Announcement
John == John Levon [EMAIL PROTECTED] writes: John The webpage announcement links to 1_1_6.txt John Cut and paste error, sheez :) Thanks. And I thought I double-checked everything. Time to go home. JMarc
Re: Announcement
On Wed, May 29, 2002 at 05:55:46PM +0100, John Levon wrote: The webpage announcement links to 1_1_6.txt Although the first sentence still applies :)) john -- If you look 'round the table and can't tell who the sucker is, it's you. - Quiz Show
Re: speedup buffer parsing by a factor of 3
On Wed, May 29, 2002 at 06:43:33PM +0200, Lars Gullik Bjønnes wrote: I'd say that the performance hit is negligible, and most of it can be fixed with some more clever structurs and algorithms. We spend 25% of the LyX related UserGuide loading time in LyXTextClass::operator[] if I read the gprof output correctly. That is most certainly not negligible. Of course, most calls to this are caused by LyXText::getFont() which in turn is called by which I don't think would is strictly necessary... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: speedup buffer parsing by a factor of 3
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 06:43:33PM +0200, Lars Gullik Bjønnes wrote: I'd say that the performance hit is negligible, and most of it can be fixed with some more clever structurs and algorithms. | We spend 25% of the LyX related UserGuide loading time in | LyXTextClass::operator[] if I read the gprof output correctly. | That is most certainly not negligible. That is not what I claim. I claim that the change to laytout-as-string performance hit is negligible. -- Lgb
token frequencies when loading the Userguide.lyx
This is the token frequencies I get when loading Userguide.lyx.
3341 \family
1891 \layout
1166 \bar
874 \emph
799 \begin_inset
575 \shape
547 \noun
505 \series
502 \color
492 \SpecialChar
330 \size
107 \end_deeper
107 \begin_deeper
80 \labelwidthstring
68 \backslash
54 \i
39 \hfill
25 \align
21 \newline
16 \added_space_top
15 \added_space_bottom
5 \bibitem
4 \noindent
1 \use_numerical_citations
1 \use_natbib
1 \use_geometry
1 \use_amsmath
1 \tocdepth
1 \the_end
1 \textclass
1 \spacing
1 \secnumdepth
1 \quotes_times
1 \quotes_language
1 \paragraph_separation
1 \papersize
1 \papersides
1 \paperpagestyle
1 \paperpackage
1 \paperorientation
1 \paperfontsize
1 \papercolumns
1 \line_bottom
1 \language
1 \inputencoding
1 \graphics
1 \fontscheme
1 \defskip
1 \begin_preamble
To create this I add:
{
ofstream tofs(/tmp/tokens.txt, std::ios_base::app);
tofs token \n;
}
To the top of parseSingleLyXformat2Token in buffer.C
/tmp/tokens.txt is parsed by this prog:
bucketcheck.C:
#include fstream
#include iostream
#include map
using namespace std;
int main()
{
ifstream ifs(/tmp/realtokens.txt);
mapstring, int buckets;
string line;
while (getline(ifs, line)) {
++buckets[line];
}
mapstring, int::const_iterator cit = buckets.begin();
mapstring, int::const_iterator end = buckets.end();
for (; cit != end; ++cit) {
cout cit-second cit-first \n;
}
}
which pipes its output to this:
egrep ^ /tmp/tokens.txt /tmp/realtokens.txt
./bucketcheck | sort -g | tac /tmp/tokenorder.txt
Results for other largish lyx files would be nice to have.
--
Lgb
Re: Why is 1.2.0 not announced yet??
On Wed, May 29, 2002 at 05:52:28PM +0100, John Levon wrote: On Wed, May 29, 2002 at 09:48:27AM -0700, Kayvan A. Sylvan wrote: A complete nit, but is it the LyX team is pleased to announce? The team is one entity. Am I wrong? You're probably right, I can nevner work out the rules for this ... But it's too late now :) Well, not too late for the Web announcement or any other web or Email announcements... -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
[ANNOUNCE] LyX 1.2.0 is there!
After too long a wait, the LyX team are pleased to announce the new stable release, 1.2.0. This release has far too many bugfixes and new features to list comprehensively, but some are listed below. You can download LyX 1.2.0 here : ftp://ftp.lyx.org/pub/lyx/stable/lyx-1.2.0.tar.gz ftp://ftp.devel.lyx.org/pub/lyx/lyx-1.2.0.tar.gz Prebuild binaries (mainly rpms for linux distributions) are available at ftp://ftp.lyx.org/pub/lyx/bin/1.2.0/ Note that there is no patch, due to the amount of changes. If you find what you think is a bug in LyX 1.2.0, you may either e-mail the LyX user's mailing list ([EMAIL PROTECTED]), or open a bug report at http://bugzilla.lyx.org If you're having trouble using the new version of LyX, or have a question, first check out http://www.lyx.org/help/, and e-mail the LyX user's list if you can't find an answer there. New features Major improvements have been made to the handling of insets such as footnotes, margin notes, and figure floats. A new minipage facility has been added to make minipage management easy and powerful. Float parameters can be set on a per-float basis now. Notes insets can contain arbitrary objects. A new ERT mode replaces the old LaTeX font and LaTeX environment method of 1.1.6. This allows the user to fold LaTeX text away just like a float, and supports both short and long sections of LaTeX commands in an intuitive manner. The speed and usability problems with tables that remained in 1.1.6 have almost all been fixed. A powerful new graphics system has been included. This allows the user to set up converters to allow previews of any input format (for example, LyX can display inline previews of figures generated from Grace). Many other improvements to the graphics code has been made. Support for natbib citations has been added, and more facilities have been added (such as the ability to search). The math editor has been mostly rewritten, leading to many new features, such as : - possibility to display all standard latex and amsmath symbols (and also the \mathcal, \mathbb, and \mathfrak fonts) as long as the relevant fonts have been made available to the X server - support for many amsmath features - GUI support provided for many more features - (Better) support for nested macros Many dialogs and other LyX features have had major usability improvements. Other new features include document bookmarks, parsing LaTeX pre-ambles on LaTeX import, ligature break support, an English thesaurus, and more. New document classes dtk, ltugboat, spie and svprobth. Bug fixes - A large number of math editor fixes have been made. A number of obscure drawing errors and crash problems have been fixed, and several problems with LaTeX output from LyX documents no longer occur. The problems affecting figure previews, due to ghostscript and xforms, no longer apply. A work around for long tab names in dialogs has been included. Various miscellaneous fixes. Upgrading from earlier LyX versions --- You should have no problems upgrading from LyX versions 1.1.5 and 1.1.6. It is nevertheless recommended that you keep backups of important documents. Most documents will load in 1.2.0 without problems. Older versions of LyX cannot read documents saved with LyX 1.2.0. If you are having problems displaying figures in LyX, make sure you have a recent version of the ImageMagick package installed. There are some (rare) problems with older documents, especially concerning floating figures and the use of minipages. Please read the UPGRADING file for more information on this.
Re: CJK-LyX-1.2.0
cghan == [EMAIL PROTECTED] writes: cghan Hello, Since there's been no official announcement of lyx-1.2.0 cghan yet, I cannot announce CJK-LyX-1.2.0 now, right? You can now. Sorry for the delay. JMarc
[Patch] mathed: fontinsets.diff
The attached patch introduces real insets for font changes for mathed. This (a) is not yet fully functional again (b) is still a bit awkward to navigate (an extra Left or Right) (c) simplifies the code by removing some not-so-pretty hacks. Comments? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson) fontinsets.diff.gz Description: application/gunzip
maintainer-clean fails...
This is following a make clean. Angus Making maintainer-clean in lib make[1]: Entering directory `/home/aleem/lyx/lyx-devel-build/lib' make[1]: *** No rule to make target `../config.status', needed by `Makefile'. Stop. make[1]: Leaving directory `/home/aleem/lyx/lyx-devel-build/lib' make: *** [maintainer-clean-recursive] Error 1
Re: maintainer-clean fails...
On Wed, May 29, 2002 at 07:45:08PM +0100, Angus Leeming wrote: make[1]: *** No rule to make target `../config.status', needed by `Makefile'. You've infected the tree with an automake != 1.5. You usually need a manual distclean to get yourself out of the hole ... john -- If you look 'round the table and can't tell who the sucker is, it's you. - Quiz Show
Re: maintainer-clean fails...
On Wednesday 29 May 2002 7:50 pm, John Levon wrote: On Wed, May 29, 2002 at 07:45:08PM +0100, Angus Leeming wrote: make[1]: *** No rule to make target `../config.status', needed by `Makefile'. You've infected the tree with an automake != 1.5. You usually need a manual distclean to get yourself out of the hole ... So I have; I'm playing on a linux-alpha machine that I don't know that well. It's running debian unstable, but is clearly not so unstable: automake (GNU automake) 1.4-p4 Nonetheless, I can actually compile fine. Angus
Re: [Patch] mathed: fontinsets.diff
Andre Poenitz [EMAIL PROTECTED] writes:
| The attached patch introduces real insets for font changes for mathed.
| This
| (a) is not yet fully functional again
| (b) is still a bit awkward to navigate (an extra Left or Right)
| (c) simplifies the code by removing some not-so-pretty hacks.
| Comments?
Why this:
+ MathPainterInfo pi = MathPainterInfo(bv-painter());
and not
MathPaitnerInfo pi(bv-painter());
?
Parenthesis perhaps?
+ pi.base.style = display() ? LM_ST_DISPLAY : LM_ST_TEXT;
btw. why are you using strings instead of the ints? (LM_TC_GREEK1 -
lyxgreek1) Not that it really matter.
(Except that magic constants, be it ints or strings, are bad.)
Hmmm...
diff -u -p -r1.8 math_binaryopinset.C
--- math_binaryopinset.C23 May 2002 09:21:30 - 1.8
+++ math_binaryopinset.C29 May 2002 18:21:04 -
@@ -5,7 +5,11 @@
#endif
#include math_binaryopinset.h
+ math_binaryopinset.C
+#include MathPainterInfo.h
+===
#include frontends/Painter.h
+ 1.8
#include support/LOstream.h
Do we really like strchr and friends?
+ bool isBinaryOp(char c)
+ {
+ return strchr(+-=/*, c);
+ }
or would we rather like to see
static char const * binaries = +-=/*;
return memchr(binaries, 7, c);
or perhaps even (I'd prefere this one)
static string const binaries(+-=/*);
return binaries.find_first_of(c) != string::npos;
The patch looks pretty much ok to me.
--
Lgb
Re: maintainer-clean fails...
Angus Leeming [EMAIL PROTECTED] writes: | This is following a make clean. | Angus | Making maintainer-clean in lib | make[1]: Entering directory `/home/aleem/lyx/lyx-devel-build/lib' | make[1]: *** No rule to make target `../config.status', needed by `Makefile'. | Stop. | make[1]: Leaving directory `/home/aleem/lyx/lyx-devel-build/lib' | make: *** [maintainer-clean-recursive] Error 1 version of automake please. -- Lgb
Re: speedup buffer parsing by a factor of 3
Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, May 29, 2002 at 06:43:33PM +0200, Lars Gullik Bjønnes wrote: I'd say that the performance hit is negligible, and most of it can be fixed with some more clever structurs and algorithms. | We spend 25% of the LyX related UserGuide loading time in | LyXTextClass::operator[] if I read the gprof output correctly. | That is most certainly not negligible. That is not what I claim. I claim that the change to laytout-as-string performance hit is negligible. Uh? Without layout-as-string, this operator[] would be trivial. JMarc
[RFC PATCH] Require arguments when needed
? arguments.patch
? build
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.244
diff -u -p -r1.244 BufferView_pimpl.C
--- src/BufferView_pimpl.C 29 May 2002 16:20:56 - 1.244
+++ src/BufferView_pimpl.C 29 May 2002 19:24:01 -
-1804,17 +1804,6 bool BufferView::Pimpl::Dispatch(kb_acti
lyxerr[Debug::INFO] LFUN_LAYOUT: (arg)
argument endl;
- // This is not the good solution to the empty argument
- // problem, but it will hopefully suffice for 1.2.0.
- // The correct solution would be to augument the
- // function list/array with information about what
- // functions needs arguments and their type.
- if (argument.empty()) {
- owner_-getLyXFunc()-setErrorMessage(
-_(LyX function 'layout' needs an argument.));
- break;
- }
-
// Derive layout number from given argument (string)
// and current buffer's textclass (number). */
bool hasLayout = tclass.hasLayout(argument);
-2829,12 +2818,16 bool BufferView::Pimpl::Dispatch(kb_acti
string tmp;
istr tmp;
+
Spacing::Space new_spacing = cur_spacing;
float new_value = cur_value;
+#if 0
if (tmp.empty()) {
lyxerr Missing argument to `paragraph-spacing'
endl;
- } else if (tmp == single) {
+ } else
+#endif
+ if (tmp == single) {
new_spacing = Spacing::Single;
} else if (tmp == onehalf) {
new_spacing = Spacing::Onehalf;
-3188,6 +3181,7 bool BufferView::Pimpl::Dispatch(kb_acti
}
break;
+#if 0
case LFUN_INDEX_INSERT:
{
InsetCommandParams p;
-3200,6 +3194,7 bool BufferView::Pimpl::Dispatch(kb_acti
updateInset(inset, true);
}
break;
+#endif
case LFUN_INDEX_INSERT_LAST:
{
-3287,8 +3282,9 bool BufferView::Pimpl::Dispatch(kb_acti
case LFUN_SELFINSERT:
{
+#if 0
if (argument.empty()) break;
-
+#endif
/* Automatically delete the currently selected
* text and replace it with what is being
* typed in now. Depends on lyxrc settings
Index: src/LyXAction.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LyXAction.C,v
retrieving revision 1.115
diff -u -p -r1.115 LyXAction.C
--- src/LyXAction.C 21 Mar 2002 17:25:08 - 1.115
+++ src/LyXAction.C 29 May 2002 19:24:01 -
-102,16 +102,18 void LyXAction::init()
{ LFUN_VECTOR, accent-vector, , Noop },
{ LFUN_APPENDIX, appendix, N_(Insert appendix), Noop },
{ LFUN_APROPOS, apropos, N_(Describe command),
- NoBuffer|ReadOnly },
+ NoBuffer | ReadOnly | Argument },
{ LFUN_LEFTSEL, backward-select,
N_(Select previous char), ReadOnly },
- { LFUN_BIBDB_ADD, bibtex-database-add, , Noop },
- { LFUN_BIBDB_DEL, bibtex-database-del, , Noop },
+ { LFUN_BIBDB_ADD, bibtex-database-add, , Argument },
+ { LFUN_BIBDB_DEL, bibtex-database-del, , Argument },
{ LFUN_INSERT_BIBTEX, bibtex-insert, N_(Insert bibtex),
- Noop },
- { LFUN_BIBTEX_STYLE, bibtex-style, , Noop },
- { LFUN_BOOKMARK_GOTO, bookmark-goto, , ReadOnly },
- { LFUN_BOOKMARK_SAVE, bookmark-save, , ReadOnly },
+ Argument },
+ { LFUN_BIBTEX_STYLE, bibtex-style, , Argument },
+ { LFUN_BOOKMARK_GOTO, bookmark-goto, ,
+ ReadOnly | Argument },
+ { LFUN_BOOKMARK_SAVE, bookmark-save, ,
+ ReadOnly | Argument},
{ LFUN_BREAKLINE, break-line, , Noop },
{ LFUN_BREAKPARAGRAPH, break-paragraph, , Noop },
{ LFUN_BREAKPARAGRAPHKEEPLAYOUT, break-paragraph-keep-layout,
-124,17 +126,19 void LyXAction::init()
N_(Go to beginning of document), ReadOnly },
{ LFUN_BEGINNINGBUFSEL, buffer-begin-select,
N_(Select to beginning of document), ReadOnly },
- { LFUN_CHILD_INSERT, buffer-child-insert, , Noop },
- { LFUN_CHILDOPEN, buffer-child-open, , ReadOnly },
+ { LFUN_CHILD_INSERT, buffer-child-insert, , Argument },
+ { LFUN_CHILDOPEN, buffer-child-open, ,
+ ReadOnly | Argument },
{ LFUN_RUNCHKTEX, buffer-chktex, N_(Check TeX), ReadOnly },
{ LFUN_CLOSEBUFFER, buffer-close, N_(Close), ReadOnly },
{ LFUN_ENDBUF, buffer-end,
N_(Go to end of document), ReadOnly },
{ LFUN_ENDBUFSEL, buffer-end-select,
N_(Select to end of document), ReadOnly },
- { LFUN_EXPORT, buffer-export, N_(Export to), ReadOnly },
+ { LFUN_EXPORT, buffer-export, N_(Export to),
+ ReadOnly | Argument },
{ LFUN_IMPORT, buffer-import,
- N_(Import document), NoBuffer },
+ N_(Import document), NoBuffer | Argument },
{ LFUN_BUFFER_PRINT, buffer-print-xtl, N_(Print),
ReadOnly },
{ LFUN_PRINTER_PARAMS_GET, printer-params-get,
-146,14 +150,16 void LyXAction::init()
{ LFUN_MENURELOAD, buffer-reload,
N_(Revert to saved), ReadOnly },
{ LFUN_SWITCHBUFFER, buffer-switch,
- N_(Switch to an open document), ReadOnly },
+ N_(Switch to an open document), ReadOnly | Argument },
{ LFUN_READ_ONLY_TOGGLE, buffer-toggle-read-only,
N_(Toggle read-only), ReadOnly },
- { LFUN_UPDATE,
Re: [Patch] mathed: fontinsets.diff
Andre Poenitz wrote: The attached patch introduces real insets for font changes for mathed. This (a) is not yet fully functional again (b) is still a bit awkward to navigate (an extra Left or Right) (c) simplifies the code by removing some not-so-pretty hacks. Comments? (b) is exactly the problem I have with this font-as-inset approach. Do we really want, for the sake of good code and intellectual satisfaction, to have all documents littered with boxen? Even if these boxen are not visible, they will have a noticable effect on the UI. JMarc
Re: Why is 1.2.0 not announced yet??
Kayvan A. Sylvan wrote: On Wed, May 29, 2002 at 05:52:28PM +0100, John Levon wrote: On Wed, May 29, 2002 at 09:48:27AM -0700, Kayvan A. Sylvan wrote: A complete nit, but is it the LyX team is pleased to announce? The team is one entity. Am I wrong? You're probably right, I can nevner work out the rules for this ... But it's too late now :) Well, not too late for the Web announcement or any other web or Email announcements... Done on the web site. JMarc
Re: [Patch] mathed: fontinsets.diff
On Wed, May 29, 2002 at 09:32:38PM +0200, Jean-Marc Lasgouttes wrote: (b) is exactly the problem I have with this font-as-inset approach. Do we really want, for the sake of good code and intellectual satisfaction, to have all documents littered with boxen? Even if these boxen are not visible, they will have a noticable effect on the UI. Unless we fix the UI to skip about properly too. Aren't we going to need that to get nice foldable sections etc. too some day ? Also, this behaviour is in fact a feature request, consider : Blah Balh Blah| \/ in smallcaps Currently, if this is the end of paragraph, it's very awkward to switch out of SmallCaps. If you can just press right to get back to the default, like many word processors, it becomes much nicer to use, especially when you're doing this a LOT : The function get_something() calls blah_do(), which is obfuscated with mass_doobries() is annoying to type right now if you want to mark up the function names in typewriter regards john -- If you look 'round the table and can't tell who the sucker is, it's you. - Quiz Show
Re: [RFC PATCH] Require arguments when needed
On Wed, May 29, 2002 at 09:25:09PM +0200, Lars Gullik Bjønnes wrote: patch Great, but please put a comment before the #if 0 if you apply the patch as is. Just one of my bete noires :) john -- If you look 'round the table and can't tell who the sucker is, it's you. - Quiz Show
Re: token frequencies when loading the Userguide.lyx
Lars Gullik Bjønnes wrote:
This is the token frequencies I get when loading Userguide.lyx.
3341 \family
1891 \layout
1166 \bar
874 \emph
799 \begin_inset
575 \shape
547 \noun
505 \series
502 \color
492 \SpecialChar
330 \size
107 \end_deeper
107 \begin_deeper
80 \labelwidthstring
68 \backslash
54 \i
39 \hfill
25 \align
21 \newline
16 \added_space_top
15 \added_space_bottom
5 \bibitem
4 \noindent
1 \use_numerical_citations
1 \use_natbib
1 \use_geometry
1 \use_amsmath
1 \tocdepth
1 \the_end
1 \textclass
1 \spacing
1 \secnumdepth
1 \quotes_times
1 \quotes_language
1 \paragraph_separation
1 \papersize
1 \papersides
1 \paperpagestyle
1 \paperpackage
1 \paperorientation
1 \paperfontsize
1 \papercolumns
1 \line_bottom
1 \language
1 \inputencoding
1 \graphics
1 \fontscheme
1 \defskip
1 \begin_preamble
To create this I add:
{
ofstream tofs(/tmp/tokens.txt, std::ios_base::app);
tofs token \n;
}
To the top of parseSingleLyXformat2Token in buffer.C
/tmp/tokens.txt is parsed by this prog:
bucketcheck.C:
#include fstream
#include iostream
#include map
using namespace std;
int main()
{
ifstream ifs(/tmp/realtokens.txt);
mapstring, int buckets;
string line;
while (getline(ifs, line)) {
++buckets[line];
}
mapstring, int::const_iterator cit = buckets.begin();
mapstring, int::const_iterator end = buckets.end();
for (; cit != end; ++cit) {
cout cit-second cit-first \n;
}
}
which pipes its output to this:
egrep ^ /tmp/tokens.txt /tmp/realtokens.txt
./bucketcheck | sort -g | tac /tmp/tokenorder.txt
Results for other largish lyx files would be nice to have.
If I may reattach my earlier script (which is admitedly not 100%
accurate but who cares?)... It gives similar but different results:
3335 \family
1889 \layout
1398 \begin_inset
1398 \end_inset
1166 \bar
871 \emph
575 \shape
547 \noun
505 \series
502 \color
491 \SpecialChar
330 \size
107 \begin_deeper
107 \end_deeper
80 \labelwidthstring
67 \backslash
54 \i
39 \hfill
21 \newline
[snip]
If I run it on Herbert's Versuch.lyx (translated to 1.2.0 format)
(this is a file he sent because of performance problems), I get
ginette: ./counttokens fichiers/Versuch120.lyx
10869 \layout
9612 \begin_inset
9612 \end_inset
4841 \backslash
2589 \emph
2506 \family
2492 \noun
2486 \bar
2486 \shape
2375 \color
2371 \size
1684 \series
192 \SpecialChar
64 \align
64 \newline
[snip]
I doubt though that there is still a big gain to be found in this area.
JMarc
#!/bin/sh
grep '\\[a-zA-Z_]* ' $1 | sed -e 's/^[^\]*\(\\[A-Za-z_]*\) .*$/\1/'|sort|uniq -c|sort
-k1,1nr
Re: [RFC PATCH] Require arguments when needed
Why just do this half-baked reauire argument thing (which does not buy us much, unless you have something in mind) instead of trying to specify better these arguments? JMarc
