On Sun, Feb 23, 2020 at 05:00:43PM -0500, Richard Kimberly Heck wrote:
> On 2/23/20 4:11 PM, Scott Kostyshak wrote:
> > On Sun, Feb 23, 2020 at 03:54:06PM -0500, Richard Kimberly Heck wrote:
> >> On 2/23/20 2:31 PM, Scott Kostyshak wrote:
> >>> On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard
On 2/23/20 4:11 PM, Scott Kostyshak wrote:
> On Sun, Feb 23, 2020 at 03:54:06PM -0500, Richard Kimberly Heck wrote:
>> On 2/23/20 2:31 PM, Scott Kostyshak wrote:
>>> On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote:
On 2/23/20 8:23 AM, Scott Kostyshak wrote:
> On Tue,
On Sun, Feb 23, 2020 at 03:54:06PM -0500, Richard Kimberly Heck wrote:
> On 2/23/20 2:31 PM, Scott Kostyshak wrote:
> > On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote:
> >> On 2/23/20 8:23 AM, Scott Kostyshak wrote:
> >>> On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott
On 2/23/20 2:31 PM, Scott Kostyshak wrote:
> On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote:
>> On 2/23/20 8:23 AM, Scott Kostyshak wrote:
>>> On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote:
On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly
On Sun, Feb 23, 2020 at 12:50:42PM -0500, Richard Kimberly Heck wrote:
> On 2/23/20 8:23 AM, Scott Kostyshak wrote:
> > On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote:
> >> On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote:
> >>> On 2/18/20 6:07 PM, Scott
On 2/23/20 8:23 AM, Scott Kostyshak wrote:
> On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote:
>> On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote:
>>> On 2/18/20 6:07 PM, Scott Kostyshak wrote:
Valgrind gave me the following error:
==732== 112
On Tue, Feb 18, 2020 at 08:28:33PM -0500, Scott Kostyshak wrote:
> On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote:
> > On 2/18/20 6:07 PM, Scott Kostyshak wrote:
> > > Valgrind gave me the following error:
> > >
> > > ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks
On Wed, Feb 19, 2020 at 08:52:18AM +, Neven Sajko wrote:
> > Well, actually the hardest part is waiting because LyX is very slow when
> > run under valgrind.
>
> Try sanitizers instead. They are instrumentation that GCC or Clang can
> include in executables. They do basically the same thing
My instructions for the C compiler and linker command line were wrong:
instead of -fsanitize=asan , use -fsanitize=address or
-fsanitize=thread or -fsanitize=undefined or -fsanitize=memory .
And, of course, include debugging symbols with "-g".
Regards,
Neven Sajko
--
lyx-devel mailing list
> Well, actually the hardest part is waiting because LyX is very slow when run
> under valgrind.
Try sanitizers instead. They are instrumentation that GCC or Clang can
include in executables. They do basically the same thing as Valgrind,
but should be much faster and since you are already
On Tue, Feb 18, 2020 at 07:33:39PM -0500, Richard Kimberly Heck wrote:
> On 2/18/20 6:07 PM, Scott Kostyshak wrote:
> > Valgrind gave me the following error:
> >
> > ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks are definitely
> > lost in loss record 5,165 of 5,862
> > ==732==at
On 2/18/20 6:07 PM, Scott Kostyshak wrote:
> Valgrind gave me the following error:
>
> ==732== 112 (72 direct, 40 indirect) bytes in 1 blocks are definitely lost
> in loss record 5,165 of 5,862
> ==732==at 0x483AE63: operator new(unsigned long) (in
>
Hi Guillaume,
I thought about it again, and you are right, of course.
JMarc
Le 24 février 2017 22:10:17 GMT+01:00, Guillaume Munch a écrit :
>Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit :
>> It would be nice to hide these subtleties in the Cache
>implementation,
>> if
Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit :
Le 21/02/2017 à 20:13, Guillaume Munch a écrit :
BTW, why don't you use Cache::contains in getLayout like you do for
other cache uses?
This is explained in the documentation of Cache::object. It is enough to
check for a null pointer in
Le 23/02/2017 à 18:05, Richard Heck a écrit :
Here is for reference the updated patch (even with comment
clarification). Richard?
OK. I'll test it over the next couple weeks, and if all is well move
toward 2.2.3.
rh
Done at 998c3e7c8ef. There is no status.22x entry, since this is a fix
On 02/23/2017 04:46 AM, Jean-Marc Lasgouttes wrote:
> Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit :
>> Indeed. Richard, I think this patch should go in 2.2.3, because the
>> caching code that is in stable causes bad memory leaks with Qt5.
>
> Here is for reference the updated patch (even
On 02/23/2017 04:46 AM, Jean-Marc Lasgouttes wrote:
> Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit :
>> Indeed. Richard, I think this patch should go in 2.2.3, because the
>> caching code that is in stable causes bad memory leaks with Qt5.
>
> Here is for reference the updated patch (even
Le 22/02/2017 à 18:03, Jean-Marc Lasgouttes a écrit :
Indeed. Richard, I think this patch should go in 2.2.3, because the
caching code that is in stable causes bad memory leaks with Qt5.
Here is for reference the updated patch (even with comment
clarification). Richard?
JMarc
From
Le 21/02/2017 à 20:13, Guillaume Munch a écrit :
Thanks for doing this. I thought there was some bigger adaptation to the
code to do but indeed it only looks like a matter of C++98 conversion.
You mean it was a trap? It did not work %-p
I think it's all good except:
class Cache : private
Le 21/02/2017 à 07:19, Jean-Marc Lasgouttes a écrit :
Le 21/02/2017 à 00:08, Guillaume Munch a écrit :
Could you do the backport to stable? :)
What about that? Please check especially the code related to
LYX_USE_CXX11 in Cache.h. For the caching, I re-read the code to make
sure that my
Le 20/02/2017 à 18:25, Jean-Marc Lasgouttes a écrit :
Le 10/02/2017 à 17:58, Guillaume Munch a écrit :
There's more data, but I am not sure how to interpret the results that
massif-visualizer shows.
If you send the file or make it available, I can take a look.
Here it is. But if it is like
Le 21/02/2017 à 00:08, Guillaume Munch a écrit :
Could you do the backport to stable? :)
What about that? Please check especially the code related to
LYX_USE_CXX11 in Cache.h. For the caching, I re-read the code to make
sure that my hand-merging was correct, I hope I did not miss anything.
Le 21/02/2017 à 00:08, Guillaume Munch a écrit :
Le 20/02/2017 à 18:27, Jean-Marc Lasgouttes a écrit :
Le 13/02/2017 à 20:55, Jean-Marc Lasgouttes a écrit :
What I mean is that you can easily force
QCache into shared ownership by replacing
QCache
with
Le 20/02/2017 à 18:27, Jean-Marc Lasgouttes a écrit :
Le 13/02/2017 à 20:55, Jean-Marc Lasgouttes a écrit :
What I mean is that you can easily force
QCache into shared ownership by replacing
QCache
with
QCache
and create the appropriate
Le 13/02/2017 à 20:55, Jean-Marc Lasgouttes a écrit :
What I mean is that you can easily force
QCache into shared ownership by replacing
QCache
with
QCache
and create the appropriate wrappers for insertion and retrieval.
Could you have
Le 10/02/2017 à 17:58, Guillaume Munch a écrit :
There's more data, but I am not sure how to interpret the results that
massif-visualizer shows.
If you send the file or make it available, I can take a look.
Here it is. But if it is like callgrind, it might lack the symbols.
Interestingly,
Le 31/12/2016 à 15:42, Guillaume Munch a écrit :
Snippet of Valgrind output for stable below. The WordList object created
in theWordList() never gets deleted, although QThreadStorage is supposed
to be automagic.
According to the docs, the GlobalWordLists were deleted with the
QApplication,
Le 31/12/2016 à 13:16, Jean-Marc Lasgouttes a écrit :
WordList leaks all its contents on exit, which is very impolite (even
though the memory will be reclaimed anyway). This hides real memory
leaks that may happen elsewhere.
Snippet of Valgrind output for stable below. The WordList object
Am 22.01.2012 um 21:58 schrieb Jean-Marc Lasgouttes:
Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit :
My testing so far says the opposite. We are continually using more and
more memory. Not especially fast, but it is there.
A good tool to know where memory goes is the massif tool of
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
Like what Stephan reported, we see:
fantomas: ms_print massif.out.24204|grep
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
Like what Stephan reported, we see:
Op 23-1-2012 15:54, Richard Heck schreef:
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote:
Op 23-1-2012 15:54, Richard Heck schreef:
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of
valgrind.
This is the result
Am 22.01.2012 um 21:58 schrieb Jean-Marc Lasgouttes:
> Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit :
>> My testing so far says the opposite. We are continually using more and
>> more memory. Not especially fast, but it is there.
>
> A good tool to know where memory goes is the massif tool of
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
Like what Stephan reported, we see:
fantomas: ms_print massif.out.24204|grep
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
Like what Stephan reported, we see:
Op 23-1-2012 15:54, Richard Heck schreef:
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of valgrind.
This is the result from a ~6hrs run.
I am not quite sure how to read it.
On 01/23/2012 12:04 PM, Vincent van Ravesteijn wrote:
Op 23-1-2012 15:54, Richard Heck schreef:
On 01/23/2012 05:53 AM, Jean-Marc Lasgouttes wrote:
Le 23/01/2012 10:56, Lars Gullik Bjønnes a écrit :
| A good tool to know where memory goes is the massif tool of
valgrind.
This is the result
Richard Heck rgh...@comcast.net writes:
| On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote:
Richard Heckrgh...@comcast.net writes:
| On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote:
Hello,
A French user tells me privately that he finds a big memeory leak in
LyX-2.0.2 on an Archlinux
Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit :
My testing so far says the opposite. We are continually using more and
more memory. Not especially fast, but it is there.
A good tool to know where memory goes is the massif tool of valgrind.
JMarc
Richard Heck writes:
| On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote:
>> Richard Heck writes:
>>
>> | On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote:
Hello,
A French user tells me privately that he finds a big memeory leak in
Le 22/01/12 02:09, Lars Gullik Bjønnes a écrit :
My testing so far says the opposite. We are continually using more and
more memory. Not especially fast, but it is there.
A good tool to know where memory goes is the massif tool of valgrind.
JMarc
Jean-Pierre Chrétien jeanpierre.chretien at free.fr writes:
I find no leak with Lyx-1.6.10, and an much smaller one (identical for each)
of 0.28ko/mn with Lyx-2.0.2 and 2.0.1.
I meant Lyx-2.0.0 and 2.0.1, sorry.
--
Jean-Pierre
Jean-Pierre Chrétien jeanpierre.chret...@free.fr writes:
| Hello,
| A French user tells me privately that he finds a big memeory leak in
| LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn).
| On my Debian Squeeze and a simple document, I find about 1.7ko/mn.
| Testing with the
On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote:
Hello,
A French user tells me privately that he finds a big memeory leak in
LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn).
On my Debian Squeeze and a simple document, I find about 1.7ko/mn.
Testing with the Userguide, I find
On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote:
Richard Heckrgh...@comcast.net writes:
| On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote:
Hello,
A French user tells me privately that he finds a big memeory leak in
LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn).
On my
Jean-Pierre Chrétien free.fr> writes:
> I find no leak with Lyx-1.6.10, and an much smaller one (identical for each)
> of 0.28ko/mn with Lyx-2.0.2 and 2.0.1.
I meant Lyx-2.0.0 and 2.0.1, sorry.
--
Jean-Pierre
Jean-Pierre Chrétien writes:
| Hello,
>
| A French user tells me privately that he finds a big memeory leak in
| LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn).
>
| On my Debian Squeeze and a simple document, I find about 1.7ko/mn.
>
| Testing with the
On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote:
Hello,
A French user tells me privately that he finds a big memeory leak in
LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn).
On my Debian Squeeze and a simple document, I find about 1.7ko/mn.
Testing with the Userguide, I find
On 01/21/2012 08:09 PM, Lars Gullik Bjønnes wrote:
Richard Heck writes:
| On 01/21/2012 05:36 AM, Jean-Pierre Chrétien wrote:
Hello,
A French user tells me privately that he finds a big memeory leak in
LyX-2.0.2 on an Archlinux LyX distribution (about 1.5Mo/mn).
On my
rgheck wrote:
On 08/10/2009 05:01 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a =
b, a will be a shadow copy of b up until it is modified, thus
occupying zero
On 08/11/2009 03:40 AM, Abdelrazak Younes wrote:
So, if setPixmap() returns true, then can't we do something like
reset() the cached_item_ and just get rid if that QImage?
You can try. Last time I did, I failed. But I was so upset about this
piece of code that maybe the solution was much
rgheck wrote:
On 08/10/2009 05:01 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a =
b, a will be a shadow copy of b up until it is modified, thus
occupying zero
On 08/11/2009 03:40 AM, Abdelrazak Younes wrote:
So, if setPixmap() returns true, then can't we do something like
reset() the cached_item_ and just get rid if that QImage?
You can try. Last time I did, I failed. But I was so upset about this
piece of code that maybe the solution was much
On 10/08/2009 21:34, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small scale is of no help
and more print-ready image
On 10/08/2009 21:39, Abdelrazak Younes wrote:
On 10/08/2009 21:34, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small
Abdelrazak Younes wrote:
Very intricate!
The problem is not coming from Qt but from our own caching mechanism which
is heavy and is redundant with Qt own caching system. Last time I tried to
clean up this mess I stopped at this issue with a big headache... The only
sane solution is to get
On 10/08/2009 21:46, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Very intricate!
The problem is not coming from Qt but from our own caching mechanism which
is heavy and is redundant with Qt own caching system. Last time I tried to
clean up this mess I stopped at this issue with a big
Abdelrazak Younes wrote:
but my question is simpler now:
why should original_ = QImage(); release the memory as the comment above
says?
if not what would be correct way of releasing it?
This code works and is not the problem. I don't remember the details but
the original image is
On 10/08/2009 21:55, Pavel Sanda wrote:
Abdelrazak Younes wrote:
but my question is simpler now:
why should original_ = QImage(); release the memory as the comment above
says?
if not what would be correct way of releasing it?
This code works and is not the problem. I don't
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the details but
the original image is also stored somewhere else in the graphics cache,
AFAIR.
which doesn't help me to understand what '// Clear the pixmap to save some
memory'
means :)
It
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the details but
the original image is also stored somewhere else in the graphics cache,
AFAIR.
which doesn't help me to understand what '// Clear the pixmap
On 08/10/2009 04:16 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the
details but
the original image is also stored somewhere else in the graphics
cache,
AFAIR.
which doesn't help me to
On 10/08/2009 22:18, rgheck wrote:
On 08/10/2009 04:16 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the
details but
the original image is also stored somewhere else in the graphics
On Mon, Aug 10, 2009 at 09:34:00PM +0200, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small scale is of no help
and
Abdelrazak Younes wrote:
QPixmap are implicitly shared.
this was the missing brick.. thanks
pavel
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b, a
will be a shadow copy of b up until it is modified, thus occupying
zero additional memory. This is the same concept as shared pointer,
the object, and thus the memory, is not
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b,
a will be a shadow copy of b up until it is modified, thus occupying
zero additional memory. This is the same concept as shared pointer,
the
On 08/10/2009 05:01 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b,
a will be a shadow copy of b up until it is modified, thus occupying
zero additional
Richard Heck wrote:
My thought was more simpleminded, but I don't know this code. Why do we
need a cache of the original image once the pixmap has been set? If the
original is changed, then presumably we want to reload. But if it doesn't
change, we don't need access to it any more, do we?
On 08/10/2009 06:23 PM, Pavel Sanda wrote:
Richard Heck wrote:
My thought was more simpleminded, but I don't know this code. Why do we
need a cache of the original image once the pixmap has been set? If the
original is changed, then presumably we want to reload. But if it doesn't
change, we
On 10/08/2009 21:34, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small scale is of no help
and more print-ready image
On 10/08/2009 21:39, Abdelrazak Younes wrote:
On 10/08/2009 21:34, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small
Abdelrazak Younes wrote:
> Very intricate!
>
> The problem is not coming from Qt but from our own caching mechanism which
> is heavy and is redundant with Qt own caching system. Last time I tried to
> clean up this mess I stopped at this issue with a big headache... The only
> sane solution is
On 10/08/2009 21:46, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Very intricate!
The problem is not coming from Qt but from our own caching mechanism which
is heavy and is redundant with Qt own caching system. Last time I tried to
clean up this mess I stopped at this issue with a big
Abdelrazak Younes wrote:
>> but my question is simpler now:
>> why should original_ = QImage(); release the memory as the comment above
>> says?
>> if not what would be correct way of releasing it?
>>
>
> This code works and is not the problem. I don't remember the details but
> the original
On 10/08/2009 21:55, Pavel Sanda wrote:
Abdelrazak Younes wrote:
but my question is simpler now:
why should original_ = QImage(); release the memory as the comment above
says?
if not what would be correct way of releasing it?
This code works and is not the problem. I don't
Abdelrazak Younes wrote:
>>> This code works and is not the problem. I don't remember the details but
>>> the original image is also stored somewhere else in the graphics cache,
>>> AFAIR.
>>>
>>
>> which doesn't help me to understand what '// Clear the pixmap to save some
>> memory'
>>
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the details but
the original image is also stored somewhere else in the graphics cache,
AFAIR.
which doesn't help me to understand what '// Clear the pixmap
On 08/10/2009 04:16 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the
details but
the original image is also stored somewhere else in the graphics
cache,
AFAIR.
which doesn't help me to
On 10/08/2009 22:18, rgheck wrote:
On 08/10/2009 04:16 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the
details but
the original image is also stored somewhere else in the graphics
On Mon, Aug 10, 2009 at 09:34:00PM +0200, Pavel Sanda wrote:
> hi,
> for the third time my system get frozen because of
> bug http://www.lyx.org/trac/ticket/5002.
>
> it seems when we load eg. jpg image to cache and rescale it, the
> original image is not forgoten so even small scale is of no
Abdelrazak Younes wrote:
> QPixmap are implicitly shared.
this was the missing brick.. thanks
pavel
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b, a
will be a shadow copy of b up until it is modified, thus occupying
zero additional memory. This is the same concept as shared pointer,
the object, and thus the memory, is not
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b,
a will be a shadow copy of b up until it is modified, thus occupying
zero additional memory. This is the same concept as shared pointer,
the
On 08/10/2009 05:01 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b,
a will be a shadow copy of b up until it is modified, thus occupying
zero additional
Richard Heck wrote:
> My thought was more simpleminded, but I don't know this code. Why do we
> need a cache of the original image once the pixmap has been set? If the
> original is changed, then presumably we want to reload. But if it doesn't
> change, we don't need access to it any more, do
On 08/10/2009 06:23 PM, Pavel Sanda wrote:
Richard Heck wrote:
My thought was more simpleminded, but I don't know this code. Why do we
need a cache of the original image once the pixmap has been set? If the
original is changed, then presumably we want to reload. But if it doesn't
change, we
Andre Poenitz wrote:
On Mon, Dec 03, 2007 at 11:00:00PM +0100, Peter Kümmel wrote:
Playing around with vld I came to the conclusion
that there is a memory leak in Qt's plugin system.
When I trace the allocations of Qt
(see ForceIncludeModules in the vld.ini file)
I get attached output after
On Sun, Dec 09, 2007 at 01:25:35PM +0100, Peter Kümmel wrote:
#define Q_PLUGIN_INSTANCE(IMPLEMENTATION) \
{ \
static
QT_PREPEND_NAMESPACE(QPointer)QT_PREPEND_NAMESPACE(QObject) _instance;
\
if (!_instance) \
_instance = new
Andre Poenitz wrote:
On Mon, Dec 03, 2007 at 11:00:00PM +0100, Peter Kümmel wrote:
Playing around with vld I came to the conclusion
that there is a memory leak in Qt's plugin system.
When I trace the allocations of Qt
(see ForceIncludeModules in the vld.ini file)
I get attached output after
On Sun, Dec 09, 2007 at 01:25:35PM +0100, Peter Kümmel wrote:
>>> #define Q_PLUGIN_INSTANCE(IMPLEMENTATION) \
>>> { \
>>> static
>>> QT_PREPEND_NAMESPACE(QPointer) _instance;
>>> \
>>> if (!_instance) \
>>>
On Mon, Dec 03, 2007 at 11:00:00PM +0100, Peter Kümmel wrote:
Playing around with vld I came to the conclusion
that there is a memory leak in Qt's plugin system.
When I trace the allocations of Qt
(see ForceIncludeModules in the vld.ini file)
I get attached output after just opening and
On Mon, Dec 03, 2007 at 11:00:00PM +0100, Peter Kümmel wrote:
> Playing around with vld I came to the conclusion
> that there is a memory leak in Qt's plugin system.
>
> When I trace the allocations of Qt
> (see ForceIncludeModules in the vld.ini file)
> I get attached output after just opening
On Friday 09 March 2001 18:20, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| On Friday 09 March 2001 17:04, Angus Leeming wrote:
| and there's more. If I save a file with an external inset, close it and
then
| open it again, I get the message:
|
| Solitary
On Friday 09 March 2001 18:20, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | On Friday 09 March 2001 17:04, Angus Leeming wrote:
> | and there's more. If I save a file with an external inset, close it and
then
> | open it again, I get the message:
> |
> |
On Friday 09 March 2001 16:48, Angus Leeming wrote:
When "View Result" of the Date command in the external inset popup, I get
an
error message
LyX: execvp failed: No such file or directory
and an xterm pops up displaying the message
xterm: Can't execvp less
aleem@pneumon:PROPOSALS-
On Friday 09 March 2001 17:04, Angus Leeming wrote:
and there's more. If I save a file with an external inset, close it and then
open it again, I get the message:
Solitary \end_inset. Missing \begin_inset?.
Last inset read was: External
While
Angus Leeming [EMAIL PROTECTED] writes:
| On Friday 09 March 2001 17:04, Angus Leeming wrote:
| and there's more. If I save a file with an external inset, close it and then
| open it again, I get the message:
|
| Solitary \end_inset. Missing \begin_inset?.
| Last inset read was: External
On Friday 09 March 2001 16:48, Angus Leeming wrote:
> When "View Result" of the Date command in the external inset popup, I get
an
> error message
>
> LyX: execvp failed: No such file or directory
>
> and an xterm pops up displaying the message
>
> xterm: Can't execvp less
>
1 - 100 of 104 matches
Mail list logo