Re: assert in CursorSlice.cpp

On 07/05/2015 02:53 PM, Enrico Forestieri wrote: On Sun, Jul 05, 2015 at 07:28:34PM +0100, Guillaume M-M wrote: Le 05/07/2015 18:06, Enrico Forestieri a écrit : Thanks for the reproducers. They evidence that the problem is due to the fact that MathData::metrics is not called when instant previe

Re: assert in CursorSlice.cpp

On Sun, Jul 05, 2015 at 07:28:34PM +0100, Guillaume M-M wrote: > Le 05/07/2015 18:06, Enrico Forestieri a écrit : > > > >Thanks for the reproducers. They evidence that the problem is due to > >the fact that MathData::metrics is not called when instant preview is > >on. I had tried to solve this iss

Re: assert in CursorSlice.cpp

Le 05/07/2015 18:06, Enrico Forestieri a écrit : On Sun, Jul 05, 2015 at 03:05:14AM +0100, Guillaume M-M wrote: Le 30/06/2015 19:20, Enrico Forestieri a écrit : On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote: Dear list, I got an assertion in stable (1b596e92) for the second t

Re: assert in CursorSlice.cpp

On Sun, Jul 05, 2015 at 03:05:14AM +0100, Guillaume M-M wrote: > Le 30/06/2015 19:20, Enrico Forestieri a écrit : > >On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote: > >>Dear list, > >> > >> > >>I got an assertion in stable (1b596e92) for the second time today. It > >>happened while

Re: assert in CursorSlice.cpp

Le 30/06/2015 19:20, Enrico Forestieri a écrit : On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote: Dear list, I got an assertion in stable (1b596e92) for the second time today. It happened while selecting text (first time with Shift+Arrows and second time with the mouse). I don't

Re: assert in CursorSlice.cpp

Le 30/06/2015 19:20, Enrico Forestieri a écrit : On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote: Dear list, I got an assertion in stable (1b596e92) for the second time today. It happened while selecting text (first time with Shift+Arrows and second time with the mouse). I don't

Re: assert in CursorSlice.cpp

On Tue, Jun 30, 2015 at 06:14:05PM +0100, Guillaume M-M wrote: > Dear list, > > > I got an assertion in stable (1b596e92) for the second time today. It > happened while selecting text (first time with Shift+Arrows and second time > with the mouse). > > I don't remember seeing it before: if it wa

assert in CursorSlice.cpp

Dear list, I got an assertion in stable (1b596e92) for the second time today. It happened while selecting text (first time with Shift+Arrows and second time with the mouse). I don't remember seeing it before: if it wasn't introduced recently then maybe it was hidden by the fact that I did n

Re: Re: [LyX/master] print callstack on assert

Yes, this would be the best thing to do - just use the scripts that were developed for configure tools. Benjamin On Thu, Sep 18, 2014 at 7:38 PM, Peter Kuemmel wrote: > > > I did work on the cmake bundling issue, but stopped since the CMake disk > image builder is not working that well… > > I th

Aw: Re: [LyX/master] print callstack on assert

> I did work on the cmake bundling issue, but stopped since the CMake disk > image builder is not working that well… > I think the best would be to adapt the existing script to build a disk image > directly, depending on the install target. > Benjamin We could create a target which calls the scr

Re: [LyX/master] print callstack on assert

> Date: 18 Sep 2014 at 13:06:22 To: lyx-devel@lists.lyx.org Devel > Subject:  Re: [LyX/master] print callstack on assert > > Isn't the package created by a bash script after building? > > Or is the cmake-build broken on Mac? > > Sorry, I've missed your

Re: [LyX/master] print callstack on assert

> > Isn't the package created by a bash script after building? > > Or is the cmake-build broken on Mac? > > Sorry, I've missed your reply. > > I'm using the cmake-generator to produce a Xcode project. I would use make (-G"Unix Makefiles") just to build the binaries and then use the script you al

Re: [LyX/master] print callstack on assert

Am 29.08.2014 um 08:28 schrieb Peter Kuemmel : >> >>> It's Friday: >>> There are no traces of LYX_CALLSTACK_PRINTING in automake files. >>> >>> Not important, automake will be dropped anyway ;) >> >> So, you're working on a cmake way to produce Mac packages? When is it >> finished?

Re: [LyX/master] print callstack on assert

> > > It's Friday: > > > >> > >> There are no traces of LYX_CALLSTACK_PRINTING in automake files. > > > > Not important, automake will be dropped anyway ;) > > So, you're working on a cmake way to produce Mac packages? When is it > finished? ;) Isn't the package created by a bash script afte

Re: [LyX/master] print callstack on assert

Am 29.08.2014 um 08:02 schrieb Peter Kuemmel : > It's Friday: > >> >> There are no traces of LYX_CALLSTACK_PRINTING in automake files. > > Not important, automake will be dropped anyway ;) So, you're working on a cmake way to produce Mac packages? When is it finished? ;) Stephan

Aw: Re: [LyX/master] print callstack on assert

It's Friday: > > There are no traces of LYX_CALLSTACK_PRINTING in automake files. Not important, automake will be dropped anyway ;) > > Kornel

Re: [LyX/master] print callstack on assert

066 > >>> Author: Peter Kümmel > >>> Date: Wed Aug 27 19:40:40 2014 +0200 > >>> > >>> print callstack on assert > >>> > >>> diff --git a/src/support/lassert.cpp b/src/support/lassert.cpp > >>> index 28

Re: [LyX/master] print callstack on assert

On 08/28/2014 03:19 AM, Peter Kümmel wrote: On 28.08.2014 00:20, Richard Heck wrote: On 08/27/2014 01:52 PM, Peter Kümmel wrote: commit ada262a78b2ec12e9697783b27523b8c13b51066 Author: Peter Kümmel Date: Wed Aug 27 19:40:40 2014 +0200 print callstack on assert diff --git a/src

Re: [LyX/master] print callstack on assert

On 28.08.2014 00:20, Richard Heck wrote: On 08/27/2014 01:52 PM, Peter Kümmel wrote: commit ada262a78b2ec12e9697783b27523b8c13b51066 Author: Peter Kümmel Date: Wed Aug 27 19:40:40 2014 +0200 print callstack on assert diff --git a/src/support/lassert.cpp b/src/support/lassert.cpp index

Re: [LyX/master] print callstack on assert

On 08/27/2014 01:52 PM, Peter Kümmel wrote: commit ada262a78b2ec12e9697783b27523b8c13b51066 Author: Peter Kümmel Date: Wed Aug 27 19:40:40 2014 +0200 print callstack on assert diff --git a/src/support/lassert.cpp b/src/support/lassert.cpp index 281330e..fa2ffb0 100644 --- a/src/support

Re: boost static assert on Ubuntu 13.10

Le 07/11/2013 15:06, Richard Heck a écrit : I think a bunch of us were getting such messages a while back in branch, at least, and that something was done to suppress them. But I can't remember for sure. JMarc may. We had some different warnings in boost when compiling with clang. I guess the

Re: boost static assert on Ubuntu 13.10

On 11/06/2013 06:32 PM, Tommaso Cucinotta wrote: Is anyone else getting gazillion of these messages ../../boost/boost/regex/v4/match_results.hpp:305:7: note: in expansion of macro ‘BOOST_STATIC_ASSERT’ BOOST_STATIC_ASSERT(sizeof(charT) <= sizeof(char_type)); ^ In file included

boost static assert on Ubuntu 13.10

Is anyone else getting gazillion of these messages ../../boost/boost/regex/v4/match_results.hpp:305:7: note: in expansion of macro ‘BOOST_STATIC_ASSERT’ BOOST_STATIC_ASSERT(sizeof(charT) <= sizeof(char_type)); ^ In file included from ../../boost/boost/regex/v4/regex.hpp:166:0,

Re: LyX crash after font assert

On 06/09/2012 08:35 AM, Tommaso Cucinotta wrote: On 08/06/12 04:15, Richard Heck wrote: On 6/7/12 6:15 PM, Tommaso Cucinotta wrote: Do u mind explaining what does this code do ? +void BufferView::makeDocumentClass() +{ + DocumentClassConstPtr olddc = buffer_.params().documentClassPtr();

Re: LyX crash after font assert

On 08/06/12 04:15, Richard Heck wrote: On 6/7/12 6:15 PM, Tommaso Cucinotta wrote: Do u mind explaining what does this code do ? +void BufferView::makeDocumentClass() +{ + DocumentClassConstPtr olddc = buffer_.params().documentClassPtr(); + buffer_.params().makeDocumentClass(); +

Re: LyX crash after font assert

On 04/06/12 18:22, Richard Heck wrote: The problem turns out to be that the paragraph we are redrawing here references a non-existent Layout. This is because the copy_params() routine in FindAndReplace.cpp, although it MAKES a new DocumentClass, it never APPLIES this new DocumentClass to its Bu

Re: LyX crash after font assert

On 06/04/2012 12:47 PM, Richard Heck wrote: On 06/04/2012 02:14 AM, Scott Kostyshak wrote: From: Tommaso Cucinotta [tomm...@lyx.org] Sent: Sunday, June 03, 2012 8:17 PM on trunk: 1) open embedded manual 2) put cursor at the very beginning of document 3) try to open Advanced Find and Replace (C

Re: LyX crash after font assert

On 06/04/2012 12:47 PM, Richard Heck wrote: On 06/04/2012 02:14 AM, Scott Kostyshak wrote: From: Tommaso Cucinotta [tomm...@lyx.org] Sent: Sunday, June 03, 2012 8:17 PM on trunk: 1) open embedded manual 2) put cursor at the very beginning of document 3) try to open Advanced Find and Replace (C

Re: LyX crash after font assert

On 06/04/2012 02:14 AM, Scott Kostyshak wrote: From: Tommaso Cucinotta [tomm...@lyx.org] Sent: Sunday, June 03, 2012 8:17 PM on trunk: 1) open embedded manual 2) put cursor at the very beginning of document 3) try to open Advanced Find and Replace (C-S-f) and I get this: lyx: SIGSEGV signal cau

Re: LyX crash after font assert

On 06/04/2012 02:14 AM, Scott Kostyshak wrote: From: Tommaso Cucinotta [tomm...@lyx.org] Sent: Sunday, June 03, 2012 8:17 PM on trunk: 1) open embedded manual 2) put cursor at the very beginning of document 3) try to open Advanced Find and Replace (C-S-f) and I get this: lyx: SIGSEGV signal cau

RE: LyX crash after font assert

From: Tommaso Cucinotta [tomm...@lyx.org] Sent: Sunday, June 03, 2012 8:17 PM >on trunk: >1) open embedded manual >2) put cursor at the very beginning of document >3) try to open Advanced Find and Replace (C-S-f) >and I get this: >lyx: SIGSEGV signal caught! I get this from a new document. That

Fwd: LyX crash after font assert

I forgot to mention: often I get this assert as well: lassert.cpp(35): ASSERTION f.family() < NUM_FAMILIES VIOLATED IN GuiFontLoader.cpp:95 (details follow) $ ./src/lyx lib/doc/EmbeddedObjects.lyx lyx: SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost

LyX crash after font assert

Hi, on trunk: 1) open embedded manual 2) put cursor at the very beginning of document 3) try to open Advanced Find and Replace (C-S-f) and I get this: $ ./src/lyx lib/doc/EmbeddedObjects.lyx lyx: SIGSEGV signal caught! Sorry, you have found a bug in LyX, hope you have not lost any data. Please

ASSERT on entering regexp inset when instant preview on

Hi all, I just dropped a ticket about an assertion triggered as follows (on current trunk r39819): 0) Activate instant preview from prefs 1) C-S-f (open the find advanced panel) 2) C-m (start math inset) 3) Menu: Insert->Regular Expression->Anything 4) C-Home 5) Cursor right twice For details

lyx_2_0_0 @ Ubuntu 11.04 Natty (with assert)

Just a quick note from an attempt to build the lyx_2_0_0 branch on Ubuntu 11.04: I get a warning: $ ./autogen.sh Using automake (GNU automake) 1.11.1 Using autoconf (GNU Autoconf) 2.67 Building macros... /usr/share/aclocal/gtkglextmm-1.2.m4:225: warning: underquoted definition of AC_GTKGLEXTMM_

Re: (Regression in r37749 by forenr) Assert with ERT inset and LaTeX Error dialog open.

John McCabe-Dansted wrote: > On Tue, Mar 1, 2011 at 2:55 AM, Pavel Sanda wrote: > > neither me. John are you running up to date svn? > > It was quite recent, but I updated I now I cannot reproduce either :). yep something similar was fixed recently.p

Re: (Regression in r37749 by forenr) Assert with ERT inset and LaTeX Error dialog open.

On Tue, Mar 1, 2011 at 2:55 AM, Pavel Sanda wrote: > neither me. John are you running up to date svn? It was quite recent, but I updated I now I cannot reproduce either :). -- John C. McCabe-Dansted

Re: (Regression in r37749 by forenr) Assert with ERT inset and LaTeX Error dialog open.

Enrico Forestieri wrote: > On Mon, Feb 28, 2011 at 08:48:46PM +0800, John McCabe-Dansted wrote: > > > To Reproduce: > > 1) Press Alt-Delete to insert a non-printable character > > 2) Press Ctrl-L to insert an ERT inset > > 3) Press Ctrl-D to bring up the LaTeX error dialog box. > > 4) Click inside

Re: (Regression in r37749 by forenr) Assert with ERT inset and LaTeX Error dialog open.

On Mon, Feb 28, 2011 at 08:48:46PM +0800, John McCabe-Dansted wrote: > To Reproduce: > 1) Press Alt-Delete to insert a non-printable character > 2) Press Ctrl-L to insert an ERT inset > 3) Press Ctrl-D to bring up the LaTeX error dialog box. > 4) Click inside the ERT. Sorry, cannot reproduce. --

(Regression in r37749 by forenr) Assert with ERT inset and LaTeX Error dialog open.

To Reproduce: 1) Press Alt-Delete to insert a non-printable character 2) Press Ctrl-L to insert an ERT inset 3) Press Ctrl-D to bring up the LaTeX error dialog box. 4) Click inside the ERT. I then get the following assert. This appears to be a regression in r37749 by forenr, though note that I

Re: Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

On 12/02/2010 11:29 AM, Vincent van Ravesteijn wrote: No, this should never be empty. We specifically push a null pointer onto the stack at the beginning, as a kind of dummy entry that makes sure we never pop more than we push. If it is empty, then we have popped more than we have pushed.

Re: Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

> No, this should never be empty. We specifically push a null pointer onto the > stack at the beginning, as a kind > of dummy entry that makes sure we never pop more than we push. If it is > empty, then we have popped more > than we have pushed. > I don't understand why we do that. We only push&po

Re: Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

On 12/02/2010 08:43 AM, John McCabe-Dansted wrote: Keycodes: '''\Af\C\[Left]\Am\Av\Af\Ay'''\[!Loop]\Af To reproduce: 1) Press Alt-H, M to open the Math Guide. (KK: \Af) (KK: \C\[Left]) (KK: \Am) 2) Press Alt-V, F, Y to view LyXHTML (KK: \Av\Af\Ay) Regression in: r36603 Fixed ar r36657. Rich

Re: Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

2) Press Alt-V, F, Y to view LyXHTML (KK: \Av\Af\Ay) Regression in: r36603 I think the ASSERT is bogus. counters@573: -LASSERT(!layout_stack_.empty(), return); +if(layout_stack_.empty()) + return; will fix it. No, this should never be empty. We specifically push a null pointer onto th

Re: Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

Math Guide. (KK: \Af) (KK: \C\[Left]) (KK: >> \Am) >> 2)  Press Alt-V, F, Y to view LyXHTML (KK: \Av\Af\Ay) >> >> Regression in: r36603 >> > > I think the ASSERT is bogus. > > counters@573: > -LASSERT(!layout_stack_.empty(), return); > +if(layout_stac

Re: Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

TML (KK: \Av\Af\Ay) > > Regression in: r36603 > I think the ASSERT is bogus. counters@573: -LASSERT(!layout_stack_.empty(), return); +if(layout_stack_.empty()) + return; will fix it. Vincent

Regression in r36603 by vfr: Assert when Viewing Math Guide as LyXHTML

Keycodes: '''\Af\C\[Left]\Am\Av\Af\Ay'''\[!Loop]\Af To reproduce: 1) Press Alt-H, M to open the Math Guide. (KK: \Af) (KK: \C\[Left]) (KK: \Am) 2) Press Alt-V, F, Y to view LyXHTML (KK: \Av\Af\Ay) Regression in: r36603 Arch: x86_64 Revision: 36644 {{{ lassert.cpp(21): ASSERTION !layout_stack_.

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

On 11/18/2010 10:16 PM, John McCabe-Dansted wrote: On Fri, Nov 19, 2010 at 11:07 AM, RGH > wrote: On 11/18/2010 08:06 PM, John McCabe-Dansted wrote: I can also reproduce after I have closed the split as follows: 1. Open LyX. Create a section heading (alt-P

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

On Fri, Nov 19, 2010 at 11:07 AM, RGH wrote: > On 11/18/2010 08:06 PM, John McCabe-Dansted wrote: > > I can also reproduce after I have closed the split as follows: > 1. Open LyX. Create a section heading (alt-P, 2), can be empty > 2. Open a new document (Ctrl-N) > 3. Enter an "x" > 4. Split the

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

On 11/18/2010 08:06 PM, John McCabe-Dansted wrote: I can also reproduce after I have closed the split as follows: 1. Open LyX. Create a section heading (alt-P, 2), can be empty 2. Open a new document (Ctrl-N) 3. Enter an "x" 4. Split the screen (Alt-V, E) 5. Close the split-screen document (Alt-

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

On Mon, Nov 1, 2010 at 8:57 PM, Richard Heck wrote: > > I now see this crash prior to r34826. The problem, as I said, is that the > TOC gets out of sync with the active buffer. So try the following. > > 1. Open LyX. File>New. Document>Outline, to make sure the TOC is open. > > 2. Create a section

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

On 01/11/2010 14:46, Pavel Sanda wrote: Richard Heck wrote: I don't understand the split screen stuff, so I'm not sure why this would only happen then. But here's a simple recipe to reproduce. which reminds me - Abdel please can you have finally look at the #34054? there seems to

[PATCH] Assert with Split Screen

So the crash John reported comes in at r31203. Here's the recipe, again: 1. Open LyX. File>New. Document>Outline, to make sure the TOC is open. That isn't necessary, but it helps you to see what is happening. 2. Create a section heading (alt-P, 2) with an x in it. 3. Split the screen. 4. File>

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

Richard Heck wrote: >>> I don't understand the split screen stuff, so I'm not sure why this would >>> only happen then. But here's a simple recipe to reproduce. which reminds me - Abdel please can you have finally look at the #34054? there seems to be more related bugs. pavel >>> 1. Open LyX. C

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

does not set the readonly flag when opening readonly files. I then get the Assert: This is a serious bug and needs to fixed quickly. It would be very helpful if you could bisect further. The actual bug itself appears to have been introduced in r34826 by "rgheck". Yes, we expected ther

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

readonly files. I then get the Assert: This is a serious bug and needs to fixed quickly. It would be very helpful if you could bisect further. The actual bug itself appears to have been introduced in r34826 by "rgheck". Yes, we expected there would be some such things: This was the big

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

then get the Assert: This is a serious bug and needs to fixed quickly. It would be very helpful if you could bisect further. The actual bug itself appears to have been introduced in r34826 by "rgheck". Yes, we expected there would be some such things: This was the big

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

oduce with r35831 too ;) Incidentally, I think the regression in r35832 has to do with being able to reproduce the bug when LFUNs.lyx is marked readonly, which in turn is because r35832 does not set the readonly flag when opening readonly files. >> I then get the Assert: > > This is

Re: (r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

On Wed, Oct 27, 2010 at 4:37 PM, John McCabe-Dansted wrote: > Hi Vincent, this appears to be another recent regression, this time > from r35832 on Monday. Sorry John, your system is a bit off. I can reproduce with r35831 too ;) > I then get the Assert: This is a serious bug and

(r35832 by "vfr") Assert when pressing letter with Split Screen and Help->LyX Functions.

Hi Vincent, this appears to be another recent regression, this time from r35832 on Monday. Keycodes: \Av\Ae\AhY\A% To reproduce: 1) Press Alt-V, E to split the Screen 2) Press Alt-H, Y to Open Help->LyX Functions 3) Press X I then get the Assert: /usr/include/c++/4.4/debug/vector:272:er

Re: Search pane assert

Pavel Sanda ha scritto: 1. new file 2. find and open (advanced) //open 3. close file 4. find and open (advanced) //close 5. kaboom As observed by Vincent, the assertion is not needed, and I verified that setCurrentWorkArea() tolerates a NULL argument (see attached patch). I can commit, unle

Search pane assert

1. new file 2. find and open (advanced) //open 3. close file 4. find and open (advanced) //close 5. kaboom

Re: Assert on setCursor()

Tommaso Cucinotta wrote: > I forgot to please ask somebody to commit this patch, as I can't. i already understood, but knowing basically nothing about tabular stuff waited for somebody competent to review, since "heurictic" patch made somewhat suspicious ;) pavel

Re: Assert on setCursor()

I forgot to please ask somebody to commit this patch, as I can't. Thx, T. Tommaso Cucinotta ha scritto: Hi again, with the attached ("heuristic") patch I fixed this problem, which was arising when searching for stuff inside a math environment nested inside a table cell (i.e., searching f

Re: Assert on setCursor()

Hi again, with the attached ("heuristic") patch I fixed this problem, which was arising when searching for stuff inside a math environment nested inside a table cell (i.e., searching for a+b inside Math.lyx). In such segments, I'm assuming the direction is Left To Right (but don't actually kn

Assert on setCursor()

Hi all, could anyone please explain what is the purpose of the "- 2", in this method (from InsetTabular.cpp) ? 5090bool InsetTabular::isRightToLeft(Cursor & cur) const 5091{ 5092LASSERT(cur.depth() > 1, /**/); 5093Paragraph const & parentpar = cur[cur.depth() - 2].parag

Re: Assert when clicking a math inset

On 07/16/2009 09:49 AM, Vincent van Ravesteijn - TNW wrote: On Thu, Jul 16, 2009 at 12:09:40AM +0200, Vincent van Ravesteijn - TNW wrote: Current trunk: LyX asserts when clicking in a math inset. There's no problem entering a math inset using the arrow keys. Still there. Steps

RE: Assert when clicking a math inset

On Thu, Jul 16, 2009 at 12:09:40AM +0200, Vincent van Ravesteijn - TNW wrote: >> >> Current trunk: LyX asserts when clicking in a math inset. >> >> There's no problem entering a math inset using the arrow keys. >> > >> >Still there. Steps to reproduce: >> >> What if you remove "setBuffer(..) {}

Re: Assert when clicking a math inset

On Thu, Jul 16, 2009 at 12:09:40AM +0200, Vincent van Ravesteijn - TNW wrote: > >> Current trunk: LyX asserts when clicking in a math inset. > >> There's no problem entering a math inset using the arrow keys. > > > >Still there. Steps to reproduce: > > What if you remove "setBuffer(..) {}" from In

Re: Assert when clicking a math inset

On Wed, Jul 15, 2009 at 07:05:02PM -0400, rgheck wrote: > On 07/15/2009 05:57 PM, Enrico Forestieri wrote: > > On Wed, Jul 15, 2009 at 01:41:28PM +0200, Enrico Forestieri wrote: > > > >> Current trunk: LyX asserts when clicking in a math inset. > >> There's no problem entering a math inset usin

Re: Assert when clicking a math inset

On 07/15/2009 06:09 PM, Vincent van Ravesteijn - TNW wrote: Current trunk: LyX asserts when clicking in a math inset. There's no problem entering a math inset using the arrow keys. Still there. Steps to reproduce: What if you remove "setBuffer(..) {}" from InsetMathSpecialChar ?

Re: Assert when clicking a math inset

On 07/15/2009 05:57 PM, Enrico Forestieri wrote: On Wed, Jul 15, 2009 at 01:41:28PM +0200, Enrico Forestieri wrote: Current trunk: LyX asserts when clicking in a math inset. There's no problem entering a math inset using the arrow keys. Still there. Steps to reproduce: 1) Ctrl-N 2)

RE: Assert when clicking a math inset

>> Current trunk: LyX asserts when clicking in a math inset. >> There's no problem entering a math inset using the arrow keys. > >Still there. Steps to reproduce: What if you remove "setBuffer(..) {}" from InsetMathSpecialChar ? Vincent

Re: Assert when clicking a math inset

On Wed, Jul 15, 2009 at 01:41:28PM +0200, Enrico Forestieri wrote: > Current trunk: LyX asserts when clicking in a math inset. > There's no problem entering a math inset using the arrow keys. Still there. Steps to reproduce: 1) Ctrl-N 2) Ctrl-M 3) Ctrl-M 4) write something 5) Click in the math in

Assert when clicking a math inset

Current trunk: LyX asserts when clicking in a math inset. There's no problem entering a math inset using the arrow keys. -- Enrico

Re: trunk: Assert when copying table

Le 15 juil. 09 à 00:28, Vincent van Ravesteijn a écrit : copySelectionHelper calls: acceptChanges(copy_pars, buf.params()); This means that the paragraphs are already copied into the ParagraphList and they don't have a buffer anymore. Yes, this is why my changeset that removed plenty of expl

Re: trunk: Assert when copying table

Jean-Marc Lasgouttes schreef: Le 15 juil. 09 à 00:11, Vincent van Ravesteijn a écrit : Changes are accepted in the selection, which need bufferparams(). Yes, this is what I saw. So it is my fault after all :) I guess the problem is r30531, which should probably be reverted (I do not have time

Re: trunk: Assert when copying table

Le 15 juil. 09 à 00:22, Jean-Marc Lasgouttes a écrit : Finally, moveItem needs this information only to be able to call getFontSettings. I doubt that this operation really requires the bufferparam... All this boils down to the fact that we may need the document language. This really does not

Re: trunk: Assert when copying table

Le 15 juil. 09 à 00:11, Vincent van Ravesteijn a écrit : Changes are accepted in the selection, which need bufferparams(). Yes, this is what I saw. So it is my fault after all :) I guess the problem is r30531, which should probably be reverted (I do not have time to do it cleanly, but it almos

Re: trunk: Assert when copying table

Jean-Marc Lasgouttes schreef: Le 15 juil. 09 à 00:00, Vincent van Ravesteijn a écrit : Select a table, try to copy. Assert! It is worse than that: select any inset, copy or deselect it -> crash What happens is that the copy of the inset that is done has a buffer pointer =0, and t

Re: trunk: Assert when copying table

Le 15 juil. 09 à 00:00, Vincent van Ravesteijn a écrit : Select a table, try to copy. Assert! It is worse than that: select any inset, copy or deselect it -> crash What happens is that the copy of the inset that is done has a buffer pointer =0, and this asserts. I do not know though

trunk: Assert when copying table

Select a table, try to copy. Assert! Vincent

Re: Crash (Assert) when opening a directory

g on it) LyX now crashes with this message: LyX: Done! ASSERT failure in QList::at: "index out of range", file ../../include/QtCore/../../src/corelib/tools/qlist.h, line 391 Aborted I just build LyX 1.6.0 on that machine at it crashes in the same way.

Crash (Assert) when opening a directory

is message: LyX: Done! ASSERT failure in QList::at: "index out of range", file ../../include/QtCore/../../src/corelib/tools/qlist.h, line 391 Aborted I suspect I might have a file/directory in 'private/jobb/' with a character in the name that LyX doesn'

Re: Buffer Message Assert [Was: trunk is asserting on shutdown]

On 22/11/2008 20:41, Enrico Forestieri wrote: On Sat, Nov 22, 2008 at 07:23:56PM +0100, Abdelrazak Younes wrote: Actually the internal buffer is properly created and deleted; IOW I cannot reproduce the assertion... Do you still can? The bug does not always happens. Here is a recipe f

Re: Buffer Message Assert [Was: trunk is asserting on shutdown]

Enrico Forestieri wrote: On Sat, Nov 22, 2008 at 07:23:56PM +0100, Abdelrazak Younes wrote: Actually the internal buffer is properly created and deleted; IOW I cannot reproduce the assertion... Do you still can? The bug does not always happens. Here is a recipe for triggering it: 1) Lo

Re: Buffer Message Assert [Was: trunk is asserting on shutdown]

On Sat, Nov 22, 2008 at 07:23:56PM +0100, Abdelrazak Younes wrote: > Actually the internal buffer is properly created and deleted; IOW I > cannot reproduce the assertion... Do you still can? The bug does not always happens. Here is a recipe for triggering it: 1) Load and preview the user guide (D

Re: Buffer Message Assert [Was: trunk is asserting on shutdown]

elf will always trigger an assert, even it it is issued for good reason This second bug is also in branch, AFAICS. What shall we do? Use a console warning instead? I'm guessing Abdel will know what to do. I seem to remember a similar issue a while ago. And we may not actually need to do an

Re: Buffer Message Assert [Was: trunk is asserting on shutdown]

d for some reason, and it's being destroyed on exit. This might be an issue with the new search stuff. It creates a Buffer for its own use, doesn't it? But then we have two bugs: 1.) the warning, as it appears, is wrong 2.) the warning itself will always trigger an assert, even it it

Buffer Message Assert [Was: trunk is asserting on shutdown]

27;s being destroyed on exit. This might be an issue with the new search stuff. It creates a Buffer for its own use, doesn't it? But then we have two bugs: 1.) the warning, as it appears, is wrong 2.) the warning itself will always trigger an assert, even it it is issued for good reason Thi

Re: InsetQuote Buffer Assert

On Tue, 28 Oct 2008 08:49:30 +0100 Abdelrazak Younes <[EMAIL PROTECTED]> wrote: Why not a const ref instead of a copy? if (cur.inTexted()) { - Paragraph par = cur.paragraph(); + Paragraph const& par = cur.paragraph(); Ooops, so, each paragraph was being w

Re: InsetQuote Buffer Assert

On Tue, Oct 28, 2008 at 08:49:30AM +0100, Abdelrazak Younes wrote: > Why not a const ref instead of a copy? Yep, that seems to be the right fix. > if (cur.inTexted()) { > - Paragraph par = cur.paragraph(); > + Paragraph const& par = cur.paragraph(); >

Re: InsetQuote Buffer Assert

On 28/10/2008 00:14, Enrico Forestieri wrote: On Mon, Oct 27, 2008 at 07:08:26PM +0100, Abdelrazak Younes wrote: On 27/10/2008 12:58, rgheck wrote: Tommaso Cucinotta wrote: Pavel Sanda ha scritto: i have put it in. anyway at first try: 1. load math manual 2. searc

Re: InsetQuote Buffer Assert

On Mon, Oct 27, 2008 at 07:08:26PM +0100, Abdelrazak Younes wrote: > On 27/10/2008 12:58, rgheck wrote: > > Tommaso Cucinotta wrote: > >> Pavel Sanda ha scritto: > >>> i have put it in. anyway at first try: > >>> 1. load math manual > >>> 2. search math exrp E/F > >>> 3. search > >>> 4. kaboom > >

Re: InsetQuote Buffer Assert

On 27/10/2008 12:58, rgheck wrote: Tommaso Cucinotta wrote: Pavel Sanda ha scritto: i have put it in. anyway at first try: 1. load math manual 2. search math exrp E/F 3. search 4. kaboom I have tracked down the problem to a much simpler example: 1. New document 2. Enter any text containing a d

InsetQuote Buffer Assert

Tommaso Cucinotta wrote: Pavel Sanda ha scritto: i have put it in. anyway at first try: 1. load math manual 2. search math exrp E/F 3. search 4. kaboom I have tracked down the problem to a much simpler example: 1. New document 2. Enter any text containing a double quote character (") 3. AdvS

Re: Assert in trunk: QList

On Fri, May 16, 2008 at 4:03 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Bennett Helm wrote: > >> In current 1.6, when choosing Edit > Text Style > Customized, I get: >> >> ASSERT failure in QList::operator[]: "index out of range", file >&

Re: Assert in trunk: QList

Bennett Helm wrote: In current 1.6, when choosing Edit > Text Style > Customized, I get: ASSERT failure in QList::operator[]: "index out of range", file /Users/bennett/lyx/qt-4.4-install/include/QtCore/qlist.h, line 401 I cannot reproduce this. Do you have a particular test

Assert in trunk: QList

In current 1.6, when choosing Edit > Text Style > Customized, I get: ASSERT failure in QList::operator[]: "index out of range", file /Users/bennett/lyx/qt-4.4-install/include/QtCore/qlist.h, line 401 Program exited with code 01. (By the way, I love the new session handling of dialogs!) Bennett

Re: Another assert

On Fri, Feb 22, 2008 at 09:44:47AM +0200, Martin Vermeer wrote: > The X system should have a routine for doing that... Yes, but that's not available on Windows. Using QColor::setNamedColor() might be an option, void QColor::setNamedColor ( const QString & name ) Sets the RGB valu

  1   2   3   >