Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: Koji == Koji Yokota [EMAIL PROTECTED] writes: Koji Then, is a sort of modification as the attached patch Koji acceptable? It seems it solved the problem and is working fine! This particular patch does not look good, but we'll find one around this idea.

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes: Koji> Then, is a sort of modification as the attached patch Koji> acceptable? It seems it solved the problem and is working fine! This particular patch does not look good, but we'll find one around this

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: What a shame. This problem is known since 2003, and still not fixed? Does nobody care for such a standard violation? It seems the fact that FreeBSD had an old implementation of a wchar_t equivalence before wchar_t was introduced made the problem complicated. I wish it is

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji == Koji Yokota [EMAIL PROTECTED] writes: Koji Then, is a sort of modification as the attached patch Koji acceptable? It seems it solved the problem and is working fine! This particular patch does not look good, but we'll find one around this idea. Isn't there some define that we can test

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: What a shame. This problem is known since 2003, and still not fixed? Does nobody care for such a standard violation? It seems the fact that FreeBSD had an old implementation of a wchar_t equivalence before wchar_t was introduced made the problem complicated. I wish it is

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes: Koji> Then, is a sort of modification as the attached patch Koji> acceptable? It seems it solved the problem and is working fine! This particular patch does not look good, but we'll find one around this idea. Isn't there some define that we

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Koji Yokota wrote: Georg Baum wrote: If you want to debug this fdurther it might be a good idea to write a small standalone program that simply calls boost::format with the problematic input. boost::basic_format() itself seems working if it is called with ordinary strings:

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: No, it doesn't compile. It complains that there is no matching function, which probablly means that in boost/boost/format/format_fwd.hpp: #if !defined(BOOST_NO_STD_WSTRING) !defined(BOOST_NO_STD_WSTREAMBUF) \ !defined(BOOST_FORMAT_IGNORE_STRINGSTREAM) typedef

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Am Dienstag, 12. Juni 2007 19:05 schrieb Koji Yokota: There seems to be a problem in libstdc++ for FreeBSD to handle wchar_t, which may still exist(?) as shown here: This did never occur as an option to me. Good detective work!

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Koji Yokota wrote: Georg Baum wrote: If you want to debug this fdurther it might be a good idea to write a small standalone program that simply calls boost::format with the problematic input. boost::basic_format() itself seems working if it is called with "ordinary"

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: No, it doesn't compile. It complains that there is no matching function, which probablly means that in boost/boost/format/format_fwd.hpp: #if !defined(BOOST_NO_STD_WSTRING) && !defined(BOOST_NO_STD_WSTREAMBUF) \ && !defined(BOOST_FORMAT_IGNORE_STRINGSTREAM)

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Am Dienstag, 12. Juni 2007 19:05 schrieb Koji Yokota: > There seems to be a problem in libstdc++ for FreeBSD to handle wchar_t, > which may still exist(?) as shown here: This did never occur as an option to me. Good detective work! >

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: Georg Baum wrote: If you want to debug this fdurther it might be a good idea to write a small standalone program that simply calls boost::format with the problematic input. boost::basic_format() itself seems working if it is called with ordinary strings: #include

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: So, this may have to be modified too. (gdb) p *start $38 = (const wchar_t ) @0x8b1e9c0: 49 (gdb) x/5s 0x8b1e9c0 0x8b1e9c0: 1 0x8b1e9c2: 0x8b1e9c3: 0x8b1e9c4: $ 0x8b1e9c6: 0x8b1e9c7: 0x8b1e9c8: s 0x8b1e9ca: 0x8b1e9cb:

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: > Georg Baum wrote: >> If you want to debug this fdurther it might be a good idea to write a >> small standalone program that simply calls boost::format with the >> problematic input. > > boost::basic_format() itself seems working if it is called with > "ordinary" strings: >

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: > So, this may have to be modified too. > >> > (gdb) p *start >> > $38 = (const wchar_t &) @0x8b1e9c0: 49 > > > (gdb) x/5s 0x8b1e9c0 > > 0x8b1e9c0: "1" > > 0x8b1e9c2: "" > > 0x8b1e9c3: "" > > 0x8b1e9c4: "$" > > 0x8b1e9c6: "" > > 0x8b1e9c7: "" > > 0x8b1e9c8:

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

I'm not quite sure about the data structure used here, but arguments fmt and arg1 in bformat() seem to contain no data fields: Oh, I should assume fmt and arg1 contain pointers. Sorry. (gdb) p fmt $44 = (const docstring *) 0xbfbfe588 (gdb) p arg1 $46 = (docstring *) 0xbfbfe580 (gdb) x/s

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Also, template class Ch, class Tr, class Alloc basic_formatCh, Tr, Alloc:: basic_format(const string_type s) : style_(0), cur_arg_(0), num_args_(0), dumped_(false), exceptions_(io::all_error_bits) { parse(s); } it contains: (gdb) p s $47 = (

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

So, this may have to be modified too. (gdb) p *start $38 = (const wchar_t ) @0x8b1e9c0: 49 (gdb) x/5s 0x8b1e9c0 0x8b1e9c0: 1 0x8b1e9c2: 0x8b1e9c3: 0x8b1e9c4: $ 0x8b1e9c6: 0x8b1e9c7: 0x8b1e9c8: s 0x8b1e9ca: 0x8b1e9cb: 0x8b1e9cc: \r0 0x8b1e9cf: 0x8b1e9d0:

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> I'm not quite sure about the data structure used here, but arguments fmt > and arg1 in bformat() seem to contain no data fields: Oh, I should assume and contain pointers. Sorry. > (gdb) p > $44 = (const docstring *) 0xbfbfe588 > (gdb) p > $46 = (docstring *) 0xbfbfe580 > (gdb) x/s

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Also, template< class Ch, class Tr, class Alloc> basic_format:: basic_format(const string_type& s) : style_(0), cur_arg_(0), num_args_(0), dumped_(false), exceptions_(io::all_error_bits) { parse(s); } it contains: > (gdb) p > $47 = (

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

So, this may have to be modified too. > (gdb) p *start > $38 = (const wchar_t &) @0x8b1e9c0: 49 > (gdb) x/5s 0x8b1e9c0 > 0x8b1e9c0: "1" > 0x8b1e9c2: "" > 0x8b1e9c3: "" > 0x8b1e9c4: "$" > 0x8b1e9c6: "" > 0x8b1e9c7: "" > 0x8b1e9c8: "s" > 0x8b1e9ca: "" > 0x8b1e9cb: "" > 0x8b1e9cc:

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: If you want to debug this fdurther it might be a good idea to write a small standalone program that simply calls boost::format with the problematic input. boost::basic_format() itself seems working if it is called with ordinary strings: #include iostream #include

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: If you want to debug this fdurther it might be a good idea to write a small standalone program that simply calls boost::format with the problematic input. boost::basic_format() itself seems working if it is called with "ordinary" strings: > #include > #include > > using

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: Georg Baum wrote: Then Koji could fire up a debugger, set a breakpoint in parse_printf_directive() and report what the result of the narrow() call is. Do you mean the return value of wrap_narrow() call? If so, the result of gdb was: Yes, I meant that. $1 = -65

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: > Georg Baum wrote: >> Then Koji could fire up a debugger, set a breakpoint in >> parse_printf_directive() and report what the result of the narrow() call >> is. > > Do you mean the return value of wrap_narrow() call? If so, the result of > gdb was: Yes, I meant that. > >

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Then Koji could fire up a debugger, set a breakpoint in parse_printf_directive() and report what the result of the narrow() call is. Do you mean the return value of wrap_narrow() call? If so, the result of gdb was: $1 = -65 '\277' It appeared twice in

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Then Koji could fire up a debugger, set a breakpoint in parse_printf_directive() and report what the result of the narrow() call is. Do you mean the return value of wrap_narrow() call? If so, the result of gdb was: > $1 = -65 '\277' It appeared twice in

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Jean-Marc Lasgouttes wrote: - how can we test whether freebsd's wchat_t support is good enough? First of all is wchar_t really 32 bit on freebsd? I know that some unices have 16bit wchar_t, IIRC AIX. This could be tested with a small test program that simply prints

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Am Dienstag, 5. Juni 2007 19:11 schrieb Koji Yokota: Georg Baum wrote: Jean-Marc Lasgouttes wrote: - how can we test whether freebsd's wchat_t support is good enough? First of all is wchar_t really 32 bit on freebsd? I know that some unices have 16bit wchar_t, IIRC AIX. This could be

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Jean-Marc Lasgouttes wrote: - how can we test whether freebsd's wchat_t support is good enough? First of all is wchar_t really 32 bit on freebsd? I know that some unices have 16bit wchar_t, IIRC AIX. This could be tested with a small test program that simply prints

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Am Dienstag, 5. Juni 2007 19:11 schrieb Koji Yokota: > Georg Baum wrote: > > Jean-Marc Lasgouttes wrote: > >> - how can we test whether freebsd's wchat_t support is good enough? > > First of all is wchar_t really 32 bit on freebsd? I know that some unices > > have 16bit wchar_t, IIRC AIX. This

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Tue, May 29, 2007 at 11:20:45AM +0900, Koji Yokota wrote: Enrico Forestieri wrote: I don't understand. Seems that you are still using wchar_t ... This crash is very similar to the one I was getting on cygwin after the switch to unicode. I remember that someway I was able to fix it by

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: - do you know of any problem related to boost::format and wchat_t? No. I remember some problems, but they were eventually solved, I believe by switching from boost::uint32_t to wchar_t. - how can we test whether freebsd's wchat_t support is good enough? First of

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Tue, May 29, 2007 at 11:20:45AM +0900, Koji Yokota wrote: > Enrico Forestieri wrote: > > I don't understand. Seems that you are still using wchar_t ... > > This crash is very similar to the one I was getting on cygwin after the > > switch to unicode. I remember that someway I was able to fix it

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: > - do you know of any problem related to boost::format and wchat_t? No. I remember some problems, but they were eventually solved, I believe by switching from boost::uint32_t to wchar_t. > - how can we test whether freebsd's wchat_t support is good enough? First of

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Mon, May 28, 2007 at 10:20:57AM +0900, Koji Yokota wrote: Peter Kümmel wrote: Hasn't Abdel fixed it today? Maybe updating helps. Yeah, right. With a newer version, Lyx at least proceeds with a successful initialization and its GUI appears. However, trial of File - New, File - Open,

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Enrico Forestieri wrote: I don't understand. Seems that you are still using wchar_t ... This crash is very similar to the one I was getting on cygwin after the switch to unicode. I remember that someway I was able to fix it by using the STLport library, before the real fix by Georg. Have a look

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Mon, May 28, 2007 at 10:20:57AM +0900, Koji Yokota wrote: > Peter Kümmel wrote: > > Hasn't Abdel fixed it today? Maybe updating helps. > > Yeah, right. With a newer version, Lyx at least proceeds with a > successful initialization and its GUI appears. However, trial of File -> > New, File

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Enrico Forestieri wrote: I don't understand. Seems that you are still using wchar_t ... This crash is very similar to the one I was getting on cygwin after the switch to unicode. I remember that someway I was able to fix it by using the STLport library, before the real fix by Georg. Have a look

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Maybe Koji could try to enable that unconditionally: Abdelrazak - #if SIZEOF_WCHAR_T != 4 defined(__GNUC__) Abdelrazak defined(__GNUC_MINOR__) __GNUC__ == 3 __GNUC_MINOR__ Abdelrazak 4 + #if

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Maybe Koji could try to enable that unconditionally: Abdelrazak - #if SIZEOF_WCHAR_T != 4 defined(__GNUC__) Abdelrazak defined(__GNUC_MINOR__) __GNUC__ == 3 __GNUC_MINOR__

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel wrote: Hasn't Abdel fixed it today? Maybe updating helps. Yeah, right. With a newer version, Lyx at least proceeds with a successful initialization and its GUI appears. However, trial of File - New, File - Open, or start of lyx with a parameter like 'lyx -dbg any' leads to the

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Maybe Koji could try to enable that unconditionally: Abdelrazak> - #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) && Abdelrazak> defined(__GNUC_MINOR__) && __GNUC__ == 3 && __GNUC_MINOR__

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: > Jean-Marc Lasgouttes wrote: >>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> >> Abdelrazak> Maybe Koji could try to enable that unconditionally: >> >> Abdelrazak> - #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) && >> Abdelrazak> defined(__GNUC_MINOR__)

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel wrote: Hasn't Abdel fixed it today? Maybe updating helps. Yeah, right. With a newer version, Lyx at least proceeds with a successful initialization and its GUI appears. However, trial of File -> New, File -> Open, or start of lyx with a parameter like 'lyx -dbg any' leads to

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter We could just wait for 1.34.1, upgrading to 1.34 is nearly a Peter noop: Peter http://www.lyx.org/trac/changeset/18458 I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is released. JMarc

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel wrote: Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter We could just wait for 1.34.1, upgrading to 1.34 is nearly a Peter noop: Peter http://www.lyx.org/trac/changeset/18458 I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter Done, all files (also filesystem) are now from 1.34. Thanks. JMarc

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: >> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: > > Peter> We could just wait for 1.34.1, upgrading to 1.34 is nearly a > Peter> noop: > > Peter> http://www.lyx.org/trac/changeset/18458 > > I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel wrote: > Jean-Marc Lasgouttes wrote: >>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: >> Peter> We could just wait for 1.34.1, upgrading to 1.34 is nearly a >> Peter> noop: >> >> Peter> http://www.lyx.org/trac/changeset/18458 >> >> I'd suggest to upgrade to 1.34 now, and

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> Done, all files (also filesystem) are now from 1.34. Thanks. JMarc

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Maybe Koji could try to enable that unconditionally: Abdelrazak - #if SIZEOF_WCHAR_T != 4 defined(__GNUC__) Abdelrazak defined(__GNUC_MINOR__) __GNUC__ == 3 __GNUC_MINOR__ Abdelrazak 4 + #if 1 Koji, could you try that?

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Thu, May 24, 2007 at 02:15:35PM +0200, Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Maybe Koji could try to enable that unconditionally: Abdelrazak - #if SIZEOF_WCHAR_T != 4 defined(__GNUC__) Abdelrazak defined(__GNUC_MINOR__)

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: Jean-Marc Lasgouttes wrote: It was Georg who wrote Note that the iostreams library in boost 1.34.0 is an outdated version (older than the version in boost 1.33.1) with a memory leak, so watch for iostreams updates in the boost 1.34 branch, too. I am afraid I do

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter We could just wait for 1.34.1, upgrading to 1.34 is nearly a Peter noop: Peter http://www.lyx.org/trac/changeset/18458 I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is released. JMarc

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Maybe Koji could try to enable that unconditionally: Abdelrazak> - #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) && Abdelrazak> defined(__GNUC_MINOR__) && __GNUC__ == 3 && __GNUC_MINOR__ Abdelrazak> < 4 + #if 1 Koji,

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Thu, May 24, 2007 at 02:15:35PM +0200, Jean-Marc Lasgouttes wrote: > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Abdelrazak> Maybe Koji could try to enable that unconditionally: > > Abdelrazak> - #if SIZEOF_WCHAR_T != 4 && defined(__GNUC__) && > Abdelrazak>

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Georg Baum wrote: > Jean-Marc Lasgouttes wrote: > >> It was Georg who wrote >> >> Note that the iostreams library in boost 1.34.0 is an outdated >> version (older than the version in boost 1.33.1) with a memory leak, >> so watch for iostreams updates in the boost 1.34 branch, too. >> >> I

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> We could just wait for 1.34.1, upgrading to 1.34 is nearly a Peter> noop: Peter> http://www.lyx.org/trac/changeset/18458 I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is released. JMarc

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes schrieb: Peter After the release of 1.5, I assume. Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. +1 Michael

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter I've updated to boost 1.34 in a branch, and it's not that hard, Peter it compiles and runs without problems. The changes are: Very good, thanks. Peter Should I update the header files? JMarc says in bugzilla that Peter we should not update

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: It was Georg who wrote Note that the iostreams library in boost 1.34.0 is an outdated version (older than the version in boost 1.33.1) with a memory leak, so watch for iostreams updates in the boost 1.34 branch, too. I am afraid I do not know what he

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji == Koji Yokota [EMAIL PROTECTED] writes: Koji I attach the backtrace when the program is crashed as additional Koji information. Looking at the backtrace, the problem happens at line 333 of boost/format/parsing.hpp: switch ( wrap_narrow(fac, *start, 0) ) { case 'X':

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Wed, May 23, 2007 at 03:40:08PM +0200, Jean-Marc Lasgouttes wrote: This seems to point to a problem with using widen/narrow on a facet like std::ctypewchar_t. Of course, I know next to nothing about that. Enrico, would you have some ideas about whether freebsd has the needed support? I

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico When sizeof(wchar_t) != 4 or wchar_t is not present, then our Enrico facets implementation should kick in. I use it with no Enrico problems in both cygwin and mingw, don't know about other Enrico platforms. Do you have a simple

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico When sizeof(wchar_t) != 4 or wchar_t is not present, then our Enrico facets implementation should kick in. I use it with no Enrico problems in both cygwin and mingw, don't know about other Enrico

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Wed, May 23, 2007 at 05:20:52PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico When sizeof(wchar_t) != 4 or wchar_t is not present, then our Enrico facets implementation should kick in. I use it with no Enrico problems in both cygwin and

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes schrieb: Peter> After the release of 1.5, I assume. Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. +1 Michael

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: Peter> I've updated to boost 1.34 in a branch, and it's not that hard, Peter> it compiles and runs without problems. The changes are: Very good, thanks. Peter> Should I update the header files? JMarc says in bugzilla that Peter> we

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: > It was Georg who wrote > > Note that the iostreams library in boost 1.34.0 is an outdated > version (older than the version in boost 1.33.1) with a memory leak, > so watch for iostreams updates in the boost 1.34 branch, too. > > I am afraid I do not know what

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes: Koji> I attach the backtrace when the program is crashed as additional Koji> information. Looking at the backtrace, the problem happens at line 333 of boost/format/parsing.hpp: switch ( wrap_narrow(fac, *start, 0) ) { case

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Wed, May 23, 2007 at 03:40:08PM +0200, Jean-Marc Lasgouttes wrote: > This seems to point to a problem with using widen/narrow on a facet > like std::ctype. Of course, I know next to nothing about that. > Enrico, would you have some ideas about whether freebsd has the needed > support? I

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> When sizeof(wchar_t) != 4 or wchar_t is not present, then our Enrico> facets implementation should kick in. I use it with no Enrico> problems in both cygwin and mingw, don't know about other Enrico> platforms. Do you have a

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> When sizeof(wchar_t) != 4 or wchar_t is not present, then our Enrico> facets implementation should kick in. I use it with no Enrico> problems in both cygwin and mingw, don't know about other Enrico>

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Wed, May 23, 2007 at 05:20:52PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> When sizeof(wchar_t) != 4 or wchar_t is not present, then our > Enrico> facets implementation should kick in. I use it with no > Enrico> problems in

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter == Peter Kümmel [EMAIL PROTECTED] writes: We should probably update boost first to 1.34 final, but I do not know who wants to do it. Peter After the release of 1.5, I assume. Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. JMarc

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Tuesday 22 May 2007 8:52:30 am Jean-Marc Lasgouttes wrote: Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. I tend to agree with Jean-Marc here. JMarc -- José Abílio

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

José Matos wrote: On Tuesday 22 May 2007 8:52:30 am Jean-Marc Lasgouttes wrote: Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. I tend to agree with Jean-Marc here. Me too. Abdel.

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Abdelrazak Younes wrote: José Matos wrote: On Tuesday 22 May 2007 8:52:30 am Jean-Marc Lasgouttes wrote: Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. I tend to agree with Jean-Marc here. Me too. Abdel. I've updated to boost 1.34 in a

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes: >> We should probably update boost first to 1.34 final, but I do not >> know who wants to do it. Peter> After the release of 1.5, I assume. Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. JMarc

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Tuesday 22 May 2007 8:52:30 am Jean-Marc Lasgouttes wrote: > Are we sure? The 1.5 branch would be better with the real 1.34, rather > than a prerelease. I tend to agree with Jean-Marc here. > JMarc -- José Abílio

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

José Matos wrote: On Tuesday 22 May 2007 8:52:30 am Jean-Marc Lasgouttes wrote: Are we sure? The 1.5 branch would be better with the real 1.34, rather than a prerelease. I tend to agree with Jean-Marc here. Me too. Abdel.

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Abdelrazak Younes wrote: > José Matos wrote: >> On Tuesday 22 May 2007 8:52:30 am Jean-Marc Lasgouttes wrote: >>> Are we sure? The 1.5 branch would be better with the real 1.34, rather >>> than a prerelease. >> >> I tend to agree with Jean-Marc here. > > Me too. > > Abdel. > I've updated to

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel [EMAIL PROTECTED] writes: But we could disable boost format, so please try attached patch. Peter, with this patch, it seems the problem has resolved. lyx successfully finishes the initialization and starts up. Great. Hope you get not other problems because of iconv. We

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus could you go the extra mile and ascertain exactly what boost Angus dislikes here and then work with the boost team to fix their Angus code. We make great use of boost and should feel honour bound Angus to help squash those bugs we find. We

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: PS: Feel like coming to Finland in August? Not really. Finland in August is much like Scotland in August; full of nasty, biting insects! Angus (ducking from the wrath of M.V. ;-))

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: PS: Feel like coming to Finland in August? Angus Not really. Finland in August is much like Scotland in August; Angus full of nasty, biting insects! You have a point there. And don't forget

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

On Mon, May 21, 2007 at 09:32:22PM +, Angus Leeming wrote: Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: PS: Feel like coming to Finland in August? Not really. Finland in August is much like Scotland in August; full of nasty, biting insects! Angus (ducking from the wrath of M.V.

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus could you go the extra mile and ascertain exactly what boost Angus dislikes here and then work with the boost team to fix their Angus code. We make great use of boost and should feel honour bound Angus to

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel <[EMAIL PROTECTED]> writes: > >> But we could disable boost format, so please try attached patch. > > Peter, with this patch, it seems the problem has resolved. lyx > > successfully finishes the initialization and starts up. > Great. > Hope you get not other problems because of

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> could you go the extra mile and ascertain exactly what boost Angus> dislikes here and then work with the boost team to fix their Angus> code. We make great use of boost and should feel honour bound Angus> to help squash those bugs

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > PS: Feel like coming to Finland in August? Not really. Finland in August is much like Scotland in August; full of nasty, biting insects! Angus (ducking from the wrath of M.V. ;-))

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> PS: Feel like coming to Finland in August? Angus> Not really. Finland in August is much like Scotland in August; Angus> full of nasty, biting insects! You have a point there.

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

On Mon, May 21, 2007 at 09:32:22PM +, Angus Leeming wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > PS: Feel like coming to Finland in August? > > Not really. Finland in August is much like Scotland in August; full of nasty, > biting insects! > > Angus (ducking from the wrath

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> could you go the extra mile and ascertain exactly what boost > Angus> dislikes here and then work with the boost team to fix their > Angus> code. We make great use of boost and should feel honour

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel wrote: lyxerr LyX: Creating directory %1$s endl, lyxerr package().user_support().absFilename() endl; docstring s1 = _(LyX: Creating directory %1$s); docstring s2 = from_utf8(package().user_support().absFilename()); //docstring s3 = bformat(_(LyX

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

We still don't know which string is wrong so here the next code: docstring format = _(LyX directory, %1$s. \n); lyxerr format = to_utf8(format) endl; docstring path = from_utf8(/home/dir/); lyxerr path = to_utf8(path) endl; docstring s4=

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Peter Kümmel wrote: We still don't know which string is wrong so here the next code: docstring format = _(LyX directory, %1$s. \n); lyxerr format = to_utf8(format) endl; docstring path = from_utf8(/home/dir/); lyxerr path = to_utf8(path) endl;

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

Koji Yokota wrote: Peter Kümmel wrote: We still don't know which string is wrong so here the next code: docstring format = _(LyX directory, %1$s. \n); lyxerr format = to_utf8(format) endl; docstring path = from_utf8(/home/dir/); lyxerr path = to_utf8(path) endl;

  1   2   3   >