(gdb) where
#0 0x003d932301b5 in raise () from /lib64/libc.so.6
#1 0x003d93231b20 in abort () from /lib64/libc.so.6
#2 0x0092c5e9 in lyx::support::abort () at abort.cpp:25
#3 0x005383f7 in error_handler (err_sig=11) at LyX.cpp:787
#4 signal handler called
#5
Neal Becker wrote:
(gdb) where
#0 0x003d932301b5 in raise () from /lib64/libc.so.6
#1 0x003d93231b20 in abort () from /lib64/libc.so.6
#2 0x0092c5e9 in lyx::support::abort () at abort.cpp:25
#3 0x005383f7 in error_handler (err_sig=11) at LyX.cpp:787
#4 signal handler
Abdelrazak Younes wrote:
Neal Becker wrote:
(gdb) where
#0 0x003d932301b5 in raise () from /lib64/libc.so.6
#1 0x003d93231b20 in abort () from /lib64/libc.so.6
#2 0x0092c5e9 in lyx::support::abort () at abort.cpp:25
#3 0x005383f7 in error_handler (err_sig=11) at
(gdb) where
#0 0x003d932301b5 in raise () from /lib64/libc.so.6
#1 0x003d93231b20 in abort () from /lib64/libc.so.6
#2 0x0092c5e9 in lyx::support::abort () at abort.cpp:25
#3 0x005383f7 in error_handler (err_sig=11) at LyX.cpp:787
#4
#5 0x005ff90a in
Neal Becker wrote:
(gdb) where
#0 0x003d932301b5 in raise () from /lib64/libc.so.6
#1 0x003d93231b20 in abort () from /lib64/libc.so.6
#2 0x0092c5e9 in lyx::support::abort () at abort.cpp:25
#3 0x005383f7 in error_handler (err_sig=11) at LyX.cpp:787
#4
#5
Abdelrazak Younes wrote:
> Neal Becker wrote:
>> (gdb) where
>> #0 0x003d932301b5 in raise () from /lib64/libc.so.6
>> #1 0x003d93231b20 in abort () from /lib64/libc.so.6
>> #2 0x0092c5e9 in lyx::support::abort () at abort.cpp:25
>> #3 0x005383f7 in error_handler
: +1-206-265-7951
==
Start with:
lyx test.lyx
Create the new document (dialog box).
Type a sentence into the new document.
Type Ctrl-S.
Type Ctrl-Q.
Leads to a core dump.
File, test.lyx
: +1-206-265-7951
==
Start with:
lyx test.lyx
Create the new document (dialog box).
Type a sentence into the new document.
Type Ctrl-S.
Type Ctrl-Q.
Leads to a core dump.
File, test.lyx
Jeremy C. Reed [EMAIL PROTECTED] writes:
| (I have emailed about core dumps on close on NetBSD many times. I am the
| package maintainer for NetBSD's lyx. I have provided a patch for this
| package so it won't core dump on close. I wish it would be included in
| lyx's source.)
It seems
"Jeremy C. Reed" <[EMAIL PROTECTED]> writes:
| (I have emailed about core dumps on close on NetBSD many times. I am the
| package maintainer for NetBSD's lyx. I have provided a patch for this
| package so it won't core dump on close. I wish it would be included in
| lyx's so
(I have emailed about core dumps on close on NetBSD many times. I am the
package maintainer for NetBSD's lyx. I have provided a patch for this
package so it won't core dump on close. I wish it would be included in
lyx's source.)
On DragonFly operating system, there is a core dump when exiting
(I have emailed about core dumps on close on NetBSD many times. I am the
package maintainer for NetBSD's lyx. I have provided a patch for this
package so it won't core dump on close. I wish it would be included in
lyx's source.)
On DragonFly operating system, there is a core dump when exiting
. Martin Vermeer advised
me to get a core dump on the next occasion that I got a crash. That has been
done and the core dump and Martin's comments are included below.
All I would add to this is that this was not preceded by the use of the
PageUp/Page Down keys and neither was I involved in an Undo
samar j. singh wrote:
All I would add to this is that this was not preceded by the use of the
PageUp/Page Down keys and neither was I involved in an Undo operation
immediately before the crash to the best of my recollection.
It would help a lot if you'd manage to come up with a recipe how to
to start lyx preceded with the core dump pre-requisite commands.
samar
continue to start lyx preceded with the core dump pre-requisite commands.
It might help. I tried to read the backtrace but I couldn't make much sense
out of it apart from what Martin already mentioned.
Did you compile with --enable-stdlib-debug ? That might give some additional
information
Juergen Spitzmueller wrote:
Would it help if you had more of these reports? In that case, I would
continue to start lyx preceded with the core dump pre-requisite commands.
It might help. I tried to read the backtrace but I couldn't make much sense
out of it apart from what Martin already
if you had more of these reports? In that case, I would
continue to start lyx preceded with the core dump pre-requisite commands.
It might help. I tried to read the backtrace but I couldn't make much sense
out of it apart from what Martin already mentioned.
Did you compile with --enable-stdlib
On Monday 30 January 2006 23:16, Juergen Spitzmueller wrote:
Juergen Spitzmueller wrote:
Would it help if you had more of these reports? In that case, I would
continue to start lyx preceded with the core dump pre-requisite
commands.
It might help. I tried to read the backtrace but I
samar j. singh wrote:
I am quite happy with slowing down the lyx if it helps. Please let me have
more specific instructions. Would you like me to compile gdb or something
else.
The two suggestions are:
1. run lyx -dbg action instead of lyx. If it crashes, the console might
have spit out some
samar j. singh wrote:
Let me understand this correctly. Would you like me to do the preparatory
work for the core dump and then start lyx with the -dbg option after that?
No, I mean without gdb. Just run lyx -dbg action normally.
No I dont use preview latex. I dont need to do any significant
On Monday 30 January 2006 23:28, Juergen Spitzmueller wrote:
samar j. singh wrote:
I am quite happy with slowing down the lyx if it helps. Please let me
have more specific instructions. Would you like me to compile gdb or
something else.
The two suggestions are:
1. run lyx -dbg action
samar j. singh wrote:
Still a bit of confusion. In 2 above it is compiling lyx that you are
talking about, is that correct?
yes.
Should I wait for 1.4pre4?
you could try the -dbg action thing already with pre3, if you want.
Thanks,
Jürgen
On Monday 30 January 2006 23:45, Juergen Spitzmueller wrote:
samar j. singh wrote:
Still a bit of confusion. In 2 above it is compiling lyx that you are
talking about, is that correct?
yes.
Should I wait for 1.4pre4?
you could try the -dbg action thing already with pre3, if you
. Martin Vermeer advised
me to get a core dump on the next occasion that I got a crash. That has been
done and the core dump and Martin's comments are included below.
All I would add to this is that this was not preceded by the use of the
PageUp/Page Down keys and neither was I involved in an Undo
samar j. singh wrote:
> All I would add to this is that this was not preceded by the use of the
> PageUp/Page Down keys and neither was I involved in an Undo operation
> immediately before the crash to the best of my recollection.
It would help a lot if you'd manage to come up with a recipe how
these reports? In that case, I would
continue to start lyx preceded with the core dump pre-requisite commands.
samar
orts? In that case, I would
> continue to start lyx preceded with the core dump pre-requisite commands.
It might help. I tried to read the backtrace but I couldn't make much sense
out of it apart from what Martin already mentioned.
Did you compile with --enable-stdlib-debug ? That might give some
Juergen Spitzmueller wrote:
> > Would it help if you had more of these reports? In that case, I would
> > continue to start lyx preceded with the core dump pre-requisite commands.
>
> It might help. I tried to read the backtrace but I couldn't make much sense
> out of it a
h. It indicates, however, that it might be a new bug (in 1.4) ;-)
>
> > Would it help if you had more of these reports? In that case, I would
> > continue to start lyx preceded with the core dump pre-requisite commands.
>
> It might help. I tried to read the backtrace but I couldn'
On Monday 30 January 2006 23:16, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > > Would it help if you had more of these reports? In that case, I would
> > > continue to start lyx preceded with the core dump pre-requisite
> > > commands.
> >
samar j. singh wrote:
> I am quite happy with slowing down the lyx if it helps. Please let me have
> more specific instructions. Would you like me to compile gdb or something
> else.
The two suggestions are:
1. run "lyx -dbg action" instead of "lyx". If it crashes, the console might
have spit
samar j. singh wrote:
> Let me understand this correctly. Would you like me to do the preparatory
> work for the core dump and then start lyx with the -dbg option after that?
No, I mean without gdb. Just run lyx -dbg action normally.
> No I dont use preview latex. I dont need
On Monday 30 January 2006 23:28, Juergen Spitzmueller wrote:
> samar j. singh wrote:
> > I am quite happy with slowing down the lyx if it helps. Please let me
> > have more specific instructions. Would you like me to compile gdb or
> > something else.
>
> The two suggestions are:
> 1. run "lyx
samar j. singh wrote:
> Still a bit of confusion. In 2 above it is compiling lyx that you are
> talking about, is that correct?
yes.
> Should I wait for 1.4pre4?
you could try the -dbg action thing already with pre3, if you want.
Thanks,
Jürgen
On Monday 30 January 2006 23:45, Juergen Spitzmueller wrote:
> samar j. singh wrote:
> > Still a bit of confusion. In 2 above it is compiling lyx that you are
> > talking about, is that correct?
>
> yes.
>
> > Should I wait for 1.4pre4?
>
> you could try the -dbg action thing already with pre3,
I updated to new lyx release on NetBSD 2.1.
I saw my previous patch to workaround the core dump exit issue for NetBSD
didn't apply any more, so I didn't patch it. This old patch (now not used)
was simply:
+/* For some reason it doesn't indicate it is locked on NetBSD
+ resulting in a Error
I updated to new lyx release on NetBSD 2.1.
I saw my previous patch to workaround the core dump exit issue for NetBSD
didn't apply any more, so I didn't patch it. This old patch (now not used)
was simply:
+/* For some reason it doesn't indicate it is locked on NetBSD
+ resulting in a Error
On Sat, Feb 07, 2004 at 11:59:56AM -0700, David Raymond wrote:
Lyx just dumped core again while I was working in an offset
equation. Here is a backtrace.
What version of LyX is that?
[Well, in any case, chances for undo related crashs in anything but the
current (not-to-be-used...) 1.4.0cvs
This was 1.3.3 using qt. I got 3 core dumps in a few days doing
more or less the same thing -- messing with offset equations. I'm
now running the xforms version to see if it happens to me there.
(Never did in the past.)
Dave Raymond
Andre Poenitz writes:
On Sat, Feb 07, 2004 at 11:59:56AM
On Sat, Feb 07, 2004 at 11:59:56AM -0700, David Raymond wrote:
>
> Lyx just dumped core again while I was working in an offset
> equation. Here is a backtrace.
What version of LyX is that?
[Well, in any case, chances for undo related crashs in anything but the
current (not-to-be-used...)
This was 1.3.3 using qt. I got 3 core dumps in a few days doing
more or less the same thing -- messing with offset equations. I'm
now running the xforms version to see if it happens to me there.
(Never did in the past.)
Dave Raymond
Andre Poenitz writes:
> On Sat, Feb 07, 2004 at 11:59:56AM
Lyx just dumped core again while I was working in an offset
equation. Here is a backtrace.
Dave Raymond
---
(gdb) bt
#0 0x4076c561 in kill () from /lib/libc.so.6
#1 0x40a7f741 in pthread_kill () from /lib/libpthread.so.0
#2 0x40a7fa4b in raise () from /lib/libpthread.so.0
#3
Lyx just dumped core again while I was working in an offset
equation. Here is a backtrace.
Dave Raymond
---
(gdb) bt
#0 0x4076c561 in kill () from /lib/libc.so.6
#1 0x40a7f741 in pthread_kill () from /lib/libpthread.so.0
#2 0x40a7fa4b in raise () from /lib/libpthread.so.0
#3
On Wed, Sep 17, 2003 at 06:35:10PM +0100, Angus Leeming spake thusly:
Martin Vermeer wrote:
Yes! This does the trick.
Great! I wonder what changed between 13x and 14x in this regard.
Shall I prepare a patch?
Why not.
Here's the patch.
Notes:
1) To suppress the bug, it would be
Martin Vermeer wrote:
3) I discovered a new (?) bug:
a) create an inset, e.g., note;
b) insert a math inset into it;
c) copy and paste the math inset to inside the note inset;
d) exit without saving.
I don't see it.
Alfredo
Martin Vermeer wrote:
Here's the patch.
And I understand how it is triggered. We have a sort of 'race'
condition between the destruction of two static variables.
In gettext.C:
Messages getLyXMessages() {
static Messages lyx_messages;
return lyx_messages;
}
In Dialogs.C
Alfredo Braunstein wrote:
Martin Vermeer wrote:
3) I discovered a new (?) bug:
a) create an inset, e.g., note;
b) insert a math inset into it;
c) copy and paste the math inset to inside the note inset;
d) exit without saving.
I don't see it.
No, it's going to be a compiler-specific
On Thu, Sep 18, 2003 at 09:25:41AM +, Angus Leeming wrote:
Alfredo Braunstein wrote:
Martin Vermeer wrote:
3) I discovered a new (?) bug:
a) create an inset, e.g., note;
b) insert a math inset into it;
c) copy and paste the math inset to inside the note inset;
d) exit
Andre Poenitz wrote:
As the destruction order is the reversed construction order you
could specify a certain order if you need to.
Let's just not go there in the first place.
--
Angus
On Thu, Sep 18, 2003 at 09:45:06AM +, Angus Leeming wrote:
Andre Poenitz wrote:
As the destruction order is the reversed construction order you
could specify a certain order if you need to.
Let's just not go there in the first place.
Fine with me.
Andre'
On Thu, Sep 18, 2003 at 09:05:57AM +, Angus Leeming spake thusly:
Martin Vermeer wrote:
Here's the patch.
And I understand how it is triggered. We have a sort of 'race'
condition between the destruction of two static variables.
In gettext.C:
Messages getLyXMessages() {
On Thursday 18 September 2003 11:58 am, Martin Vermeer wrote:
your patch and apply mine. Yours is a work around broken behaviour.
Mine cures the source of the breakage.
I very much agree -- provided it works. (Do you mean the dialogs.diff
patch you posted here much earlier? But you called
On Thu, Sep 18, 2003 at 12:57:40PM +, Angus Leeming spake thusly:
On Thursday 18 September 2003 11:58 am, Martin Vermeer wrote:
your patch and apply mine. Yours is a work around broken behaviour.
Mine cures the source of the breakage.
I very much agree -- provided it works. (Do you
Martin Vermeer wrote:
ps, see if you can trigger the bug with current cvs. Also the math one...
Yes, the bug is gone. So is the math bug.
Good news indeed.
These kind of bugs based upon unspecified compiler behaviour are hell
to hunt down. I think we did our good deed for this week!
On Wed, Sep 17, 2003 at 06:35:10PM +0100, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
> > Yes! This does the trick.
>
> Great! I wonder what changed between 13x and 14x in this regard.
>
> > Shall I prepare a patch?
>
> Why not.
Here's the patch.
Notes:
1) To suppress the bug, it
Martin Vermeer wrote:
> 3) I discovered a new (?) bug:
>
> a) create an inset, e.g., note;
> b) insert a math inset into it;
> c) copy and paste the math inset to inside the note inset;
> d) exit without saving.
I don't see it.
Alfredo
Martin Vermeer wrote:
> Here's the patch.
And I understand how it is triggered. We have a sort of 'race'
condition between the destruction of two static variables.
In gettext.C:
Messages & getLyXMessages() {
static Messages lyx_messages;
return lyx_messages;
}
In Dialogs.C
Alfredo Braunstein wrote:
> Martin Vermeer wrote:
>
>> 3) I discovered a new (?) bug:
>>
>> a) create an inset, e.g., note;
>> b) insert a math inset into it;
>> c) copy and paste the math inset to inside the note inset;
>> d) exit without saving.
>
> I don't see it.
No, it's going to be a
On Thu, Sep 18, 2003 at 09:25:41AM +, Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
> > Martin Vermeer wrote:
> >
> >> 3) I discovered a new (?) bug:
> >>
> >> a) create an inset, e.g., note;
> >> b) insert a math inset into it;
> >> c) copy and paste the math inset to inside the note
Andre Poenitz wrote:
> As the destruction order is the reversed construction order you
> could specify a certain order if you need to.
Let's just not go there in the first place.
--
Angus
On Thu, Sep 18, 2003 at 09:45:06AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > As the destruction order is the reversed construction order you
> > could specify a certain order if you need to.
>
> Let's just not go there in the first place.
Fine with me.
Andre'
On Thu, Sep 18, 2003 at 09:05:57AM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> > Here's the patch.
>
> And I understand how it is triggered. We have a sort of 'race'
> condition between the destruction of two static variables.
>
> In gettext.C:
> Messages & getLyXMessages() {
On Thursday 18 September 2003 11:58 am, Martin Vermeer wrote:
> > your patch and apply mine. Yours is a work around broken behaviour.
> > Mine cures the source of the breakage.
>
> I very much agree -- provided it works. (Do you mean the dialogs.diff
> patch you posted here much earlier? But you
On Thu, Sep 18, 2003 at 12:57:40PM +, Angus Leeming spake thusly:
> On Thursday 18 September 2003 11:58 am, Martin Vermeer wrote:
> > > your patch and apply mine. Yours is a work around broken behaviour.
> > > Mine cures the source of the breakage.
> >
> > I very much agree -- provided it
Martin Vermeer wrote:
>> ps, see if you can trigger the bug with current cvs. Also the math one...
>
> Yes, the bug is gone. So is the math bug.
Good news indeed.
> These kind of bugs based upon unspecified compiler behaviour are hell
> to hunt down. I think we did our good deed for this week!
On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
Martin Vermeer wrote:
H... is it possible that lang_ is being accessed after the
containing class Messages::Pimpl has been destroyed?
If so, I guess that this is the kludge. Thereafter we'd have to
ascertain
Martin Vermeer [EMAIL PROTECTED] writes:
| On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
|
Martin Vermeer wrote:
H... is it possible that lang_ is being accessed after the
containing class Messages::Pimpl has been destroyed?
If so, I guess that this is the
On Wed, Sep 17, 2003 at 09:36:28AM +0200, Lars Gullik Bjønnes spake thusly:
Martin Vermeer [EMAIL PROTECTED] writes:
| On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
|
Martin Vermeer wrote:
H... is it possible that lang_ is being accessed after the
Martin Vermeer [EMAIL PROTECTED] writes:
Do we have any static objects? (we shouldn't) Global objects?
| Yes! in gettext.C:
| 24 Messages getLyXMessages()
| 25 {
| 26 static Messages lyx_messages;
| 27
| 28 return lyx_messages;
| 29 }
| 30
|
On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
Martin Vermeer [EMAIL PROTECTED] writes:
Do we have any static objects? (we shouldn't) Global objects?
| Yes! in gettext.C:
| 24 Messages getLyXMessages()
| 25 {
| 26 static Messages
Martin Vermeer [EMAIL PROTECTED] writes:
| On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
Martin Vermeer [EMAIL PROTECTED] writes:
Do we have any static objects? (we shouldn't) Global objects?
| Yes! in gettext.C:
| 24 Messages getLyXMessages()
|
Martin Vermeer [EMAIL PROTECTED] writes:
| On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
Martin Vermeer [EMAIL PROTECTED] writes:
Do we have any static objects? (we shouldn't) Global objects?
| Yes! in gettext.C:
| 24 Messages getLyXMessages()
|
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake thusly:
what happens if you function call replace the default args with
N_(...)
?
and use _(...) where the vars are used?
I did that... the new strings appear in the output.
Or remove the _(..) from the default args
Martin Vermeer wrote:
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake
thusly:
what happens if you function call replace the default args with
N_(...)
?
N_(...) is just an empty macro (does nothing --- see src/gettext.h)
that enables the po files to document
On Wed, Sep 17, 2003 at 11:28:36AM +0100, Angus Leeming spake thusly:
Martin Vermeer wrote:
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake
thusly:
what happens if you function call replace the default args with
N_(...)
?
N_(...) is just an empty macro
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake thusly:
...
Or remove the _(..) from the default args completely?
--
Lgb
Yes, then the error goes away. But do we want that? We want Cancel
and Close translated, don't we?
- Martin
pgp0.pgp
Description:
Martin Vermeer wrote:
On Wed, Sep 17, 2003 at 11:28:36AM +0100, Angus Leeming spake
thusly:
Martin Vermeer wrote:
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes
spake
thusly:
what happens if you function call replace the default args with
N_(...)
?
On Wed, Sep 17, 2003 at 02:15:35PM +0100, Angus Leeming spake thusly:
Martin Vermeer wrote:
...
Like this?
No, because this is code executed when the xformsBC constructor is
invoked.
xformsBC(ButtonController const ,
-string const = _(Cancel), string const =
Martin Vermeer wrote:
Yes, I know how gettext works -- I did the first Dutch and Finnish
translations remember? But I still don't get what Lars wanted
me to do. Please bend it in copperwire for me. Remember I'm a little
dumb :-)
My misunderstanding.
Ok, I think that Lars is suggesting
//
On Wed, Sep 17, 2003 at 02:53:27PM +0100, Angus Leeming spake thusly:
Martin Vermeer wrote:
Yes, I know how gettext works -- I did the first Dutch and Finnish
translations remember? But I still don't get what Lars wanted
me to do. Please bend it in copperwire for me. Remember I'm a little
Martin Vermeer wrote:
or presumably alternatively:
// file frontends/xforms/xformsBC.C
void xformsBC::setButtonLabel(FL_OBJECT * obj, string const
label) const
{
fl_set_object_label(obj, _(label).c_str());
}
Yes! This bites. At least for Cancel and Close.
Now the same for
Angus Leeming wrote:
Incidentally, maybe a script would help automate the changing of
those _(Minipage settings) to N_(...)
for file in Form*.C; do
sed 's/\(^[ ]*: base_class([^_]*\)_/\1N_/' $file tmp
cmp -s $file tmp continue
diff -u $file tmp
mv -i tmp $file
done
Hmmm. Dunno
On Wed, Sep 17, 2003 at 04:32:50PM +0100, Angus Leeming spake thusly:
...
or alternatively:
void FormDialogView::prepare_to_show()
{
...
if (!lyxrc.dialogs_iconify_with_main)
- fl_winicontitle(form()-window, getTitle().c_str());
+
Martin Vermeer wrote:
Yes! This does the trick.
Great! I wonder what changed between 13x and 14x in this regard.
Shall I prepare a patch?
Why not.
By the way, I run CVS LyX uninstalled. Relevant?
Not to the fact that the code is crashing, no.
What I don't like though is that
Looking deeper, LOCALEDIR should be ${INSTALL_DIR}/share/locale I
think
Angus
| Install locally. Something like this should do the trick.
| Note that the important line is the penultimate one.
| See main.C and thereafter the code in ${LYX_TOP_DIR}/intl
| $
On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> > H... is it possible that lang_ is being accessed after the
> > containing class Messages::Pimpl has been destroyed?
>
> If so, I guess that this is the kludge. Thereafter we'd have to
>
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
|
>> Martin Vermeer wrote:
>> > H... is it possible that lang_ is being accessed after the
>> > containing class Messages::Pimpl has been destroyed?
>>
>> If so, I guess that
On Wed, Sep 17, 2003 at 09:36:28AM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
> |
> >> Martin Vermeer wrote:
> >> > H... is it possible that lang_ is being accessed
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Do we have any static objects? (we shouldn't) Global objects?
>
| Yes! in gettext.C:
>
| 24 Messages & getLyXMessages()
| 25 {
| 26 static Messages lyx_messages;
| 27
| 28 return lyx_messages;
| 29 }
| 30
|
On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> Do we have any static objects? (we shouldn't) Global objects?
> >
> | Yes! in gettext.C:
> >
> | 24 Messages & getLyXMessages()
> | 25 {
> | 26
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
>>
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> >> Do we have any static objects? (we shouldn't) Global objects?
>> >
>> | Yes! in gettext.C:
>> >
>> | 24
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
>>
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> >> Do we have any static objects? (we shouldn't) Global objects?
>> >
>> | Yes! in gettext.C:
>> >
>> | 24
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake thusly:
> what happens if you function call replace the default args with
> N_(...)
?
> and use _(...) where the vars are used?
I did that... the new strings appear in the output.
> Or remove the _(..) from the default args
Martin Vermeer wrote:
> On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake
> thusly:
>
>> what happens if you function call replace the default args with
>> N_(...)
>
> ?
N_(...) is just an empty macro (does nothing --- see src/gettext.h)
that enables the po files to
On Wed, Sep 17, 2003 at 11:28:36AM +0100, Angus Leeming spake thusly:
> Martin Vermeer wrote:
>
> > On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake
> > thusly:
> >
> >> what happens if you function call replace the default args with
> >> N_(...)
> >
> > ?
>
> N_(...) is
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake thusly:
...
> Or remove the _(..) from the default args completely?
>
> --
> Lgb
Yes, then the error goes away. But do we want that? We want "Cancel"
and "Close" translated, don't we?
- Martin
pgp0.pgp
Martin Vermeer wrote:
> On Wed, Sep 17, 2003 at 11:28:36AM +0100, Angus Leeming spake
thusly:
>
>> Martin Vermeer wrote:
>>
>> > On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes
spake
>> > thusly:
>> >
>> >> what happens if you function call replace the default args with
>> >>
On Wed, Sep 17, 2003 at 02:15:35PM +0100, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
...
> >
> > Like this?
>
> No, because this is code executed when the xformsBC constructor is
> invoked.
> xformsBC(ButtonController const &,
> -string const & = _("Cancel"),
Martin Vermeer wrote:
> Yes, I know how gettext works -- I did the first Dutch and Finnish
> translations remember? But I still don't get what Lars wanted
> me to do. Please bend it in copperwire for me. Remember I'm a little
> dumb :-)
My misunderstanding.
Ok, I think that Lars is suggesting
1 - 100 of 320 matches
Mail list logo
