Re: Another Crash with SIGSEGV signal on LyX-2.4.0-beta2 (macOS Ventura)

Le 28/01/2023 à 03:49, 黃皇男 a écrit : To whom it may be concerned: Machine: Apple Macbook Air 15 Intel OS:Ventura 13.2 I think it happens when OS turn the dark into light mode Hello, Huang-Nan: The best solution to get answer is to send your message to lyx-devel@lists.lyx.org Others: pleas

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

On 8/17/20 1:35 AM, Jürgen Spitzmüller wrote: > Am Sonntag, den 16.08.2020, 21:26 +0100 schrieb José Abílio Matos: >> What is wrong with >> >> pos_type ipos = min(cur.pos(), cell(i).size()); >> >> it expresses intent better than the other code, no? :-) > This was my first choice, too. However,

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am 17.08.2020 um 13:30 schrieb Jürgen Spitzmüller : > > Am Montag, den 17.08.2020, 08:38 +0100 schrieb José Abílio Matos: >> pos_type ipos = min(cur.pos(), pos_type(cell(i).size())); > > Changed on top of Stephan's fix (plus constify). That’s better indeed. Fine. Stephan -- lyx-devel mailing l

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am Montag, den 17.08.2020, 08:38 +0100 schrieb José Abílio Matos: > pos_type ipos = min(cur.pos(), pos_type(cell(i).size())); Changed on top of Stephan's fix (plus constify). Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am Montag, den 17.08.2020, 08:38 +0100 schrieb José Abílio Matos: > OK then what about > > pos_type ipos = min(cur.pos(), pos_type(cell(i).size())); Looks better. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http:

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

On Monday, 17 August 2020 06.35.27 WEST Jürgen Spitzmüller wrote: > Am Sonntag, den 16.08.2020, 21:26 +0100 schrieb José Abílio Matos: > > What is wrong with > > > > pos_type ipos = min(cur.pos(), cell(i).size()); > > > > it expresses intent better than the other code, no? :-) > > This was my fi

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am Sonntag, den 16.08.2020, 21:29 +0200 schrieb Stephan Witt: > This patch works with clang and avoids a type mismatch warning for > signed vs unsigned typed values comparison. This works for me, too. Please commit. Jürgen signature.asc Description: This is a digitally signed message part -- l

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am Sonntag, den 16.08.2020, 21:26 +0100 schrieb José Abílio Matos: > What is wrong with > > pos_type ipos = min(cur.pos(), cell(i).size()); > > it expresses intent better than the other code, no? :-) This was my first choice, too. However, it triggers: mathed/InsetMathGrid.cpp:1637:51: error:

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

On Sunday, 16 August 2020 20.29.50 WEST Stephan Witt wrote: > This patch works with clang and avoids a type mismatch warning for signed vs > unsigned typed values comparison. > > Stephan What is wrong with pos_type ipos = min(cur.pos(), cell(i).size()); it expresses intent better than the other

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am 16.08.2020 um 21:00 schrieb Stephan Witt : > > Am 16.08.2020 um 19:23 schrieb Thibaut Cuvelier : >> >> Hi, >> >> I just tried to compile the latest version of the code with Visual C++. >> However, it chokes on line 1637 of InsetMathGrid.cpp: >> >> error C3861: 'uint': identifier not found

Re: Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Am 16.08.2020 um 19:23 schrieb Thibaut Cuvelier : > > Hi, > > I just tried to compile the latest version of the code with Visual C++. > However, it chokes on line 1637 of InsetMathGrid.cpp: > > error C3861: 'uint': identifier not found > > Here is my (simple) fix, in bold (formal patch attach

Commit 957b615b (Fix another crash with Grid pasting) breaks compilation with Visual C++ 2019

Hi, I just tried to compile the latest version of the code with Visual C++. However, it chokes on line 1637 of InsetMathGrid.cpp : error C3861: 'uint': identifier not found He

Re: Another Crash in Trunk

On Thu, Jan 10, 2008 at 02:22:52PM -0500, rgheck wrote: > Andre Poenitz wrote: >> On Thu, Jan 10, 2008 at 01:45:23AM -0500, rgheck wrote: >> >>> When lyx2lyx fails with an error: >>> gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb >>> >> >> Completely unrelated out o

Re: Another Crash in Trunk

Andre Poenitz wrote: On Thu, Jan 10, 2008 at 01:45:23AM -0500, rgheck wrote: When lyx2lyx fails with an error: gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb Completely unrelated out of interest: Why do you use --interpreter=mi2? It does not give any advantages

Re: Another Crash in Trunk

On Thu, Jan 10, 2008 at 01:45:23AM -0500, rgheck wrote: > > When lyx2lyx fails with an error: > gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb Completely unrelated out of interest: Why do you use --interpreter=mi2? It does not give any advantages when used 'manually', does

Re: Another Crash in Trunk

rgheck wrote: When lyx2lyx fails with an error: ... #3 0x0072b269 in lyx::CursorSlice::paragraph (this=optimized out>) at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/vector:192 It looks like the DocIterator::slices_ is empty and 'DocIterator::top()'

Another Crash in Trunk

When lyx2lyx fails with an error: gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quietQuit (gdb) quitquit The program is running. Exit anyway? (y or n) [answered Y; input not from terminal] (gdb) Process exited gdb /cvs/

Re: Another crash with TOC dock widget after undo

Stefan Schimanski wrote: Any news about this? LyX still crashes... The fix is obvious. Just commit it Abdel.

Re: Another crash with TOC dock widget after undo

Any news about this? LyX still crashes... Stefan Am 11.06.2007 um 16:41 schrieb Jean-Marc Lasgouttes: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Since label update is a view thing (nothing to do in core undo code imo), we could have a new update flag that does the update

Re: Another crash with TOC dock widget after undo

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> Since label update is a view thing (nothing to do in core undo >> code imo), we could have a new update flag that does the update >> (one entry or all entries) before the matrics update. Abdelrazak> Yes but not now! Yes, sur

Re: [patch] Another crash with TOC dock widget after undo

Stefan Schimanski wrote: The obvious naive fix: Simple is beautiful and most of time correct. I'm sure it is this time ;-) Abdel.

Re: Another crash with TOC dock widget after undo

Jean-Marc Lasgouttes wrote: "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> What about updating the TOC asynchronously? Don't know how to Stefan> do this with the current architecture. Are there asynchronous Stefan> lfuns? I.e. they are only executed from the frontend's messag

Re: Another crash with TOC dock widget after undo

Am 11.06.2007 um 15:16 schrieb Abdelrazak Younes: Richard Heck wrote: Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is

Re: Another crash with TOC dock widget after undo

Richard Heck wrote: Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that call. But ControlToc::getCurrent

Re: Another crash with TOC dock widget after undo

> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes: Stefan> What about updating the TOC asynchronously? Don't know how to Stefan> do this with the current architecture. Are there asynchronous Stefan> lfuns? I.e. they are only executed from the frontend's message Stefan> loop after ever

[patch] Another crash with TOC dock widget after undo

The obvious naive fix: --- src/Undo.cpp(Revision 18737) +++ src/Undo.cpp(Arbeitskopie) @@ -164,6 +164,7 @@ // This does the actual undo/redo. //lyxerr << "undo, performing: " << undo << std::endl; + bool labelsUpdateNeeded = false; DocIterator dit = u

Re: Another crash with TOC dock widget after undo

Am 11.06.2007 um 15:06 schrieb Richard Heck: Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that cal

Re: Another crash with TOC dock widget after undo

Stefan Schimanski wrote: FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 First guess: looking at Undo::undoText... updateLabels(*buf) will trigger a TOC update. The cursor of the bufferview is still broken then. It is only fixed after that call. But ControlToc::getCurrentTocItem(size_t type) fi

Another crash with TOC dock widget after undo

FYI: http://bugzilla.lyx.org/show_bug.cgi?id=3851 Stefan PGP.sig Description: Signierter Teil der Nachricht

Re: another crash

On Sat, Apr 10, 2004 at 05:17:08PM +0200, Juergen Spitzmueller wrote: > Juergen Spitzmueller wrote: > > - create a new document > > - insert a collapsable (e.g. ert) > > - move the cursor before the inset > > - press backspace > > I think I see what's going on. The crash only happens if you hit ba

Re: another crash

Juergen Spitzmueller wrote: > - create a new document > - insert a collapsable (e.g. ert) > - move the cursor before the inset > - press backspace I think I see what's going on. The crash only happens if you hit backspace when the cursor is in front of an *opened* collapsable (a closed collapsabl

another crash

- create a new document - insert a collapsable (e.g. ert) - move the cursor before the inset - press backspace Regards, Jürgen. Assertion triggered in void LyXText::backspace(LCursor&) by failing check "this == cur.text()" in file text.C:1599 LyX: Versuche, das Dokument newfile1.lyx zu speichern

another crash

I think I was printing or using custom export. It was right before class, and I just launched another lyx to print. Program received signal SIGSEGV, Segmentation fault. MathCursor::depth (this=0x0) at /usr/include/g++/stl_vector.h:210 210 { return size_type(end() - begin()); } (gdb) bt #

Re: another crash

On Wed, Feb 06, 2002 at 10:10:08AM -0500, Richard E. Hawkins wrote: > appears. Sure enough, my equation is still highlighted, and lyx is > frozen. Have you updated recently. I fixed some endless loop yesterday. > My executable shows a Feb 4, which means I should be up to cvs as of > sometime