Le 19/10/2015 20:57, Georg Baum a écrit :
I archive this in a bug report?
Yes please.
http://www.lyx.org/trac/ticket/9804
Guillaume Munch wrote:
> I hope I did not put you on a wrong track with my reference to the gcc-5
> bug, which was more of a joke (because the the conditions to trigger it
> were *the contrary*).
No problem. It made me think a bit, but I did not waist any time.
> It displays more resemblance wit
Le 19/10/2015 20:32, Georg Baum a écrit :
Guillaume Munch wrote:
The choice is simple, because just adding a new variable member to math
insets as per the attached (trivial) .diff leads to new segfaults with
math macros. The .diff must be applied to current master (before or
after my upcoming T
Guillaume Munch wrote:
> Le 17/10/2015 21:19, Guillaume Munch a écrit :
>>
>> I thought about that, but I do not want to introduce a divergence in the
>> behaviour of release mode compared to devel mode in a fundamental
>> aspect. This can open the door to a lot of problems: unreproducibility
>> o
Guillaume Munch wrote:
> The choice is simple, because just adding a new variable member to math
> insets as per the attached (trivial) .diff leads to new segfaults with
> math macros. The .diff must be applied to current master (before or
> after my upcoming TexRow patches). Compiler is g++ 4.9.2
Le 19/10/2015 17:21, Guillaume Munch a écrit :
Ok. I tried to go that route, but then figured that I had to adapt the
code for copy/paste, duplicate row/column, etc. which I tried to avoid.
I can understand that :)
JMarc
Le 19/10/2015 09:54, Jean-Marc Lasgouttes a écrit :
Le 15/10/15 19:32, Guillaume Munch a écrit :
Jean-Marc's comment seems to be: sometimes we would like the id to
remain the same (which indeed would not be taken into account by the
current patch). Jean-Marc, did I understand you remark correctl
Le 15/10/15 19:32, Guillaume Munch a écrit :
Jean-Marc's comment seems to be: sometimes we would like the id to
remain the same (which indeed would not be taken into account by the
current patch). Jean-Marc, did I understand you remark correctly and if
so, do you have an example in mind?
We do
Le 17/10/2015 21:19, Guillaume Munch a écrit :
Le 17/10/2015 15:13, Richard Heck a écrit :
On 10/16/2015 12:34 PM, Guillaume Munch wrote:
The id is now only on InsetMathNest. Please, tell me if you still feel
uncomfortable about this id and I will try a version with pointer
comparison. This in
Le 17/10/2015 12:00, Georg Baum a écrit :
Guillaume Munch wrote:
But if the memory usage is still too high, various solutions:
* pointer comparison (what is your opinion on pointer comparison vs.
using a counter?)
* variable-length integers encoding.
* pointer comparison, but somehow keep the po
Le 17/10/2015 15:13, Richard Heck a écrit :
On 10/16/2015 12:34 PM, Guillaume Munch wrote:
The id is now only on InsetMathNest. Please, tell me if you still feel
uncomfortable about this id and I will try a version with pointer
comparison. This incremental id, I found, gives interesting clues i
Le 17/10/2015 12:00, Georg Baum a écrit :
Sorry, I don't have the time right now to really measure, but I think it is
not needed, since the numbers you got are OK IMHO.
… As I see it, we do now have
a trade off between easier debugging (ids), and less memory consumption
(pointers). Apart from t
On 10/16/2015 12:34 PM, Guillaume Munch wrote:
The id is now only on InsetMathNest. Please, tell me if you still feel
uncomfortable about this id and I will try a version with pointer
comparison. This incremental id, I found, gives interesting clues in
debug mode when trying to understand how
Guillaume Munch wrote:
> Le 16/10/2015 21:52, Georg Baum a écrit :
>> Guillaume Munch wrote:
>>
>>> I did not realise that there were supposed to be so many InsetMaths live
>>> at the same time. Although the increased memory use is quite small for
>>> modern standard, I agree that it is a bad idea
Le 16/10/2015 21:52, Georg Baum a écrit :
Guillaume Munch wrote:
Le 14/10/2015 21:35, Georg Baum a écrit :
Please measure memory consumption. I am a bit afraid that this increases
memory usage a lot, since math insets contain very tiny bits of
information, and you may need _lots_ of them even
Guillaume Munch wrote:
> Le 14/10/2015 21:35, Georg Baum a écrit :
>>
>> Please measure memory consumption. I am a bit afraid that this increases
>> memory usage a lot, since math insets contain very tiny bits of
>> information, and you may need _lots_ of them even for simple formula.
>
> I did n
On Fri, Oct 16, 2015 at 08:06:02PM +0100, Guillaume Munch wrote:
> Le 16/10/2015 19:57, Scott Kostyshak a écrit :
> >On Fri, Oct 16, 2015 at 05:34:33PM +0100, Guillaume Munch wrote:
> >
> >>Scott, I would like to commit this series of patches before α. What is the
> >>time frame?
> >
> >I would lik
Le 16/10/2015 19:57, Scott Kostyshak a écrit :
On Fri, Oct 16, 2015 at 05:34:33PM +0100, Guillaume Munch wrote:
Scott, I would like to commit this series of patches before α. What is the
time frame?
I would like to release the alpha early next week. JMarc has a pending
patch. Günter has many
On Fri, Oct 16, 2015 at 05:34:33PM +0100, Guillaume Munch wrote:
> Scott, I would like to commit this series of patches before α. What is the
> time frame?
I would like to release the alpha early next week. JMarc has a pending
patch. Günter has many patches that would be nice to have in alpha. I'
Le 15/10/2015 18:26, Guillaume Munch a écrit :
Why do you need a new member variable at all? Why can't you just use the
memory address? This would not consume memory and still be a unique id.
Yes, it would make sense to use pointers IMO. There was two reasons for
the UniqueId class: I needed t
Le 15/10/2015 18:20, Georg Baum a écrit :
Jean-Marc Lasgouttes wrote:
Why do you need a new member variable at all? Why can't you just use the
memory address? This would not consume memory and still be a unique id.
I guess that the answer is the same as for paragraph ids: they can get
copied
Le 14/10/2015 21:35, Georg Baum a écrit :
*#2: Add a unique id to math insets. I also print this information in
the DEVEL_VERSION in the status bar similarly to what is done currently
for paragraphs. It is interesting that while the paragraph id is usually
below 1, this new math inset id imm
Jean-Marc Lasgouttes wrote:
>> Why do you need a new member variable at all? Why can't you just use the
>> memory address? This would not consume memory and still be a unique id.
>
> I guess that the answer is the same as for paragraph ids: they can get
> copied at unexpected times.
If my unders
Le 14/10/15 22:35, Georg Baum a écrit :
*#2: Add a unique id to math insets.
Please measure memory consumption. I am a bit afraid that this increases
memory usage a lot, since math insets contain very tiny bits of information,
and you may need _lots_ of them even for simple formula.
I agree w
Guillaume Munch wrote:
> I submit it on the list to get your agreement on several fundamental
> changes which I kept, as you will see, as little intrusive as possible.
Wow, these are lots of changes. I am running out of time and will only
comment on some.
> The sensitive changes (i.e. where I h
Dear list,
This is a series of patches that bring various improvements to the
cursor<->row correspondence tracking (TexRow). It is now extended to
arbitrary nestings of math, and to tables and subcaptions.
Jean-Marc, no improvement to error reporting and reverse search yet,
sorry :) I had to po
26 matches
Mail list logo
