Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck rgh...@comcast.net: What the usual calls to updateBuffer() do is always make the macro context a ParIterator that points to the first paragraph in the current inset. (See e.g. the calls at InsetText:682,695.) ok. makes me wonder though why it is necessary to set the macro context

Re: [DIAGNOSIS] Re: crash in trunk

On 04/24/2011 06:02 AM, Edwin Leuven wrote: Richard Heckrgh...@comcast.net: What the usual calls to updateBuffer() do is always make the macro context a ParIterator that points to the first paragraph in the current inset. (See e.g. the calls at InsetText:682,695.) ok. makes me wonder though

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck : > What the usual calls to updateBuffer() do is always > make the macro context a ParIterator that points to > the first paragraph in the current inset. (See e.g. > the calls at InsetText:682,695.) ok. makes me wonder though why it is necessary to set the macro

Re: [DIAGNOSIS] Re: crash in trunk

On 04/24/2011 06:02 AM, Edwin Leuven wrote: Richard Heck: What the usual calls to updateBuffer() do is always make the macro context a ParIterator that points to the first paragraph in the current inset. (See e.g. the calls at InsetText:682,695.) ok. makes me wonder though

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck rgh...@comcast.net wrote: Answer: No, probably not, because it's hard to see how to do this without making copies, which would just give us the same problem back again. the attached avoids the crash for me by setting the macrocontext for nested insets (and only doing the metrics

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 06:56 AM, Edwin Leuven wrote: Richard Heckrgh...@comcast.net wrote: Answer: No, probably not, because it's hard to see how to do this without making copies, which would just give us the same problem back again. the attached avoids the crash for me by setting the macrocontext for

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck rgh...@comcast.net wrote: My main comment would be that I suspect, but of course couldn't verify, due to the crashes, that the same problem exists in the TexRow() output routine, i checked that previewing the document and having the source view pane open worked my guess was that

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 11:45 AM, Edwin Leuven wrote: I wonder if we could try: ParagraphList::const_iterator pit = tail.getText(0)-paragraphs().begin(); buffer().updateBuffer(pit, OutputUpdate); i am not sure i completely follow you, but when i use

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 11:45 AM, Edwin Leuven wrote: I wonder if we could try: ParagraphList::const_iterator pit = tail.getText(0)-paragraphs().begin(); buffer().updateBuffer(pit, OutputUpdate); i am not sure i completely follow you, but when i use

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck rgh...@comcast.net wrote: Can you post this version of the patch and I'll try to have a look? attached I'm wondering where these comparisons are being made and whether we need to do something to the cursor. But I'm really just guessing here. very frustating this poking in the

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck rgh...@comcast.net wrote: I guess the other idea would be to recurse through all the insets. attached, and no more crashes. i think i prefer this solution (although i am not sure we need to add the code to insettext) ed. x3.patch Description: Binary data

Re: [DIAGNOSIS] Re: crash in trunk

On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven e.leu...@gmail.com wrote: ..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188 In case this is relevant, this assertion also shows up in:

Re: [DIAGNOSIS] Re: crash in trunk

Regarding the x2.patch, the problem is that par_iterator_begin() does not give us a complete DocIterator (one starting with the Buffer's own InsetText, etc), which is what we need. I am constantly running into this problem! Regarding the other patch, adding the code to InsetText just seemed

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 02:07 PM, John McCabe-Dansted wrote: On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuvene.leu...@gmail.com wrote: ..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188 In case this is relevant, this assertion also shows up

Re: [DIAGNOSIS] Re: crash in trunk

Il 23/04/2011 19:52, Edwin Leuven ha scritto: Richard Heckrgh...@comcast.net wrote: I guess the other idea would be to recurse through all the insets. attached, and no more crashes. i think i prefer this solution (although i am not sure we need to add the code to insettext) ed. FYI, I just

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck wrote: > Answer: No, probably not, because it's hard to see > how to do this without making copies, which would > just give us the same problem back again. the attached avoids the crash for me by setting the macrocontext for nested insets (and only doing the

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 06:56 AM, Edwin Leuven wrote: Richard Heck wrote: Answer: No, probably not, because it's hard to see how to do this without making copies, which would just give us the same problem back again. the attached avoids the crash for me by setting the macrocontext

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck wrote: > My main comment would be that I suspect, but of course > couldn't verify, due to the crashes, that the same > problem exists in the TexRow() output routine, i checked that previewing the document and having the source view pane open worked my guess was

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 11:45 AM, Edwin Leuven wrote: I wonder if we could try: ParagraphList::const_iterator pit = tail.getText(0)->paragraphs().begin(); buffer().updateBuffer(pit, OutputUpdate); i am not sure i completely follow you, but when i use

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 11:45 AM, Edwin Leuven wrote: I wonder if we could try: ParagraphList::const_iterator pit = tail.getText(0)->paragraphs().begin(); buffer().updateBuffer(pit, OutputUpdate); i am not sure i completely follow you, but when i use

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck wrote: > Can you post this version of the patch > and I'll try to have a look? attached > I'm wondering where these comparisons are > being made and whether we need to do > something to the cursor. But I'm really > just guessing here. very frustating this

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck wrote: > I guess the other idea would be to recurse > through all the insets. attached, and no more crashes. i think i prefer this solution (although i am not sure we need to add the code to insettext) ed. x3.patch Description: Binary data

Re: [DIAGNOSIS] Re: crash in trunk

On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven wrote: > ..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false > VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188 In case this is relevant, this assertion also shows up in:

Re: [DIAGNOSIS] Re: crash in trunk

Regarding the x2.patch, the problem is that par_iterator_begin() does not give us a "complete" DocIterator (one starting with the Buffer's own InsetText, etc), which is what we need. I am constantly running into this problem! Regarding the other patch, adding the code to InsetText just

Re: [DIAGNOSIS] Re: crash in trunk

On 04/23/2011 02:07 PM, John McCabe-Dansted wrote: On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven wrote: ..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188 In case this is relevant, this assertion also shows

Re: [DIAGNOSIS] Re: crash in trunk

Il 23/04/2011 19:52, Edwin Leuven ha scritto: Richard Heck wrote: I guess the other idea would be to recurse through all the insets. attached, and no more crashes. i think i prefer this solution (although i am not sure we need to add the code to insettext) ed. FYI, I

[DIAGNOSIS] Re: crash in trunk

On 04/22/2011 02:17 PM, Richard Heck wrote: On 04/22/2011 01:46 PM, Edwin Leuven wrote: Richard Heckrgh...@comcast.net wrote: Same crash with a footnote there. So it looks as if for some reason insets inside cells are not getting their macro context set properly. which is done in lines

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck rgh...@comcast.net wrote: I think I know what's happening here. sounds reasonable indeed We might somehow need to call updateBuffer() on these new insets. or find a way of calculating the width of the insettext before and after the decimal separator without making a copy,

Re: [DIAGNOSIS] Re: crash in trunk

On 04/22/2011 05:24 PM, Edwin Leuven wrote: Richard Heckrgh...@comcast.net wrote: I think I know what's happening here. sounds reasonable indeed We might somehow need to call updateBuffer() on these new insets. or find a way of calculating the width of the insettext before and after the

Re: [DIAGNOSIS] Re: crash in trunk

On 04/22/2011 10:42 PM, Richard Heck wrote: On 04/22/2011 05:24 PM, Edwin Leuven wrote: Richard Heckrgh...@comcast.net wrote: I think I know what's happening here. sounds reasonable indeed We might somehow need to call updateBuffer() on these new insets. or find a way of calculating the

[DIAGNOSIS] Re: crash in trunk

On 04/22/2011 02:17 PM, Richard Heck wrote: On 04/22/2011 01:46 PM, Edwin Leuven wrote: Richard Heck wrote: Same crash with a footnote there. So it looks as if for some reason insets inside cells are not getting their macro context set properly. which is done in lines

Re: [DIAGNOSIS] Re: crash in trunk

Richard Heck wrote: > I think I know what's happening here. sounds reasonable indeed > We might somehow need to call updateBuffer() > on these new insets. or find a way of calculating the width of the insettext before and after the decimal separator without making a copy,

Re: [DIAGNOSIS] Re: crash in trunk

On 04/22/2011 05:24 PM, Edwin Leuven wrote: Richard Heck wrote: I think I know what's happening here. sounds reasonable indeed We might somehow need to call updateBuffer() on these new insets. or find a way of calculating the width of the insettext before and after the

Re: [DIAGNOSIS] Re: crash in trunk

On 04/22/2011 10:42 PM, Richard Heck wrote: On 04/22/2011 05:24 PM, Edwin Leuven wrote: Richard Heck wrote: I think I know what's happening here. sounds reasonable indeed We might somehow need to call updateBuffer() on these new insets. or find a way of calculating the