Jürgen Spitzmüller wrote:
\textipa{\textepsilon{}kspl\textschwa{}ne\textsci{}\textesh{}\textschwa{}n}
which is not only hardly readable (due to the macros), but also the kerning
is broken by the {} which are appended after each macro.
The kerning problem is addressed by the attached patch
Jürgen Spitzmüller wrote:
> \textipa{\textepsilon{}kspl\textschwa{}ne\textsci{}\textesh{}\textschwa{}n}
>
> which is not only hardly readable (due to the macros), but also the kerning
> is broken by the {} which are appended after each macro.
The kerning problem is addressed by the attached
Stephan Witt wrote:
I have another patch in my local branch checkout...
It fixes a warning and a potential bug.
OK.
Jürgen
Stephan Witt wrote:
> I have another patch in my local branch checkout...
> It fixes a warning and a potential bug.
OK.
Jürgen
I have another patch in my local branch checkout...
It fixes a warning and a potential bug.
Stephan
Index: src/mathed/InsetMathHull.cpp
===
--- src/mathed/InsetMathHull.cpp(Revision 35627)
+++ src/mathed/InsetMathHull.cpp
I have another patch in my local branch checkout...
It fixes a warning and a potential bug.
Stephan
Index: src/mathed/InsetMathHull.cpp
===
--- src/mathed/InsetMathHull.cpp(Revision 35627)
+++ src/mathed/InsetMathHull.cpp
So, removing the whole boundary business, we get this behavious:
1) abc| \ndef =right= abc \n|def
2) ab|c\ndef =right= abc\n|def =right= abc\nd|ef
3) abc \nd|ef =left= abc \n|def =left= abc| \ndef
4) abc\nd|ef =left= abc\ndef =left= ab|c\ndef
5) abc|newline\ndef =right= abcnewline\n|def
6)
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan This is fine, mostly. I don't like 7. There should be a
Stefan position behind the c, because if you type with the cursor in
Stefan front of the $$1$ $ the characters appear behind c. In fact
Stefan the position in front of $$1 $$
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan This is fine, mostly. I don't like 7. There should be a
Stefan position behind the c, because if you type with the cursor in
Stefan front of the $$1$ $ the characters appear
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan This is fine, mostly. I don't like 7. There should be a
Stefan position behind the c, because if you type with the
Am 31.05.2007 um 09:57 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan This is fine, mostly. I don't like 7. There should be a
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan The only case I can imagine is while selecting an inset like
Stefan display math. It might seem more intuitive if you can select
Stefan just the line of a display math.
But the visual effect will remain the same anyway.
I have the
Am 31.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan The only case I can imagine is while selecting an inset like
Stefan display math. It might seem more intuitive if you can select
Stefan just the line of a display math.
But the
Jean-Marc Lasgouttes wrote:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan This is fine, mostly. I don't like 7. There should be a
Stefan position behind the c,
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Good question. In 1.4.x, the two positions exist. I am not sure
why the position in front of the display inset is deemed useful.
Abdelrazak Isn't this related to change-tracking?
I think it is something else, but what?
JMarc
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow the thread but I hope that you did not kill any
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
Ah yes I remembered something about a virtual end-of-par.
It does not care for
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-
existing) end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow
Stefan Schimanski schrieb:
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e.
non-existing) end-of-par character at the end of each paragraph.
It does not care for cursor
On Thu, May 31, 2007 at 09:25:15AM +0200, Stefan Schimanski wrote:
So, removing the whole boundary business, we get this behavious:
1) abc| \ndef =right= abc \n|def
2) ab|c\ndef =right= abc\n|def =right= abc\nd|ef
3) abc \nd|ef =left= abc \n|def =left= abc| \ndef
4) abc\nd|ef =left=
On Thu, May 31, 2007 at 09:50:03AM +0200, Stefan Schimanski wrote:
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan This is fine, mostly. I don't like 7. There should be a
Stefan position behind the c, because if you type
Stefan Schimanski schrieb:
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e.
non-existing) end-of-par character at the end of each paragraph.
It does not care for cursor
On Thu, May 31, 2007 at 09:25:15AM +0200, Stefan Schimanski wrote:
> So, removing the whole boundary business, we get this behavious:
>
> 1) abc| \ndef =right=> abc \n|def
> 2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef
> 3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef
> 4) abc\nd|ef
On Thu, May 31, 2007 at 09:50:03AM +0200, Stefan Schimanski wrote:
>
> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
>
> >>"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
> >
> >Stefan> This is fine, mostly. I don't like 7. There should be a
> >Stefan> position behind the c,
So, removing the whole boundary business, we get this behavious:
1) abc| \ndef =right=> abc \n|def
2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef
3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef
4) abc\nd|ef =left=> abc\ndef =left=> ab|c\ndef
5) abc|\ndef =right=> abc\n|def
6) abcd|ef
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because if you type with the cursor in
Stefan> front of the $$1$ $ the characters appear behind c. In fact
Stefan> the position in front
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because if you type with the cursor in
Stefan> front of the $$1$ $ the characters
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
>>> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>>
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because
Am 31.05.2007 um 09:57 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> The only case I can imagine is while selecting an inset like
Stefan> display math. It might seem more intuitive if you can select
Stefan> just the line of a display math.
But the visual effect will remain the same anyway.
I
Am 31.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> The only case I can imagine is while selecting an inset like
Stefan> display math. It might seem more intuitive if you can select
Stefan> just the line of a display math.
Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Good question. In 1.4.x, the two positions exist. I am not sure
>> why the position in front of the display inset is deemed useful.
Abdelrazak> Isn't this related to change-tracking?
I think it is something else, but what?
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow the thread but I hope that you did not kill any
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
Ah yes I remembered something about a virtual end-of-par.
It does not care for
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-
existing) end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow
[This should be applied after the patch in
http://permalink.gmane.org/gmane.editors.lyx.devel/86074, which fixes
bug 3754.]
Okay, you guys (Stefan and Andre') are correct, as always ;) .
We really don't need the boundary almost anywhere. The comment on
boundary_ in DocIterator.h is (almost)
On Thu, May 31, 2007 at 02:29:38AM +0300, Dov Feldstern wrote:
At least cursorLeft and cursorRight are much simpler now...
I have no idea whether the patch is sound, but I certainly like the
structure...
Andre'
[This should be applied after the patch in
http://permalink.gmane.org/gmane.editors.lyx.devel/86074, which fixes
bug 3754.]
Okay, you guys (Stefan and Andre') are correct, as always ;) .
We really don't need the boundary almost anywhere. The comment on
boundary_ in DocIterator.h is (almost)
On Thu, May 31, 2007 at 02:29:38AM +0300, Dov Feldstern wrote:
> At least cursorLeft and cursorRight are much simpler now...
I have no idea whether the patch is sound, but I certainly like the
structure...
Andre'
John McCabe-Dansted wrote:
John If LyX locked files which were open in a still running LyX
John process, that would have saved me some confusion.
Yes, but I am sure this can cause a lot of confusion too...
I am not sure why this would cause confusion. You could have a dialog
box warning
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Jean-Marc Anyway, I have an additional patch for this bug. Anyone
Jean-Marc disagrees?
Applied.
JMarc
Helge Hafting [EMAIL PROTECTED] writes:
| John McCabe-Dansted wrote:
|
| John If LyX locked files which were open in a still running LyX
| John process, that would have saved me some confusion.
|
| Yes, but I am sure this can cause a lot of confusion too...
|
|
| I am not sure why this would
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Please have a look at how emacs does this. (I am in favor of the
Lars 'when in doubt do as emacs' camp.)
It uses a ~/.emacs-places file which contains a list of files and
offsets.
JMarc
John McCabe-Dansted wrote:
John> If LyX locked files which were open in a still running LyX
John> process, that would have saved me some confusion.
Yes, but I am sure this can cause a lot of confusion too...
I am not sure why this would cause confusion. You could have a dialog
box
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> Anyway, I have an additional patch for this bug. Anyone
Jean-Marc> disagrees?
Applied.
JMarc
Helge Hafting <[EMAIL PROTECTED]> writes:
| John McCabe-Dansted wrote:
|
| >>John> If LyX locked files which were open in a still running LyX
| >>John> process, that would have saved me some confusion.
| >>
| >>Yes, but I am sure this can cause a lot of confusion too...
| >>
| >
| >I am not sure
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Please have a look at how emacs does this. (I am in favor of the
Lars> 'when in doubt do as emacs' camp.)
It uses a ~/.emacs-places file which contains a list of files and
offsets.
JMarc
John If LyX locked files which were open in a still running LyX
John process, that would have saved me some confusion.
Yes, but I am sure this can cause a lot of confusion too...
I am not sure why this would cause confusion. You could have a dialog
box warning that Another LyX window has this
> John> If LyX locked files which were open in a still running LyX
> John> process, that would have saved me some confusion.
>
> Yes, but I am sure this can cause a lot of confusion too...
I am not sure why this would cause confusion. You could have a dialog
box warning that "Another LyX window
John == John McCabe-Dansted [EMAIL PROTECTED] writes:
Sure, the extra trouble only ever occur for power users.
John Perhaps we could have a new minibuffer command save-unchanged
John which would save the document even if it is unchanged. Such
John power users could replace save with
> "John" == John McCabe-Dansted <[EMAIL PROTECTED]> writes:
>> Sure, the "extra trouble" only ever occur for power users.
John> Perhaps we could have a new minibuffer command save-unchanged
John> which would save the document even if it is unchanged. Such
John> power users could replace
Hi folks,
Here is another set of cleanups for the lyx.spec.in:
Please apply.
---Kayvan
--
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 |
Hi folks,
Here is another set of cleanups for the lyx.spec.in:
Please apply.
---Kayvan
--
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 |
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger Regarding improving the performance: I can only recommend using
Asger gprof. It's very easy, and it really helps when you want to
Asger find and address bottlenecks.
Yes, profiling is often a better idea than trying to guess
"Mike" == [EMAIL PROTECTED] writes:
Mike 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...
Mike This wins the "Cool Typo" award. When reading your (the
Mike
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
|
| Asger Regarding improving the performance: I can only recommend using
| Asger gprof. It's very easy, and it really helps when you want to
| Asger find and address bottlenecks.
|
|
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I think my lazy generation of LyXText could help on that. then
Lars we should only load the font metrics when first needed.
Stupid question: are we forced to load the whole font metrics to use a
font? If not, caching would be a gain.
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars I think my lazy generation of LyXText could help on that. then
| Lars we should only load the font metrics when first needed.
|
| Stupid question: are we forced to load the whole
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Regarding improving the performance: I can only recommend using
Asger> gprof. It's very easy, and it really helps when you want to
Asger> find and address bottlenecks.
Yes, profiling is often a better idea than trying
> "Mike" == <[EMAIL PROTECTED]> writes:
Mike> 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...
Mike> This wins the "Cool Typo" award. When reading your
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
|
| Asger> Regarding improving the performance: I can only recommend using
| Asger> gprof. It's very easy, and it really helps when you want to
| Asger> find and address
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I think my lazy generation of LyXText could help on that. then
Lars> we should only load the font metrics when first needed.
Stupid question: are we forced to load the whole font metrics to use a
font? If not, caching would
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> I think my lazy generation of LyXText could help on that. then
| Lars> we should only load the font metrics when first needed.
|
| Stupid question: are we forced to load
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
"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
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
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
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
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
|
[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
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
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
[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
"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
"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
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
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
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
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
--
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
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
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
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
> "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
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
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
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 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
> |
[EMAIL PROTECTED] (Lars Gullik Bjønnes) 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
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
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
[EMAIL PROTECTED] (Lars Gullik Bjønnes) 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
> "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
> "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
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "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
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
Dekel Tsur <[EMAIL PROTECTED]> writes:
| 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
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?
Jürgen
--
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>
1 - 100 of 114 matches
Mail list logo
