OK then. Enrico earlier agreed with this and then we will have more time
to
fix this properly.
Done. I've also reopened the bug report with a comment.
this starts to be pita :(
I updated from svn on July 17 evening, and the GCC3 bug is still
there.
are you sure you havent
Pavel Sanda [EMAIL PROTECTED] writes:
are you sure you havent frontend_helpers.cpp patched by some previous
work ? looking into source i dont see how this can happen.
I might have messed things up, but I'm pretty sure.
I applied Enrico's last patch (try/catch solution) with success.
BTW with trac, trying to display frontend_helpers.cpp redirects me to
http://tug.org/TeXnik/ ???
this happens not only with this file.
Could it come from the
\author: Herbert Voß
line located in the preamble?
no, other files with this line work well.
pavel
BTW with trac, trying to display frontend_helpers.cpp redirects me to
http://tug.org/TeXnik/ ???
this happens not only with this file.
FYI:
$ wget
http://www.lyx.org/trac/browser/lyx-devel/tags/lyx-1_4_4/src/frontends/controllers/tex_helpers.C
> > > OK then. Enrico earlier agreed with this and then we will have more time
> > > to
> > > fix this properly.
> >
> > Done. I've also reopened the bug report with a comment.
this starts to be pita :(
> I updated from svn on July 17 evening, and the GCC3 bug is still
> there.
are you sure
Pavel Sanda <[EMAIL PROTECTED]> writes:
>
> are you sure you havent frontend_helpers.cpp patched by some previous
> work ? looking into source i dont see how this can happen.
I might have messed things up, but I'm pretty sure.
>
> > I applied Enrico's last patch (try/catch solution) with
> > > BTW with trac, trying to display frontend_helpers.cpp redirects me to
> > > http://tug.org/TeXnik/ ???
> >
> > this happens not only with this file.
>
> Could it come from the
> \author: Herbert Voß
> line located in the preamble?
no, other files with this line work well.
pavel
> > > > BTW with trac, trying to display frontend_helpers.cpp redirects me to
> > > > http://tug.org/TeXnik/ ???
> > >
> > > this happens not only with this file.
FYI:
$ wget
Jürgen Spitzmüller [EMAIL PROTECTED] writes:
José Matos wrote:
OK then. Enrico earlier agreed with this and then we will have more time to
fix this properly.
Done. I've also reopened the bug report with a comment.
I updated from svn on July 17 evening, and the GCC3 bug is still
there.
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>
> José Matos wrote:
> > OK then. Enrico earlier agreed with this and then we will have more time to
> > fix this properly.
>
> Done. I've also reopened the bug report with a comment.
I updated from svn on July 17 evening, and the GCC3 bug is
On Fri, Jul 13, 2007 at 01:16:31PM +0200, Pavel Sanda wrote:
The exception is thrown by the locale constructor, not when the
ordering is performed.
are you sure this holds for all previous crashes ?
Yes, I am pretty sure.
--
Enrico
On Fri, Jul 13, 2007 at 01:16:31PM +0200, Pavel Sanda wrote:
> > The exception is thrown by the locale constructor, not when the
> > ordering is performed.
>
> are you sure this holds for all previous crashes ?
Yes, I am pretty sure.
--
Enrico
The exception is thrown by the locale constructor, not when the
ordering is performed.
are you sure this holds for all previous crashes ?
but even if this is not true, we can add one 'idle' call
of loc() inside try block which would catch it beforehead.
pavel
> The exception is thrown by the locale constructor, not when the
> ordering is performed.
are you sure this holds for all previous crashes ?
but even if this is not true, we can add one 'idle' call
of loc() inside try block which would catch it beforehead.
pavel
Enrico Forestieri [EMAIL PROTECTED] writes:
Yes, this is r18988 striking again :(
I don't think that this is related to the platform but rather to the
compiler version. I think that gcc 3.x is missing some locale facets.
Jean-Pierre, does the attached patch solve the bug for you?
Pavel == Pavel Sanda [EMAIL PROTECTED] writes:
Anyway, after r18988 LyX is not so much forgiving about wrong
locales. On Linux, try for example:
$ env LC_ALL=foo ./src/lyx-qt4
and you will get that exception, too.
Pavel Ouch. What if we instead of using multiple #ifs catch the
Pavel
On Wednesday 11 July 2007 20:36:25 Enrico Forestieri wrote:
Yes, this is r18988 striking again :(
I don't think that this is related to the platform but rather to the
compiler version. I think that gcc 3.x is missing some locale facets.
Jean-Pierre, does the attached patch solve the bug for
On Thu, Jul 12, 2007 at 10:05:09AM +0100, José Matos wrote:
On Wednesday 11 July 2007 20:36:25 Enrico Forestieri wrote:
Yes, this is r18988 striking again :(
I don't think that this is related to the platform but rather to the
compiler version. I think that gcc 3.x is missing some
On Thu, Jul 12, 2007 at 09:26:55AM +0200, Jean-Marc Lasgouttes wrote:
Pavel == Pavel Sanda [EMAIL PROTECTED] writes:
Anyway, after r18988 LyX is not so much forgiving about wrong
locales. On Linux, try for example:
$ env LC_ALL=foo ./src/lyx-qt4
and you will get that exception,
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
This one would also catch MSVC, which AFAIK has no problem with
the locale sorting.
OK. You can commit the change.
--
Enrico
--
José Abílio
On Thu, Jul 12, 2007 at 10:53:54AM +0100, José Matos wrote:
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
This one would also catch MSVC, which AFAIK has no problem with
the locale sorting.
OK. You can commit the change.
I did it.
--
Enrico
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
This one would also catch MSVC, which AFAIK has no problem with
the locale sorting.
OK. You can commit the change.
even if this change helps for solaris i fear many crashes on systems
with strangely set locales. the changeset
Pavel Sanda wrote:
even if this change helps for solaris i fear many crashes on systems
with strangely set locales. the changeset should be reverted back until
we know how safely detect the error.
FWIW, I agree.
Jürgen
Pavel Sanda wrote:
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
This one would also catch MSVC, which AFAIK has no problem with
the locale sorting.
OK. You can commit the change.
even if this change helps for solaris i fear many crashes on systems
with strangely set locales.
What do you mean by handling the exception? Fallback to the non wchar_t
yes
solution if an exception is caught? For this to work the choice of
using wchar_t or not must be done at run-time; unfortunately the source
code is really not ready to do that now (lots of #ifdef).
wont be
On Thu, Jul 12, 2007 at 12:54:39PM +0200, Pavel Sanda wrote:
wont be possible to avoid any ifdefs by doing something like :
try
locale stuff (init+sort);
catch any_error: do non_locale stuff
Note that this is used in a sorting context, so the comparison
should be as fast as possible. I
Note that this is used in a sorting context, so the comparison
should be as fast as possible. I don't think that the try/catch
we are sorting some ~50 items. anyway it can be written that
try block is entered only once per one sorting.
pavel
Pavel Sanda wrote:
even if this change helps for solaris i fear many crashes on systems
with strangely set locales.
I even get the crash by
- LANG=en_EN lyx
- Tools-Preferences
Jürgen
Jürgen Spitzmüller wrote:
even if this change helps for solaris i fear many crashes on systems
with strangely set locales.
I even get the crash by
- LANG=en_EN lyx
- Tools-Preferences
For 1.5.0, I propose the attached.
Jürgen
Index: src/frontends/controllers/frontend_helpers.cpp
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
even if this change helps for solaris i fear many crashes on systems
with strangely set locales.
I even get the crash by
- LANG=en_EN lyx
- Tools-Preferences
For 1.5.0, I propose the attached.
+1.
By the way, I just had a look at bug
On Thursday 12 July 2007 16:51:55 Jürgen Spitzmüller wrote:
For 1.5.0, I propose the attached.
Jürgen
OK then. Enrico earlier agreed with this and then we will have more time to
fix this properly.
--
José Abílio
On Thu, Jul 12, 2007 at 05:18:04PM +0100, José Matos wrote:
On Thursday 12 July 2007 16:51:55 Jürgen Spitzmüller wrote:
For 1.5.0, I propose the attached.
Jürgen
OK then. Enrico earlier agreed with this and then we will have more time to
fix this properly.
Please, wait a minute. I
José Matos wrote:
OK then. Enrico earlier agreed with this and then we will have more time to
fix this properly.
Done. I've also reopened the bug report with a comment.
Jürgen
Enrico Forestieri wrote:
Please, wait a minute. I have another option.
too late.
Jürgen
On Thursday 12 July 2007 17:26:54 Enrico Forestieri wrote:
I have another option.
Tell us more. :-)
--
Enrico
--
José Abílio
On Thu, Jul 12, 2007 at 06:32:28PM +0200, Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
Please, wait a minute. I have another option.
too late.
No problem. The attached patch should solve the problems related
to sorting according to the locale rules. I think that there is
no other way.
On Thu, Jul 12, 2007 at 05:36:03PM +0100, José Matos wrote:
On Thursday 12 July 2007 17:26:54 Enrico Forestieri wrote:
I have another option.
Tell us more. :-)
The exception is thrown by the locale constructor, not when the
ordering is performed. So, we catch it there and then either
use
On Thursday 12 July 2007 18:06:42 Enrico Forestieri wrote:
The exception is thrown by the locale constructor, not when the
ordering is performed. So, we catch it there and then either
use the locale facilities or the normal ordering. See patch
in the other post.
I saw the patch and I agree
José Matos wrote:
I saw the patch and I agree with the way it is done. This time though I
will be on the safe side (read chicken) and I would suggest to delay this
for 1.5.1. OK?
I was about to say the same. The patch looks correct, but the bug is not too
crucial to get it in urgently.
On Thu, Jul 12, 2007 at 07:16:45PM +0200, Jürgen Spitzmüller wrote:
José Matos wrote:
I saw the patch and I agree with the way it is done. This time though I
will be on the safe side (read chicken) and I would suggest to delay this
for 1.5.1. OK?
I was about to say the same. The patch
Enrico Forestieri wrote:
No problem with me. Anyway, I already tested it on three different
systems, so I am confident that it works ;-)
We'll release 1.5.1 soon :-)
Jürgen
Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
>
> Yes, this is r18988 striking again :(
>
> I don't think that this is related to the platform but rather to the
> compiler version. I think that gcc 3.x is missing some locale facets.
>
> Jean-Pierre, does the attached patch solve the bug for
> "Pavel" == Pavel Sanda <[EMAIL PROTECTED]> writes:
>> Anyway, after r18988 LyX is not so much forgiving about wrong
>> locales. On Linux, try for example:
>>
>> $ env LC_ALL=foo ./src/lyx-qt4
>>
>> and you will get that exception, too.
Pavel> Ouch. What if we instead of using multiple
On Wednesday 11 July 2007 20:36:25 Enrico Forestieri wrote:
>
> Yes, this is r18988 striking again :(
>
> I don't think that this is related to the platform but rather to the
> compiler version. I think that gcc 3.x is missing some locale facets.
>
> Jean-Pierre, does the attached patch solve the
On Thu, Jul 12, 2007 at 10:05:09AM +0100, José Matos wrote:
> On Wednesday 11 July 2007 20:36:25 Enrico Forestieri wrote:
> >
> > Yes, this is r18988 striking again :(
> >
> > I don't think that this is related to the platform but rather to the
> > compiler version. I think that gcc 3.x is missing
On Thu, Jul 12, 2007 at 09:26:55AM +0200, Jean-Marc Lasgouttes wrote:
> > "Pavel" == Pavel Sanda <[EMAIL PROTECTED]> writes:
>
> >> Anyway, after r18988 LyX is not so much forgiving about wrong
> >> locales. On Linux, try for example:
> >>
> >> $ env LC_ALL=foo ./src/lyx-qt4
> >>
> >> and
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
> This one would also catch MSVC, which AFAIK has no problem with
> the locale sorting.
OK. You can commit the change.
> --
> Enrico
--
José Abílio
On Thu, Jul 12, 2007 at 10:53:54AM +0100, José Matos wrote:
> On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
> > This one would also catch MSVC, which AFAIK has no problem with
> > the locale sorting.
>
> OK. You can commit the change.
I did it.
--
Enrico
> On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
> > This one would also catch MSVC, which AFAIK has no problem with
> > the locale sorting.
>
> OK. You can commit the change.
even if this change helps for solaris i fear many crashes on systems
with strangely set locales. the
Pavel Sanda wrote:
> even if this change helps for solaris i fear many crashes on systems
> with strangely set locales. the changeset should be reverted back until
> we know how safely detect the error.
FWIW, I agree.
Jürgen
Pavel Sanda wrote:
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote:
This one would also catch MSVC, which AFAIK has no problem with
the locale sorting.
OK. You can commit the change.
even if this change helps for solaris i fear many crashes on systems
with strangely set locales.
> What do you mean by handling the exception? Fallback to the non wchar_t
yes
> solution if an exception is caught? For this to work the choice of
> using wchar_t or not must be done at run-time; unfortunately the source
> code is really not ready to do that now (lots of #ifdef).
wont be
On Thu, Jul 12, 2007 at 12:54:39PM +0200, Pavel Sanda wrote:
> wont be possible to avoid any ifdefs by doing something like :
>
> try
> locale stuff (init+sort);
> catch any_error: do non_locale stuff
Note that this is used in a sorting context, so the comparison
should be as fast as possible.
> Note that this is used in a sorting context, so the comparison
> should be as fast as possible. I don't think that the try/catch
we are sorting some ~50 items. anyway it can be written that
try block is entered only once per one sorting.
pavel
Pavel Sanda wrote:
> even if this change helps for solaris i fear many crashes on systems
> with strangely set locales.
I even get the crash by
- LANG=en_EN lyx
- Tools->Preferences
Jürgen
Jürgen Spitzmüller wrote:
> > even if this change helps for solaris i fear many crashes on systems
> > with strangely set locales.
>
> I even get the crash by
> - LANG=en_EN lyx
> - Tools->Preferences
For 1.5.0, I propose the attached.
Jürgen
Index: src/frontends/controllers/frontend_helpers.cpp
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
even if this change helps for solaris i fear many crashes on systems
with strangely set locales.
I even get the crash by
- LANG=en_EN lyx
- Tools->Preferences
For 1.5.0, I propose the attached.
+1.
By the way, I just had a look at bug
On Thursday 12 July 2007 16:51:55 Jürgen Spitzmüller wrote:
> For 1.5.0, I propose the attached.
>
> Jürgen
OK then. Enrico earlier agreed with this and then we will have more time to
fix this properly.
--
José Abílio
On Thu, Jul 12, 2007 at 05:18:04PM +0100, José Matos wrote:
> On Thursday 12 July 2007 16:51:55 Jürgen Spitzmüller wrote:
> > For 1.5.0, I propose the attached.
> >
> > Jürgen
>
> OK then. Enrico earlier agreed with this and then we will have more time to
> fix this properly.
Please, wait a
José Matos wrote:
> OK then. Enrico earlier agreed with this and then we will have more time to
> fix this properly.
Done. I've also reopened the bug report with a comment.
Jürgen
Enrico Forestieri wrote:
> Please, wait a minute. I have another option.
too late.
Jürgen
On Thursday 12 July 2007 17:26:54 Enrico Forestieri wrote:
> I have another option.
Tell us more. :-)
> --
> Enrico
--
José Abílio
On Thu, Jul 12, 2007 at 06:32:28PM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > Please, wait a minute. I have another option.
>
> too late.
No problem. The attached patch should solve the problems related
to sorting according to the locale rules. I think that there is
no other
On Thu, Jul 12, 2007 at 05:36:03PM +0100, José Matos wrote:
> On Thursday 12 July 2007 17:26:54 Enrico Forestieri wrote:
> > I have another option.
>
> Tell us more. :-)
The exception is thrown by the locale constructor, not when the
ordering is performed. So, we catch it there and then either
On Thursday 12 July 2007 18:06:42 Enrico Forestieri wrote:
> The exception is thrown by the locale constructor, not when the
> ordering is performed. So, we catch it there and then either
> use the locale facilities or the normal ordering. See patch
> in the other post.
I saw the patch and I
José Matos wrote:
> I saw the patch and I agree with the way it is done. This time though I
> will be on the safe side (read chicken) and I would suggest to delay this
> for 1.5.1. OK?
I was about to say the same. The patch looks correct, but the bug is not too
crucial to get it in urgently.
On Thu, Jul 12, 2007 at 07:16:45PM +0200, Jürgen Spitzmüller wrote:
> José Matos wrote:
> > I saw the patch and I agree with the way it is done. This time though I
> > will be on the safe side (read chicken) and I would suggest to delay this
> > for 1.5.1. OK?
>
> I was about to say the same. The
Enrico Forestieri wrote:
> No problem with me. Anyway, I already tested it on three different
> systems, so I am confident that it works ;-)
We'll release 1.5.1 soon :-)
Jürgen
Hello,
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught normal exception: locale::facet::_S_create_c_locale name not valid
Program received signal SIGABRT, Aborted.
0xfdf592f0 in __sigprocmask ()
Jean-Pierre Chrétien wrote:
Hello,
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught normal exception: locale::facet::_S_create_c_locale name not valid
Program received signal SIGABRT, Aborted.
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught normal exception: locale::facet::_S_create_c_locale name not valid
could not be this somehow related to
Abdelrazak Younes [EMAIL PROTECTED] writes:
This backtrace seems minimal, should I recompile with --enable-debug ?
Yes, and possibly --enable-stdlib-debug if that is not already set by
default.
Same result
--
Jean-Pierre
On Wed, Jul 11, 2007 at 03:59:51PM +0200, Pavel Sanda wrote:
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught normal exception: locale::facet::_S_create_c_locale name not valid
could not
Anyway, after r18988 LyX is not so much forgiving about wrong locales.
On Linux, try for example:
$ env LC_ALL=foo ./src/lyx-qt4
and you will get that exception, too.
Ouch. What if we instead of using multiple #ifs catch the exception
and decide what kind sorter would be used ?
pavel
Hello,
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught "normal" exception: locale::facet::_S_create_c_locale name not valid
Program received signal SIGABRT, Aborted.
0xfdf592f0 in __sigprocmask ()
Jean-Pierre Chrétien wrote:
Hello,
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught "normal" exception: locale::facet::_S_create_c_locale name not valid
Program received signal SIGABRT, Aborted.
> All is OK with 1.5.0rc2, but with 1.5.0-svn,
> when I want to edit the settings of a template document
> on Solaris 2.8/Qt4.3.1, I get this:
>
> Caught "normal" exception: locale::facet::_S_create_c_locale name not valid
could not be this somehow related to
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> > This backtrace seems minimal, should I recompile with --enable-debug ?
>
> Yes, and possibly --enable-stdlib-debug if that is not already set by
> default.
Same result
--
Jean-Pierre
On Wed, Jul 11, 2007 at 03:59:51PM +0200, Pavel Sanda wrote:
> > All is OK with 1.5.0rc2, but with 1.5.0-svn,
> > when I want to edit the settings of a template document
> > on Solaris 2.8/Qt4.3.1, I get this:
> >
> > Caught "normal" exception: locale::facet::_S_create_c_locale name not valid
>
> Anyway, after r18988 LyX is not so much forgiving about wrong locales.
> On Linux, try for example:
>
> $ env LC_ALL=foo ./src/lyx-qt4
>
> and you will get that exception, too.
Ouch. What if we instead of using multiple #ifs catch the exception
and decide what kind sorter would be used ?
80 matches
Mail list logo
