Enrico Forestieri wrote:
Doh! So, a paragraph can have zero size. I thought that it was not
possible, and thus that end was always greater than zero.
Here, the latex log was pointing to the EndFrame, which apparently
is a zero-size paragraph. In this case the solution is to simply
highlight a
On Thu, Feb 24, 2011 at 01:06:01PM +0100, Jürgen Spitzmüller wrote:
The error highligthing could be improved here, though (highlighting is off
by a few lines).
This is hard to fix, I think. Our highlighting is based on the line
reported in the latex log. Now, the reported line may be off
Enrico Forestieri wrote:
> Doh! So, a paragraph can have zero size. I thought that it was not
> possible, and thus that "end" was always greater than zero.
> Here, the latex log was pointing to the EndFrame, which apparently
> is a zero-size paragraph. In this case the solution is to simply
>
On Thu, Feb 24, 2011 at 01:06:01PM +0100, Jürgen Spitzmüller wrote:
>
> The error highligthing could be improved here, though (highlighting is off
> by a few lines).
This is hard to fix, I think. Our highlighting is based on the line
reported in the latex log. Now, the reported line may be off
Jürgen Spitzmüller wrote:
Currently, trunk freezes on me whenever I view/update and have a LaTeX
error. I have to kill LyX and restart. I think it has to do with the
viewer application zombie process reported on lyx-users.
Actually, LyX enters a loop. On the console, I get a flood of
Jürgen Spitzmüller wrote:
Actually, LyX enters a loop. On the console, I get a flood of
lassert.cpp(21): ASSERTION pos = 0 pos = size() VIOLATED IN
Paragraph.cpp:775
This is the Paragraph::eraseChar function. LyX does not shut down because
I have configured in release mode. I'm now
Jürgen Spitzmüller wrote:
#4 0x08320142 in lyx::Paragraph::isLineSeparator (this=0xb2d7240, pos=-1)
at Paragraph.cpp:2834
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some thread-releated fixme was left iirc)
and spellcheck touches...
I suspect it has to do with
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some thread-releated fixme was left iirc)
and
On 23.02.2011 21:19, Peter Kümmel wrote:
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
bisect leads to r37749
pavel
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
bisect leads to r37749
http://www.lyx.org/trac/changeset/37749/lyx-devel/trunk
and -dgb
On 23.02.2011 21:52, Peter Kümmel wrote:
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
bisect leads to r37749
Am 23.02.2011 um 22:10 schrieb Peter Kümmel:
On 23.02.2011 21:52, Peter Kümmel wrote:
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
On Wed, Feb 23, 2011 at 09:37:15PM +0100, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
= crash.
i got it now.p
bisect leads to r37749
Doh! So, a paragraph can have
Jürgen Spitzmüller wrote:
> Currently, trunk freezes on me whenever I view/update and have a LaTeX
> error. I have to kill LyX and restart. I think it has to do with the
> viewer application zombie process reported on lyx-users.
Actually, LyX enters a loop. On the console, I get a flood of
Jürgen Spitzmüller wrote:
> Actually, LyX enters a loop. On the console, I get a flood of
>
> lassert.cpp(21): ASSERTION pos >= 0 && pos <= size() VIOLATED IN
> Paragraph.cpp:775
>
> This is the Paragraph::eraseChar function. LyX does not shut down because
> I have configured in release mode.
Jürgen Spitzmüller wrote:
> #4 0x08320142 in lyx::Paragraph::isLineSeparator (this=0xb2d7240, pos=-1)
> at Paragraph.cpp:2834
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are
Pavel Sanda wrote:
> looks like your inside ert with selected word? still cant reproduce...
> but this routine didn't changed lately. maybe-related paragraphs changes
> in my memory are texrow changes (some thread-releated fixme was left iirc)
> and spellcheck touches...
I suspect it has to do
Jürgen Spitzmüller wrote:
> Not currently, but here's a testcase.
>
> * View
> * Close error dialog
> * click into ERT
> => crash.
i got it now.p
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some thread-releated fixme was left iirc)
and
On 23.02.2011 21:19, Peter Kümmel wrote:
On 23.02.2011 20:57, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
looks like your inside ert with selected word? still cant reproduce...
but this routine didn't changed lately. maybe-related paragraphs changes
in my memory are texrow changes (some
Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > Not currently, but here's a testcase.
> >
> > * View
> > * Close error dialog
> > * click into ERT
> > => crash.
>
> i got it now.p
bisect leads to r37749
pavel
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
=> crash.
i got it now.p
bisect leads to r37749
http://www.lyx.org/trac/changeset/37749/lyx-devel/trunk
and -dgb
On 23.02.2011 21:52, Peter Kümmel wrote:
On 23.02.2011 21:37, Pavel Sanda wrote:
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Not currently, but here's a testcase.
* View
* Close error dialog
* click into ERT
=> crash.
i got it now.p
bisect leads to r37749
Am 23.02.2011 um 22:10 schrieb Peter Kümmel:
> On 23.02.2011 21:52, Peter Kümmel wrote:
>> On 23.02.2011 21:37, Pavel Sanda wrote:
>>> Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
> Not currently, but here's a testcase.
>
> * View
> * Close error dialog
> * click into
On Wed, Feb 23, 2011 at 09:37:15PM +0100, Pavel Sanda wrote:
> Pavel Sanda wrote:
> > Jürgen Spitzmüller wrote:
> > > Not currently, but here's a testcase.
> > >
> > > * View
> > > * Close error dialog
> > > * click into ERT
> > > => crash.
> >
> > i got it now.p
>
> bisect leads to r37749
Currently, trunk freezes on me whenever I view/update and have a LaTeX error.
I have to kill LyX and restart. I think it has to do with the viewer
application zombie process reported on lyx-users.
I have no real recipe. It does not happen with all documents, but 100% with
some. No time to dig
Jürgen Spitzmüller wrote:
Currently, trunk freezes on me whenever I view/update and have a LaTeX error.
I have to kill LyX and restart. I think it has to do with the viewer
application zombie process reported on lyx-users.
I have no real recipe. It does not happen with all documents, but
Pavel Sanda wrote:
I have no real recipe. It does not happen with all documents, but 100%
with some. No time to dig further ATM, semester has started here.
cant reproduce. what viewer do you use? also evince?
No, okular.
Jürgen
Currently, trunk freezes on me whenever I view/update and have a LaTeX error.
I have to kill LyX and restart. I think it has to do with the viewer
application zombie process reported on lyx-users.
I have no real recipe. It does not happen with all documents, but 100% with
some. No time to dig
Jürgen Spitzmüller wrote:
> Currently, trunk freezes on me whenever I view/update and have a LaTeX error.
> I have to kill LyX and restart. I think it has to do with the viewer
> application zombie process reported on lyx-users.
>
> I have no real recipe. It does not happen with all documents,
Pavel Sanda wrote:
> > I have no real recipe. It does not happen with all documents, but 100%
> > with some. No time to dig further ATM, semester has started here.
>
> cant reproduce. what viewer do you use? also evince?
No, okular.
Jürgen
Another major bug with QT 4.5.
1.Start LyX
2. Ctrl-N
3. Ctrl-N
Infinite Loop.
Vincent
Vincent van Ravesteijn schreef:
Another major bug with QT 4.5.
1.Start LyX
2. Ctrl-N
3. Ctrl-N
Infinite Loop.
Vincent
According to the documentation:
bool QFileInfo::operator!= ( const QFileInfo /fileinfo/ )
Returns true if this QFileInfo qfileinfo.html object refers
Another major bug with QT 4.5.
1.Start LyX
2. Ctrl-N
3. Ctrl-N
Infinite Loop.
Vincent
Vincent van Ravesteijn schreef:
Another major bug with QT 4.5.
1.Start LyX
2. Ctrl-N
3. Ctrl-N
Infinite Loop.
Vincent
According to the documentation:
bool QFileInfo::operator!= ( const QFileInfo & /fileinfo/ )
Returns true if this QFileInfo object refers to a
_*different
Joost Verburg wrote:
Abdelrazak Younes wrote:
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File -
Open dialog needs many seconds before it opens).
There are more bugs related to the Qt file dialog. Sometimes
Bennett Helm wrote:
On Jul 2, 2007, at 7:32 AM, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File -
Open dialog needs many seconds before it opens).
Joost Verburg wrote:
Abdelrazak Younes wrote:
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File ->
Open dialog needs many seconds before it opens).
There are more bugs related to the Qt file dialog. Sometimes
Bennett Helm wrote:
On Jul 2, 2007, at 7:32 AM, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File ->
Open dialog needs many seconds before it opens).
Hello,
Even though I like our file dialog, I think we have no choice but using
native file dialog on Windows in order to fix bug 3907 (File - Open
dialog needs many seconds before it opens).
OK?
Abdel.
Index: FileDialog.cpp
===
Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but using
native file dialog on Windows in order to fix bug 3907 (File - Open
dialog needs many seconds before it opens).
Sorry, here is a correct patch.
Abdel.
Index: FileDialog.cpp
On Jul 2, 2007, at 7:32 AM, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File
- Open dialog needs many seconds before it opens).
Sorry, here is a
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File
- Open dialog needs many seconds before it opens).
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File
- Open dialog needs many
On Mon, Jul 02, 2007 at 05:02:03PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file
Enrico Forestieri wrote:
On Mon, Jul 02, 2007 at 05:02:03PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
Abdelrazak Younes wrote:
Even though I like our file dialog, I think we have no choice but using
native file dialog on Windows in order to fix bug 3907 (File - Open
dialog needs many seconds before it opens).
There are more bugs related to the Qt file dialog. Sometimes it doesn't
even show
Nope, I use Qt4.2.1 so Qt4.2 _is_ impacted. I do not know about Qt4.3. Uwe,
Edwin, Joost, Peter,
do you use Qt4.3?
Due to various Qt bugs I still use Qt 4.2.2.
But your patch is THE solution for one of the most annoying problems with LyX 1.5 on Windows,
according how often this was reported
Hello,
Even though I like our file dialog, I think we have no choice but using
native file dialog on Windows in order to fix bug 3907 (File -> Open
dialog needs many seconds before it opens).
OK?
Abdel.
Index: FileDialog.cpp
Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but using
native file dialog on Windows in order to fix bug 3907 (File -> Open
dialog needs many seconds before it opens).
Sorry, here is a correct patch.
Abdel.
Index: FileDialog.cpp
On Jul 2, 2007, at 7:32 AM, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File
-> Open dialog needs many seconds before it opens).
Sorry, here is a
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
>> Hello,
>>
>> Even though I like our file dialog, I think we have no choice but
>> using native file dialog on Windows in order to fix bug 3907 (File
-> Open dialog needs many seconds
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice but
using native file dialog on Windows in order to fix bug 3907 (File
-> Open dialog needs
On Mon, Jul 02, 2007 at 05:02:03PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> > Abdelrazak> Abdelrazak Younes wrote:
> >>> Hello,
> >>>
> >>> Even though I like our file dialog, I think we have no
Enrico Forestieri wrote:
On Mon, Jul 02, 2007 at 05:02:03PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Abdelrazak Younes wrote:
Hello,
Even though I like our file dialog, I think we have no choice
Abdelrazak Younes wrote:
Even though I like our file dialog, I think we have no choice but using
native file dialog on Windows in order to fix bug 3907 (File -> Open
dialog needs many seconds before it opens).
There are more bugs related to the Qt file dialog. Sometimes it doesn't
even show
> Nope, I use Qt4.2.1 so Qt4.2 _is_ impacted. I do not know about Qt4.3. Uwe,
Edwin, Joost, Peter,
> do you use Qt4.3?
Due to various Qt bugs I still use Qt 4.2.2.
But your patch is THE solution for one of the most annoying problems with LyX 1.5 on Windows,
according how often this was
On 22 Feb 2001, Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| I re-tried purify, but it seems it does not work here anymore. I
| though I'd find a way to get a list of allocated blocks...
|
| Assuming this comes from LyXText, what are the places where such
On 22 Feb 2001, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | I re-tried purify, but it seems it does not work here anymore. I
> | though I'd find a way to get a list of allocated blocks...
> |
> | Assuming this comes from LyXText, what are the places
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | but if you
Lars see memory growth just by moving the cursor in and out of a |
Lars tabular then something is wrong. And this hans nothing to do
Lars with the | size of structures. And
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars [EMAIL PROTECTED] (Lars Gullik Bjnnes) writes: | but if you
| Lars see memory growth just by moving the cursor in and out of a |
| Lars tabular then something is wrong. And this
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I see it by moving the cursor through the tabular.
Lars And I have no memory checker so I can't see where that mem goes.
Lars and for all I know we deallocate the mem properly so a mem
Lars checker might not see it anyway.
I
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| I re-tried purify, but it seems it does not work here anymore. I
| though I'd find a way to get a list of allocated blocks...
|
| Assuming this comes from LyXText, what are the places where such
| structures can be kept, besides TextCache?
Note
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | but if you
Lars> see memory growth just by moving the cursor in and out of a |
Lars> tabular then something is wrong. And this hans nothing to do
Lars> with the | size of
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | but if you
| Lars> see memory growth just by moving the cursor in and out of a |
| Lars> tabular then something is
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I see it by moving the cursor through the tabular.
Lars> And I have no memory checker so I can't see where that mem goes.
Lars> and for all I know we deallocate the mem properly so a mem
Lars> checker might not see it anyway.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| I re-tried purify, but it seems it does not work here anymore. I
| though I'd find a way to get a list of allocated blocks...
|
| Assuming this comes from LyXText, what are the places where such
| structures can be kept, besides TextCache?
On 09-Feb-2001 Jean-Marc Lasgouttes wrote:
Step 1.2.0cvs 1.2.0cvspatched1.0.3
1 1M 1M 7856K
2 26M 25M 8096K
3 41M 39M n/a
4 52M 50M 8552K
Step 2 tells us that
"Juergen" == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen On 09-Feb-2001 Jean-Marc Lasgouttes wrote:
Step 1.2.0cvs 1.2.0cvspatched 1.0.3 1 1M 1M 7856K 2 26M 25M 8096K
3 41M 39M n/a 4 52M 50M 8552K
Step 2 tells us that we have a cost per cell of about 10k for a
tabular. This seems a
On 12-Feb-2001 Jean-Marc Lasgouttes wrote:
Juergen No IMO the problem is that a LyXText object is allocated at
Juergen that time!
That's what I meant, in fact. Presumably, if the code needs to
allocate a new LyXText for the table, there also an old one in the
cache that should go away.
"Juergen" == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen There is a cache but not in the tabular-inset, it's the
Juergen InsetText which needs the LyXText and that is one per
Juergen BufferView (which currently is fixed to 1 ;). So there is 1
Juergen LyXText for each BufferView for each
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars Or lessen the mem consumption for a LyXText.
|
| What makes the bunch of the size of a LyXText?
An empty LyXText is some ~300 bytes.
Most of this is in different LyXCursors
|
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED]
Lars writes: | | Lars Or lessen the mem consumption for a LyXText. |
Lars | What makes the bunch of the size of a LyXText?
Lars An
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
|
| Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
| Lars "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED]
| Lars writes: | | Lars Or lessen the mem consumption for a LyXText. |
| Lars
[EMAIL PROTECTED] (Lars Gullik Bjnnes) writes:
| but if you see memory growth just by moving the cursor in and out of a
| tabular then something is wrong. And this hans nothing to do with the
| size of structures. And purify will not handle a memory leak that is
| handled...
There is
On Mon, 12 Feb 2001, Juergen Vigna wrote:
Yes, the 1.2.0cvspatched is just that. One gains 2M (to compare with
memory consumption of around 50M!). This means that undo is really not
much, compared to lyxtext.
Ok this means we have to find a way to only use 1 LyXText instance, but
how
On 09-Feb-2001 Jean-Marc Lasgouttes wrote:
>
> Step 1.2.0cvs 1.2.0cvspatched1.0.3
> 1 1M 1M 7856K
> 2 26M 25M 8096K
> 3 41M 39M n/a
> 4 52M 50M 8552K
>
> Step 2 tells
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> On 09-Feb-2001 Jean-Marc Lasgouttes wrote:
>> Step 1.2.0cvs 1.2.0cvspatched 1.0.3 1 1M 1M 7856K 2 26M 25M 8096K
>> 3 41M 39M n/a 4 52M 50M 8552K
>>
>> Step 2 tells us that we have a cost per cell of about 10k for a
>>
On 12-Feb-2001 Jean-Marc Lasgouttes wrote:
>
> Juergen> No IMO the problem is that a LyXText object is allocated at
> Juergen> that time!
>
> That's what I meant, in fact. Presumably, if the code needs to
> allocate a new LyXText for the table, there also an old one in the
> cache that should
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
Juergen> There is a cache but not in the tabular-inset, it's the
Juergen> InsetText which needs the LyXText and that is one per
Juergen> BufferView (which currently is fixed to 1 ;). So there is 1
Juergen> LyXText for each BufferView
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Or lessen the mem consumption for a LyXText.
|
| What makes the bunch of the size of a LyXText?
An empty LyXText is some ~300 bytes.
Most of this is in different
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]>
Lars> writes: | | Lars> Or lessen the mem consumption for a LyXText. |
Lars> | What makes the bunch of the size
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]>
| Lars> writes: | | Lars> Or lessen the mem consumption
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| but if you see memory growth just by moving the cursor in and out of a
| tabular then something is wrong. And this hans nothing to do with the
| size of structures. And purify will not handle a memory leak that is
| handled...
There is
On Mon, 12 Feb 2001, Juergen Vigna wrote:
> > Yes, the 1.2.0cvspatched is just that. One gains 2M (to compare with
> > memory consumption of around 50M!). This means that undo is really not
> > much, compared to lyxtext.
>
> Ok this means we have to find a way to only use 1 LyXText instance,
On 09-Feb-2001 Lars Gullik Bjnnes wrote:
| Thus the reserved text buffer accounts for less than 2/3 of the memory
| use. Not to say that we shouldn't reduce it, but perhaps we can find some
| ways to save more space. E.g. not allocate anything until the user
| actually puts something in the
On 09-Feb-2001 Lars Gullik Bjønnes wrote:
>
>| Thus the reserved text buffer accounts for less than 2/3 of the memory
>| use. Not to say that we shouldn't reduce it, but perhaps we can find some
>| ways to save more space. E.g. not allocate anything until the user
>| actually puts something
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Dekel" == Dekel Tsur [EMAIL PROTECTED] writes:
|
| Dekel The memory consumption can be (slightly) reduced by deleting
| Dekel the line text.reserve(500) in LyXParagraph::LyXParagraph.
|
| In the example we had, a 50x50 array consumes 1.2M
Lior Silberman [EMAIL PROTECTED] writes:
| What about using different values in different contexts - table cells
| usually have less text than run-of-the-mill paragraphs. Add an extra
| constr. to LyXParagraph getting an 'enum ExpectedSize' value (Tiny, Small,
| ...) and reserve memory
"Lior" == Lior Silberman [EMAIL PROTECTED] writes:
Lior Thus the reserved text buffer accounts for less than 2/3 of the
Lior memory use. Not to say that we shouldn't reduce it, but perhaps
Lior we can find some ways to save more space. E.g. not allocate
Lior anything until the user actually
On Fri, Feb 09, 2001 at 09:42:10AM +0100, Lars Gullik Bjønnes wrote:
| I'll do experiments tomorrow if nobody beats me to it. What was the
| initial reason for the reserve(500)? speed?
Actually both speed and memory consumption. Primarily speed.
I still claim that it doesn't give any speed
Dekel Tsur [EMAIL PROTECTED] writes:
| On Fri, Feb 09, 2001 at 09:42:10AM +0100, Lars Gullik Bjnnes wrote:
| | I'll do experiments tomorrow if nobody beats me to it. What was the
| | initial reason for the reserve(500)? speed?
|
| Actually both speed and memory consumption. Primarily speed.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
|
| Dekel> The memory consumption can be (slightly) reduced by deleting
| Dekel> the line text.reserve(500) in LyXParagraph::LyXParagraph.
|
| In the example we had, a 50x50 array
Lior Silberman <[EMAIL PROTECTED]> writes:
| What about using different values in different contexts - table cells
| usually have less text than run-of-the-mill paragraphs. Add an extra
| constr. to LyXParagraph getting an 'enum ExpectedSize' value (Tiny, Small,
| ...) and reserve memory
> "Lior" == Lior Silberman <[EMAIL PROTECTED]> writes:
Lior> Thus the reserved text buffer accounts for less than 2/3 of the
Lior> memory use. Not to say that we shouldn't reduce it, but perhaps
Lior> we can find some ways to save more space. E.g. not allocate
Lior> anything until the user
On Fri, Feb 09, 2001 at 09:42:10AM +0100, Lars Gullik Bjønnes wrote:
> | I'll do experiments tomorrow if nobody beats me to it. What was the
> | initial reason for the reserve(500)? speed?
>
> Actually both speed and memory consumption. Primarily speed.
I still claim that it doesn't give any
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Fri, Feb 09, 2001 at 09:42:10AM +0100, Lars Gullik Bjønnes wrote:
| > | I'll do experiments tomorrow if nobody beats me to it. What was the
| > | initial reason for the reserve(500)? speed?
| >
| > Actually both speed and memory consumption. Primarily
1 - 100 of 127 matches
Mail list logo
