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
> "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
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 so
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!
> http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#
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
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:
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
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:
>
>
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: "\r
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 &s
> $47 = (
> const
> 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
>
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 n
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
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 boost/boost/format/
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 cou
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 sizeof(wcha
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
> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes:
Koji> 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
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
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
a
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 ->
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
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__) &&
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__
Abdelr
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Done, all files (also filesystem) are now from 1.34.
Thanks.
JMarc
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 con
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
> "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
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
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(
> "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,
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 b
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> pl
> "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 s
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 reall
> "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 '
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
> "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
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
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 b
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.
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
> "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
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 bou
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 o
> "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
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. ;-))
> "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 w
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
Peter Kümmel wrote:
Have fun!
Do you know that beta3 is out?
Yes, now I'm going to try it.
Hope you get not other problems because of iconv.
I will report if there is any.
Thanks,
Koji
Koji Yokota wrote:
> Peter Kümmel wrote:
>> bformat is just a call to boost:
>>
>> boost::basic_format(fmt) % arg1).str();
>>
>> So it is a boost bug when checking the format string,
>> or our string is somehow invalid. This does not help much.
>>
>> But we could disable boost format, so please try
Peter Kümmel wrote:
bformat is just a call to boost:
boost::basic_format(fmt) % arg1).str();
So it is a boost bug when checking the format string,
or our string is somehow invalid. This does not help much.
But we could disable boost format, so please try attached patch.
Peter, with this pat
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 << "p
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)
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;
docs
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 = bfo
there is no bformat which takes a char*:
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());
横田 宏治 wrote:
> As I think I'd better continue to throw additional informations on this
> problem, I'll do so gradually.
>
Yes this is a good idea.
First we must locate the reason for the crash.
Is it the format string or the path string. And crashes it really
because of iconv or has it nothing t
As I think I'd better continue to throw additional informations on this
problem, I'll do so gradually.
Before the call of from_utf8 in lyx_main.C:
> lyxerr << to_utf8(bformat(_("LyX: Creating directory %1$s"),
> from_utf8(package().user_support().absFilename(
><< endl;
Peter Kümmel wrote:
Could you have a look at the sting passes to boost::basic_format?
support/lstrings.C line 875
OK, it's as follows:
> (gdb) p fmt
> $18 = (const docstring &) @0xbfbfe5a8: {static npos = 4294967295,
> _M_dataplus = {> =
> {<__gnu_cxx::new_allocator> = {}, fields>}, _M_p =
Koji Yokota wrote:
> I attach the backtrace when the program is crashed as additional
> information.
>
> Koji
>
> ---
> Program received signal SIGABRT, Aborted.
> 0x2958a897 in kill () from /lib/libc.so.6
> (gdb) bt
> #0 0x2958a897 in kill () from /lib/libc.so.6
> #1 0x2949d4f7 in raise ()
ps.
The last call of processor.convert() is called by getEnv("LC_ALL") in
function Messages::get() in messages.C when it handles strings "LyX:
Creating directory %1$s".
Koji Yokota wrote:
When it is called just before crash:
(1) Before
(gdb) p inbuf:$29 = 0x87f22ec "C"
(gdb)
I attach the backtrace when the program is crashed as additional
information.
Koji
---
Program received signal SIGABRT, Aborted.
0x2958a897 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x2958a897 in kill () from /lib/libc.so.6
#1 0x2949d4f7 in raise () from /lib/libpthread.so.2
#2 0x295892fb
Jean-Marc Lasgouttes wrote:
What is the value of "out"? This is the important one.
Uh, is this mean encodings of output? If it is, it's "UCS-4LE".
Koji
Jean-Marc Lasgouttes wrote:
Koji, I am slowly looking at this again. It is normal that the value
of outbuf is changed by iconv, since it is incremented to point to the
end of the converted string.
I see.
I am not sure. What are the values of the variables before and after
the call
in
> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes:
Koji> Can the attached unicode.C.patch be a solution? With the patch,
Koji> I can compile lyx (but I got a crash in another place, sigh...).
I am not sure. What are the values of the variables before and after
the call
int bytes = pr
>> I think the 'in' and 'out' are iso8859-1 because the passed strings
>> are a directory name. When iconv is called in unicode.C:
>>int res = iconv(pimpl_->cd, &inbuf, &inbytesleft, &outbuf,
>> &outbytesleft);
>> output of gdb before call is:
>> inbuf : $3 = 0x8a79d0c "/home/hge/.lyx-devel
> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes:
Koji> Hi, I'm investigating in this problem and it seems the address
Koji> of outbuf changes before and after of the call of
Koji> iconv((pimpl_->cd, &inbuf, &inbytesleft, &outbuf,
Koji> &outbytesleft);
Koji, I am slowly looking at this aga
> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes:
Koji> Jean-Marc Lasgouttes wrote:
>> What architecture is it?
Koji> Sorry, architecture is all i386 (one is amd64 running in i386
Koji> mode).
So it is not a problem of endianness.
JMarc
Jean-Marc Lasgouttes wrote:
What architecture is it?
Sorry, architecture is all i386 (one is amd64 running in i386 mode).
Koji
Jean-Marc Lasgouttes wrote:
Does the behaviour depend from current locale settings?
No, it doesn't seem so. The same thing happens under LC_ALL=C.
What architecture is it?
All are FreeBSD-6.2-RELEASE with current ports programs.
Can you reproduce it with a minimal C(++) file?
Yeah, I tr
> "Koji" == Koji Yokota <[EMAIL PROTECTED]> writes:
Koji> I confirmed the same bug arises in at least three freebsd boxes
Koji> (all stable release version).
Does the behaviour depend from current locale settings?
What architecture is it?
Can you reproduce it with a minimal C(++) file?
JMa
Correction. iconv conversion is from UTF-8 to UCS4-LE.
1) Initially, IconvProcessor::init() is called from
IconvProcessor::convert().
2) Then, since pimpl_->cd = invalid_cd, iconv_open() is called.
3) arguments of iconv_open(tocode_.c_str(),fromcode_.c_str()) is:
tocode_.c_str()
Jean and Abdel,
libiconv is compiled from the "port" package management and its version
is 1.9.2, so I can say that the problem occurs under a fairly standard
setting of FreeBSD (6.2-(stable)release with updated ports). It is
installed under /usr/local/ because, in FreeBSD, all files which com
On Fri, May 04, 2007 at 07:47:06PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Fri, May 04, 2007 at 06:49:32PM +0200, Andre Poenitz wrote:
> >>>About this particular one, I proposed to make the method pure virtual,
> >>>any objection?
> >>Unless you do not end up with 85 implement
Andre Poenitz wrote:
On Fri, May 04, 2007 at 06:49:32PM +0200, Andre Poenitz wrote:
About this particular one, I proposed to make the method pure virtual,
any objection?
Unless you do not end up with 85 implementations, that's fine with me.
Negation is considered a projection...
What do you
On Fri, May 04, 2007 at 06:49:32PM +0200, Andre Poenitz wrote:
> > About this particular one, I proposed to make the method pure virtual,
> > any objection?
>
> Unless you do not end up with 85 implementations, that's fine with me.
Negation is considered a projection...
Andre'
On Fri, May 04, 2007 at 02:41:55PM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >And then look at the very recent marginal bug: AFAIK (correct me if I am
> >wrong) this happened because of missing review of the insetName -> name
> >change.
>
> Small correction: this bug appeared in the In
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
And then look at the very recent marginal bug: AFAIK (correct me if I am
wrong) this happened because of missing review of the insetName -> name
change.
Small correction: this bug appeared in the InsetOld -> Inset transfer
with the
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> And then look at the very recent marginal bug: AFAIK (correct me if I am
>> wrong) this happened because of missing review of the insetName -> name
>> change.
>
> Small correction: this bug appeared in the InsetOld -> Inset transfer
> with the remov
Abdelrazak Younes wrote:
Georg Baum wrote:
And then look at the very recent marginal bug: AFAIK (correct me if I am
wrong) this happened because of missing review of the insetName -> name
change.
Small correction: this bug appeared in the InsetOld -> Inset transfer
with the removal of setInse
Georg Baum wrote:
And then look at the very recent marginal bug: AFAIK (correct me if I am
wrong) this happened because of missing review of the insetName -> name
change.
Small correction: this bug appeared in the InsetOld -> Inset transfer
with the removal of setInsetName(). Nothin to do with
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> And then look at the very recent marginal bug: AFAIK (correct
Georg> me if I am wrong) this happened because of missing review of
Georg> the insetName -> name change. A simple and safe looking change
Georg> caused a serious bug. I am c
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
think I need to reiterate all of them, one example can be seen in my
other mail of today.
Georg, you know very well that you have to get involved in order to
lead. Uwe is simply not as competent as you in this field, I guess none
of
Michael Gerz wrote:
> I looked up the meaning of "endorse" and I must confess that I am sorry
> that you cannot endorse a product on which you have spent sooo much
> spare time.
>
> Apart from the Armenian support and the recent InsetListings discussion,
> what exactly is missing to make LyX 1.5.
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> think I need to reiterate all of them, one example can be seen in my
>> other mail of today.
>
> Georg, you know very well that you have to get involved in order to
> lead. Uwe is simply not as competent as you in this field, I guess none
> of us is
Bo Peng wrote:
Ouch... this is a big, non obvious, patch Bo... I am not sure we will
find the time to properly review it and add the missing bits before
1.5.0 :-(
InsetListings ~= InsetERT so you do not have to pay much attention to
it, other than the InsetListingsParams part.
Than why don't
...
> Index: src/insets/Inset.cpp
> ===
> --- src/insets/Inset.cpp (revision 18187)
> +++ src/insets/Inset.cpp (working copy)
> @@ -76,6 +76,7 @@
> InsetName("bibtex", Inset::BIBTEX_CODE),
> Inse
On Thu, May 03, 2007 at 03:07:58PM -0500, Bo Peng wrote:
> >
> > What do you need?
>
> I am attaching what I have right now. Many parts are missing but the
> main points are there:
>
> What I have got:
...
> Index: src/insets/Inset.cpp
> ===
Ouch... this is a big, non obvious, patch Bo... I am not sure we will
find the time to properly review it and add the missing bits before
1.5.0 :-(
InsetListings ~= InsetERT so you do not have to pay much attention to
it, other than the InsetListingsParams part.
Many other small changes are sta
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> > Seemingly, scons also fails to find libiconv:
>>
>> Bo, you might want to improve scons FreeBSD support. iconv is
>> apparently properly detected by autotools...
Bo> FreeBSD and macOS are left out because I can not test on them.
Bo> Maybe I
On Thu, 3 May 2007, Michael Gerz wrote:
José Matos schrieb:
On Thursday 03 May 2007 19:40:06
[EMAIL PROTECTED] wrote:
> Good points. Does this mean you've approved the schedule above?
>
The calendar is optimistic, and I am not know for being pessimistic. ;-)
You should, if possibl
On Thu, 3 May 2007, Bo Peng wrote:
we have to be very careful with InsetListings! If we add a half-baked
solution, people will be nagging all the time, i.e., we will be flooded
by countless bug reports ("Listing does not support this, Listing does
not support that").
I am using a list of s
Bo Peng wrote:
What do you need?
I am attaching what I have right now. Many parts are missing but the
main points are there:
Ouch... this is a big, non obvious, patch Bo... I am not sure we will
find the time to properly review it and add the missing bits before
1.5.0 :-(
What I have
> Seemingly, scons also fails to find libiconv:
Bo, you might want to improve scons FreeBSD support. iconv is apparently
properly detected by autotools...
FreeBSD and macOS are left out because I can not test on them. Maybe I
will install a FreeBSD virtual machine soon.
Bo
I am attaching what I have right now. Many parts are missing but the
main points are there:
Sorry, last patch does not have InsetListingsParams.h/cpp.
Bo
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp (revision 18187)
+++ src/L
What do you need?
I am attaching what I have right now. Many parts are missing but the
main points are there:
What I have got:
1. add InsetListings in file InsetListings.h and InsetListings.cpp,
this is a slightly modified copy of InsetERT. It already works in the
sense that you can insert
On Thursday 03 May 2007 20:38:00 Michael Gerz wrote:
> Point taken. But all hobby-horses have to be stopped by beta 3, even if
> it hurts (no matter how important or smart they are). IMHO things like
> icons rescaling falls into this category, too.
I agree and I count with every developer to imp
Abdelrazak Younes schrieb:
Since it would be arrogant to demand from all of you to adjust to my
wishes for the very little amount I could contribute I chose the
other alternative: Don't help with a product that I cannot endorse.
Georg,
I looked up the meaning of "endorse" and I must confess th
On Thursday 03 May 2007 15:49:06 Bo Peng wrote:
> > You know of course that you have the power to implement everything you
> > want locally don't you? :-)
>
> But another guy in my group will collaborate with me on this document
> and it would be easier for him if it is in lyx.1.5.0.
Since this
1 - 100 of 148 matches
Mail list logo
