Am 15.09.2023 um 15:26 schrieb Jean-Marc Lasgouttes :
>
> Le 15/09/2023 à 13:18, Stephan Witt a écrit :
>>> To me, this looks like this one:
>>> https://www.lyx.org/trac/ticket/12818
>>>
>>> We have a problem on macOS with the interpretation of the return values of
>>> QMessageBox.
>>>
>>> I se
Le 15/09/2023 à 13:18, Stephan Witt a écrit :
To me, this looks like this one:
https://www.lyx.org/trac/ticket/12818
We have a problem on macOS with the interpretation of the return values of
QMessageBox.
I see the patch there is not backported to 2.3.x. Is this normal?
I think it’s not back
Am 15.09.2023 um 11:44 schrieb Jean-Marc Lasgouttes :
>
> Le 15/09/2023 à 11:40, luxhacker a écrit :
>> Hi Pavel,
>> Please create an account for me. I am very interested in LyX.
>> It's difficult to reproduce or seize a problem without knowing anything
>> about it.
>> When looking at the stack,
On Fri, Sep 15, 2023 at 09:40:08AM +, luxhacker wrote:
> Please create an account for me. I am very interested in LyX.
done. p
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Le 15/09/2023 à 11:40, luxhacker a écrit :
Hi Pavel,
Please create an account for me. I am very interested in LyX.
It's difficult to reproduce or seize a problem without knowing anything about
it.
When looking at the stack, I get - perhaps wrongly - the impression it's
user-interface related
Hi Pavel,
Please create an account for me. I am very interested in LyX.
It's difficult to reproduce or seize a problem without knowing anything about
it.
When looking at the stack, I get - perhaps wrongly - the impression it's
user-interface related. Which surprises me a lot.
Could you plea
On Fri, Sep 15, 2023 at 06:39:22AM +, luxhacker wrote:
> New to LyX and appreciating it ! found no way to register. Is this ok ?
> therefore mailing bug report
It's ok. I can create the account if you are interested.
> What I do before ;) ?
>
> Immediately when crashing, I was searching for
Dear All,
New to LyX and appreciating it ! found no way to register. Is this ok ?
therefore mailing bug report
Please find hereafter a crash of the LyX-system:
( 1) 1 lyx 0x00010bde4ddd
_ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_tr
Ok; no problem. Thank you.
> On 12 Feb 2018, at 5:43 pm, LyX Ticket Tracker wrote:
>
> #10781: LyX crash while moving between two open LyX files (I presume) --
> report
> attached
> --+-
> Reporter: lyx101| Owner:
No, I have not seen this crash since my report. BUT I’ve not been a heavy user
since that time. That will start again next month.
> On 12 Feb 2018, at 3:06 am, LyX Ticket Tracker wrote:
>
> #10781: LyX crash while moving between two open LyX files (I presume) --
> repor
5 um 00:28 schrieb LyX Ticket Tracker :
> #9659: lyx crash when exited from dock
> -+---
> Reporter: HongshengHe | Owner: stwitt
> Type: defect | Status: accepted
> Priority: high | Mile
ok, done.
A/
On Tue, Oct 14, 2014 at 5:33 PM, Richard Heck wrote:
> On 10/14/2014 11:17 AM, Alfredo Braunstein wrote:
>>
>> On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein
>> wrote:
>>>
>>> On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
>>> wrote:
Le 13/10/2014 18:15, Alfr
On 10/14/2014 11:17 AM, Alfredo Braunstein wrote:
On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein wrote:
On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
wrote:
Le 13/10/2014 18:15, Alfredo Braunstein a écrit :
The fix however seems bogus to me:
-cur.forwardPos()
On Tue, Oct 14, 2014 at 8:51 AM, Alfredo Braunstein wrote:
> On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
> wrote:
>> Le 13/10/2014 18:15, Alfredo Braunstein a écrit :
>
> The fix however seems bogus to me:
> -cur.forwardPos();
> +
On Mon, Oct 13, 2014 at 6:27 PM, Jean-Marc Lasgouttes
wrote:
> Le 13/10/2014 18:15, Alfredo Braunstein a écrit :
The fix however seems bogus to me:
>>>
>>>
>>>
-cur.forwardPos();
+cur.top().forwardPos();
>>>
>>>
>>>
>>> Why bogus? Why do you want
Le 13/10/2014 18:15, Alfredo Braunstein a écrit :
The fix however seems bogus to me:
-cur.forwardPos();
+cur.top().forwardPos();
Why bogus? Why do you want to revert it?
To me it seems wrong (for the reasons explained below). But maybe I
don't understand i
On Mon, Oct 13, 2014 at 5:39 PM, Jean-Marc Lasgouttes
wrote:
> Le 13/10/2014 14:29, Alfredo Braunstein a écrit :
>>
>> The fix however seems bogus to me:
>
>
>> -cur.forwardPos();
>> +cur.top().forwardPos();
>
>
> Why bogus? Why do you want to revert it?
To me it s
Le 13/10/2014 14:29, Alfredo Braunstein a écrit :
The fix however seems bogus to me:
-cur.forwardPos();
+cur.top().forwardPos();
Why bogus? Why do you want to revert it?
If you look at the top of the chunk, there is another
forwardPos/backwardPos that could
The problem was indeed correctly identified by JM in changeset 7c3d1d7:
"The problem is the use of cursor movement methods to update cursor.
Cursor::forwardPos() steps into insets, which is not always what we
want. The problem here is that there is a math inset just after the
accepted change, and
On 07/02/2014 04:29 PM, Paul A. Rubin wrote:
Scott Kostyshak lyx.org> writes:
On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes
lyx.org> wrote:
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
The other possibility is to loo
Scott Kostyshak lyx.org> writes:
>
> On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes
lyx.org> wrote:
> > Le 02/07/14 17:07, Richard Heck a écrit :
> >
> >> There was a report from someone who did not have autosave enabled.
> >
> >
> > The other possibility is to look at changes that occurr
On 07/02/2014 03:40 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
Maybe there are two different triggers? When I find some time, I'll play a
bit with autosave.
The other report c
Jean-Marc Lasgouttes wrote:
> Le 02/07/14 17:07, Richard Heck a écrit :
>> There was a report from someone who did not have autosave enabled.
Maybe there are two different triggers? When I find some time, I'll play a
bit with autosave.
> The other possibility is to look at changes that occurred
Richard Heck wrote:
> On 07/01/2014 04:36 PM, Georg Baum wrote:
>> Richard Heck wrote:
>>
>>> That was what I was thinking, too. Just guessing at this point.
>> Yes. It would be really nice if we had a more reliable way to reproduce
>> the crash. OTOH it is good that it does not occur very often;-
On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes wrote:
> Le 02/07/14 17:07, Richard Heck a écrit :
>
>> There was a report from someone who did not have autosave enabled.
>
>
> The other possibility is to look at changes that occurred in Tabular code.
> The main difference that I see is new s
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
The other possibility is to look at changes that occurred in Tabular
code. The main difference that I see is new support for
insert/duplicate-row. Do we have indications that people ha
On 07/01/2014 04:36 PM, Georg Baum wrote:
Richard Heck wrote:
That was what I was thinking, too. Just guessing at this point.
Yes. It would be really nice if we had a more reliable way to reproduce the
crash. OTOH it is good that it does not occur very often;-)
I went over the code again and
On 07/01/2014 04:50 PM, Georg Baum wrote:
Richard Heck wrote:
That was what I was thinking, too. Just guessing at this point.
Another wild guess: Since the backtrace shows autoSave(), and autoSave()
runs in a separate thread and operates on the cloned buffer: Could the non-
thread-safety of th
Richard Heck wrote:
> That was what I was thinking, too. Just guessing at this point.
Another wild guess: Since the backtrace shows autoSave(), and autoSave()
runs in a separate thread and operates on the cloned buffer: Could the non-
thread-safety of the cloning business be the real problem? At
Richard Heck wrote:
> That was what I was thinking, too. Just guessing at this point.
Yes. It would be really nice if we had a more reliable way to reproduce the
crash. OTOH it is good that it does not occur very often;-)
I went over the code again and found and fixed a memory leak (and missing
On 07/01/2014 02:38 PM, Georg Baum wrote:
Richard Heck wrote:
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since
"\begin_inset
smells little bit lik
Richard Heck wrote:
> On 06/30/2014 06:54 PM, Pavel Sanda wrote:
>> Richard Heck wrote:
>>> Paragraph::write, so the crashing call to to_utf8 could come in any of
>>> them. The crashing call certainly isn't the first one, since
>>> "\begin_inset
>> smells little bit like concurrency problem inside
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave
Richard Heck wrote:
> Paragraph::write, so the crashing call to to_utf8 could come in any of
> them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave while using to_utf8 somewhere in ui?
p
Richard Heck wrote:
> The key part is:
>
> #15 0x00a99af0 in lyx::to_utf8(std::basic_string #std::char_traits, std::allocator > const&) ()
> No symbol table info available.
> #16 0x005c6577 in lyx::Paragraph::write(std::ostream&,
> #lyx::BufferParams const&, unsigned long&) const
Not sure how important it is, but looking at
#15 0x00a99af0 in lyx::to_utf8(std::basic_stringstd::char_traits, std::allocator > const&) ()
#16 0x005c6577 in lyx::Paragraph::write(std::ostream&,
lyx::BufferParams const&, unsigned long&) const ()
#17 0x005ed142 in lyx::Te
On 06/29/2014 08:06 AM, Jean-Marc Lasgouttes wrote:
What is thé contents of thé truncated document ?
Here's a longer backtrace:
#0 0x00a99af0 in lyx::to_utf8(std::basic_string,
std::allocator > const&) ()
No symbol table info available.
#1 0x005c6577 in lyx::Paragraph::write
What is thé contents of thé truncated document ?
JMarc
On 29 juin 2014 13:01:08 UTC+02:00, "José Matos" wrote:
>Hi,
> a fedora user submitted the following report
>https://bugzilla.redhat.com/show_bug.cgi?id=1114263
>
>I hope that some of the debug information provided helps to find the
>c
Hi,
a fedora user submitted the following report
https://bugzilla.redhat.com/show_bug.cgi?id=1114263
I hope that some of the debug information provided helps to find the cause of
the crash. :-(
Regards,
--
José Abílio
Am 03.06.2013 11:04, schrieb Vincent van Ravesteijn:
(Someone volunteers to open a bug report so we don't forget ?)
Done:
http://www.lyx.org/trac/ticket/8721
regards Uwe
>
> Could not reproduce (linux, lyx 2.0.6). Maybe more specific steps are
> necessary. Pavel
>
I could reproduce with 2.1git.
Fixing the easy way is easy, the LFUN_PARAGRAPH_PARAMS_APPLY should be send
to all cells individually. However, the more general problem is that there
are cases in which w
#CHEW KOK HON# wrote:
> Dear developers,
>
> I am currently using LyX version 2.0.5.1 and I found a bug in Lyx which will
> trigger crash of program. These are the steps lead to crash:
>
> Steps:
>
> 1) Create a table
>
> 2) Convert it into a long table
>
> 3) Type paragraphs i
Dear developers,
I am currently using LyX version 2.0.5.1 and I found a bug in Lyx which will
trigger crash of program. These are the steps lead to crash:
Steps:
1) Create a table
2) Convert it into a long table
3) Type paragraphs in a few cells
4) Highlight the cells (mu
Le 25/06/2012 22:38, B a écrit :
No I didn't, I installed it from Chakra Linux and Kubuntu with the same
result in both cases.
Could you explain me what can I do to give you a more useful information?
If I can trust the following page
http://apachelog.wordpress.com/2010/03/09/opportunistic-kd
No I didn't, I installed it from Chakra Linux and Kubuntu with the same
result in both cases.
Could you explain me what can I do to give you a more useful information?
On Mon, Jun 25, 2012 at 5:31 PM, LyX Ticket Tracker wrote:
> #8221: Every time that I compile a document L
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();
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();
+
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
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
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
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
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
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
LIES VIOLATED IN
GuiFontLoader.cpp:95
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:37
Aborted (core dumped)
Original Message
Subject:LyX crash after font assert
Date: Mon, 04 Jun 2
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
On 01/11/2012 09:04 PM, Richard Heck wrote:
On 01/11/2012 04:37 PM, Richard Heck wrote:
On 01/11/2012 04:15 PM, Andrew Parsloe wrote:
Given master.lyx and child.lyx (which can be blank or contain text).
1. Open child.lyx
2. Save under a different name -- say test.lyx
3. In test.lyx clear the m
On 01/11/2012 04:37 PM, Richard Heck wrote:
On 01/11/2012 04:15 PM, Andrew Parsloe wrote:
Given master.lyx and child.lyx (which can be blank or contain text).
1. Open child.lyx
2. Save under a different name -- say test.lyx
3. In test.lyx clear the master dependency
(Document>Settings>Document
On 01/11/2012 04:15 PM, Andrew Parsloe wrote:
Given master.lyx and child.lyx (which can be blank or contain text).
1. Open child.lyx
2. Save under a different name -- say test.lyx
3. In test.lyx clear the master dependency (Document>Settings>Document
Class)
4. Compile to pdf
LyX 2.0.2 crashes
Given master.lyx and child.lyx (which can be blank or contain text).
1. Open child.lyx
2. Save under a different name -- say test.lyx
3. In test.lyx clear the master dependency (Document>Settings>Document
Class)
4. Compile to pdf
LyX 2.0.2 crashes (at least under Windows Vista)
LyX 2.0.1 does
Stephan Witt wrote:
> This ticket has lyx-documents attached.
> How can I use them? It gets formatted with line-numbers
> and is therefor useless for download.
look on the very bottom of the page for download link.
pavel
Am 13.10.2010 um 16:13 schrieb LyX Ticket Tracker:
> #6149: lyx crash after doc updates
> -+--
> Reporter: istaon | Owner: lasgouttes
> Type: defect |
Jean-Marc Lasgouttes wrote:
[[Context]] is used to distinguish otherwise identical strings, which could
have different translation dependent on the Context. [[Context]] appears only
in msgid string and should not be repeated in the translated version.
-
You should leave i
Koji Yokota wrote:
> I'm currently updating the Japanese message file
Konnichiwa!
this is just to remind you that we need your translation by Friday.
Domo arigato,
Jürgen
Koji Yokota <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm currently updating the Japanese message file and facing an error in
> which the updated message file causes lyx to crash. Can anyone tell me
> whether this can happen because of any problem in the message file or it
> can be a bug in LyX? Conve
Hi,
I'm currently updating the Japanese message file and facing an error in
which the updated message file causes lyx to crash. Can anyone tell me
whether this can happen because of any problem in the message file or it
can be a bug in LyX? Conversion of the po file by msgfmt emits no error
messag
On Sunday 13 May 2007 21:20:51 Bo Peng wrote:
> Hi, Jose,
>
> See http://bugzilla.lyx.org/show_bug.cgi?id=3600 .
>
> Can I submit the following patch before a proper solution is
> implemented? My understand is that a proper solution will be
> difficult, but avoiding such a crash for now is necessar
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> The complicated part is: what did the user *mean* by doing this?
Dov> Can you think of a realistic case in which the user would want to
Dov> do what you're describing (namely, switch from LyX-Code to
Dov> standard text)
The user should
Bo Peng wrote:
I will submit a patch to prevent such a crash with a FIXME in its
comment. A bugzilla entry will also be created.
Hi, Jose,
See http://bugzilla.lyx.org/show_bug.cgi?id=3600 .
Bo, can I add a comment to bugzilla pointing to this thread? I feel that
often there are discussions
Can you not select the LyX-Code directly, and inset->program listing?
That would at least be clearer on the conceptual level, because you're
going from verbatim to verbatim...
Actually, if I go from lyx-code to listings directly, this problem
will not happen. I removed the lyx-code environment a
I will submit a patch to prevent such a crash with a FIXME in its
comment. A bugzilla entry will also be created.
Hi, Jose,
See http://bugzilla.lyx.org/show_bug.cgi?id=3600 .
Can I submit the following patch before a proper solution is
implemented? My understand is that a proper solution will
Bo Peng wrote:
The complicated part is: what did the user *mean* by doing this? Can you
think of a realistic case in which the user would want to do what you're
describing (namely, switch from LyX-Code to standard text) --- and if
so, what does the user mean by it? And how would the user want the
The complicated part is: what did the user *mean* by doing this? Can you
think of a realistic case in which the user would want to do what you're
describing (namely, switch from LyX-Code to standard text) --- and if
so, what does the user mean by it? And how would the user want the
spaces to be tr
Bo Peng wrote:
1. lyx-code
2. enter
a
123456 (there are four leading spaces)
3. change environment to standard
4. select a and 1
5. cut
a, 12345 are removed.
It is pretty easy to avoid the crash by adding something like right =
min(right, par[pit].size() + 1) after line 304 of
Bo Peng wrote:
Isn't every crash a critical bug?
i would say that it depends on the probability of it happening.
some "critical" bugs are p=0 critical for me personally...
Why nobody is interested?
i don't think people are uninterested, but either busy with other stuff
or unfamiliar with
1. lyx-code
2. enter
a
123456 (there are four leading spaces)
3. change environment to standard
4. select a and 1
5. cut
a, 12345 are removed.
It is pretty easy to avoid the crash by adding something like right =
min(right, par[pit].size() + 1) after line 304 of CutAndPaste.cpp,
On 5/9/07, Bo Peng <[EMAIL PROTECTED]> wrote:
1. create a lyx file
2. layout LyX-code
3. enter something with leading blanks.
a
b
4. select, change layout to standard, the leading blanks of b are not removed.
5. select all, insert ERT. crash.
The problem is that after step 4, the paragraph i
1. create a lyx file
2. layout LyX-code
3. enter something with leading blanks.
a
b
4. select, change layout to standard, the leading blanks of b are not removed.
5. select all, insert ERT. crash.
Assertion triggered in int
lyx::Paragraph::Pimpl::eraseChars(lyx::pos_type, lyx::pos_type, bool)
b
On Tuesday 03 October 2006 17:20, Diego De Rosa wrote:
> Hello,
> I just noticed a bug in LyX: when I do "save" and then I press "page-up"
> key, LyX crashes.
Could you give more details, please? I am running 1.4.3 in Fedora Core 5 and
I don't see this.
> hope this is not a bug already reporte
Hello,
I just noticed a bug in LyX: when I do "save" and then I press "page-up"
key, LyX crashes.
hope this is not a bug already reported.
Regards,
Diego
--
___
Diego De Rosa
Consultant - European Space Agency
Ph.D. Student - University "La Sapienz
Jean-Marc Lasgouttes wrote:
> I think so.
I applied it. The actual bug number is 2202, not 2022.
Jürgen
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> I was about to post almost the same patch :)
Juergen> Good :-)
>> I think yours is just as good. You should probably add a 'using
>> std::max' somewhere, though.
Juergen> Done. What about
Jean-Marc Lasgouttes wrote:
> I was about to post almost the same patch :)
Good :-)
> I think yours is just as good. You should probably add a 'using
> std::max' somewhere, though.
Done. What about the attached patch? Can it be applied?
Jürgen
Index: src/text2.C
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> http://bugzilla.lyx.org/show_bug.cgi?id=2202 Jean-Marc,
Juergen> I found that the attached patch fixes the described crash for
Juergen> me. The cases described in bug 2155 still work. However, I'm
Juergen> not really sur
http://bugzilla.lyx.org/show_bug.cgi?id=2202
Jean-Marc,
I found that the attached patch fixes the described crash for me. The cases
described in bug 2155 still work. However, I'm not really sure I got the
logic. Does this make sense to you?
Jürgen
Index: src/text2.C
===
Sven Schreiber wrote:
> (sorry for new thread, btw is it possible to reply to the
> gmane-transferred mail, I mean are list addresses resolved etc?)
It is possible, this post is created via a news reply to gmane. Even the
obfuscated email-addresses work.
Georg
(sorry for new thread, btw is it possible to reply to the
gmane-transferred mail, I mean are list addresses resolved etc?)
Jean-Marc Lasgouttes wrote:
Sven> "Can't change number of columns in 'simple'"
You have entered a & in a formula, and that confuses LyX. This bug ill
be fixed in 1.3.6, but i
> "Sven" == Sven Schreiber <[EMAIL PROTECTED]> writes:
Sven> When I try to open that file (from lyx-open dialog, or by
Sven> double-clicking), lyx reproducibly crashes (already tried a
Sven> win-reboot, and lyx reconfigure) and gives me the following
Sven> message on the console window:
Sven>
Hi, I have a weird show-stopping problem, and I need the output from the
lyx-file tomorrow for a presentation. Any hints would be highly
appreciated!
(This is with Ruurd's lyx 1.3.5 on win2000 -- if all fails within the
next few hours I will try at home on linux, but I'd rather have a quick
fi
Hello,
just a sidenote: While adding words to the personal dictionary during the
ispell-check I accidentially added a wrong word. So while Lyx had still
opened its spellchecker popup I opened my .ispell_ngerman in kate and
deleted the accidentially added word by hand, save the file and closed
kate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dienstag, 18. Mai 2004 03:59, John Levon wrote:
> On Tue, May 18, 2004 at 01:42:58AM +0200, Kornel Benko wrote:
>
> > The patch I am using now without any crash is attached. The selected fonts may
> > have some unwanted default value, but at least
Maurizio Monge <[EMAIL PROTECTED]> writes:
| #0 0x002a980626e9 in kill () from /lib64/libc.so.6
| #1 0x002a9736b111 in pthread_kill () from /lib64/libpthread.so.0
| #2 0x002a9736b432 in raise () from /lib64/libpthread.so.0
| #3 0x002a980623d2 in raise () from /lib64/libc.so.6
|
On Tue, May 18, 2004 at 01:42:58AM +0200, Kornel Benko wrote:
> The patch I am using now without any crash is attached. The selected fonts may
> have some unwanted default value, but at least you are then able to select your
> own font with the lyx-UI.
Hmm, that's interesting. Why would fromqstr(
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Montag, 17. Mai 2004 15:14, Jean-Marc Lasgouttes wrote:
> > "Maurizio" == Maurizio Monge <[EMAIL PROTECTED]> writes:
>
> Maurizio> Hello. I compiled lyx cvs (lyx-devel) on and amd64-pc-linux,
> Maurizio> with gcc-3.4, latest binutils and qt fon
On Mon, May 17, 2004 at 03:14:42PM +0200, Jean-Marc Lasgouttes wrote:
> The problem seems to be related to the use of the "sans" font family
> which is unknown from qt. Could you try the attached patch which has
> been send by Kornel Benko a while ago?
It looks wrong. For starters, these default
> "Maurizio" == Maurizio Monge <[EMAIL PROTECTED]> writes:
Maurizio> Hello. I compiled lyx cvs (lyx-devel) on and amd64-pc-linux,
Maurizio> with gcc-3.4, latest binutils and qt font-end (qt-3.3.2).
Maurizio> I get:
Maurizio> terminate called after throwing an instance of
Maurizio> 'std
Hello.
I compiled lyx cvs (lyx-devel) on and amd64-pc-linux, with gcc-3.4, latest
binutils and qt font-end (qt-3.3.2).
I get:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
Aborted
Have you an
Hello.
I compiled lyx cvs (lyx-devel) on and amd64-pc-linux, with gcc-3.4, latest
binutils and qt font-end (qt-3.3.2).
I get:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct NULL not valid
Aborted
Have you an
On Sun, 18 Apr 2004 17:29:18 +0100
John Levon <[EMAIL PROTECTED]> wrote:
>
> I can't reproduce this problem at all
Strange - I get it every time I try, so I guess it might be something with my
environment...
I'll check it up, and eventually come back to it if I manage to understand why it
h
On Sun, Apr 04, 2004 at 06:16:21PM +0200, Rune Hansen wrote:
> I have found a bug in the lyx spellchecker that makes lyx crach
>
> To reproduce the crash:
>
> 1. Open several documents in lyx (with some spelling errors in it...)
>
> 2. Start spellchecker in one of the documents - when dialogb
1 - 100 of 238 matches
Mail list logo
