After reading it, the idea makes indeed sense. But this means that we
will disallow all compilers where C++ string is not good enough (gcc
2.7.x and even 2.8.x currently, not too mention probably many
proprietary compilers).
Maybe we have to build our own standard string and wstring
"Amir" == Amir Karger [EMAIL PROTECTED] writes:
Amir Has something like this been mentioned before? When you
Amir collapse a figure, you get a little red "fig". Wouldn't it be
Amir neat if instead you got the label with which you had labelled
Amir that fig? (Of course, this wouldn't work if
"Serge" == Serge Winitzki [EMAIL PROTECTED] writes:
Serge Hi, This is to report some minor problems and troubles I've had
Serge with the latest LyX 1.0.1.
Serge Compiling lyx 1.0.1 on linux 2.0.34 slackware 3.5 (libc5) using
Serge gcc version egcs-1.1b (egcs-2.91.57): compilation errors in
"Asger" == Asger Alstrup Nielsen [EMAIL PROTECTED] writes:
After reading it, the idea makes indeed sense. But this means that
we will disallow all compilers where C++ string is not good enough
(gcc 2.7.x and even 2.8.x currently, not too mention probably many
proprietary compilers).
Asger
"Pawel" == Pawel Sokolowski [EMAIL PROTECTED] writes:
Pawel The following bug only occurs when I set LANG environment to
Pawel pl, however I only tested: pl,de,no and C. It occurs when
Pawel there is no any document opened ( only gray background ) and I
Pawel select menu (pl):
"Daniel" == Daniel Naber [EMAIL PROTECTED] writes:
Daniel Asger Alstrup Nielsen wrote:
1.1 does work for implementing new things, although it's unstable.
If you can build the stuff, you should be able to port it. If you
can't build it, let us know what fails, and we should fix things.
"Volker" == Volker Enderlein [EMAIL PROTECTED] writes:
Volker Hi, I've got some problems while running LyX 1.0.0 (02/23/99)
Volker and 1.0.1 (03/04/99) on my SGI-Workstation (SGI Indigo2 IMPACT
Volker 1, IRIX64 wega 6.2 06101031 IP28). During the Compilation
Volker with the native CC and cc
"fpetitje" == fpetitje [EMAIL PROTECTED] writes:
fpetitje In Solaris development tools there is a nice bcheck
fpetitje script. With it, we can run any non stripped ELF executable
fpetitje under the debugger and a report on memory related problems
fpetitje is produced. bcheck -all src/lyx gives
On Tue, 9 Mar 1999 12:23:05 +0100 (MET), Jean-Marc Lasgouttes
[EMAIL PROTECTED] said:
ost Anyway, by a binary search I found out that the offending
ost function is
ost void MathedIter::Insert(MathedInset* p, int type) { ...
Yes. If you have any idea on why it happens, we'd be interested...
"Martin" == Martin Ostermann [EMAIL PROTECTED] writes:
Martin On Tue, 9 Mar 1999 12:23:05 +0100 (MET), Jean-Marc Lasgouttes
Martin [EMAIL PROTECTED] said:
ost Anyway, by a binary search I found out that the offending
ost function is
ost void MathedIter::Insert(MathedInset* p, int type) { ...
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes:
No. T1 is an output encoding, that is the encoding of the font used
in the dvi file. This has nothing to do with the input encoding,
which is the encoding that LaTeX reads, in order to translate
internally to its own 7bit format.
Hi!
I updated the Encoding stuff in the CVS according to the new design document
about it.
I split the support into two halves: An EncodingConverter hierarchy that does
the dirty work of converting, and then a bunch of functions that the outside
world sees (through the Encoding.h header file).
The bug is still there in 1.0.1 when you have several error boxes in a
row: all but the right-most only respond to clicks on the left-hand end of
the box.
--
http://www.cl.cam.ac.uk/users/rrt1001/ | maxim, n. wisdom for fools
"Asger" == Asger Alstrup Nielsen [EMAIL PROTECTED] writes:
Asger I split the support into two halves: An EncodingConverter
Asger hierarchy that does the dirty work of converting, and then a
Asger bunch of functions that the outside world sees (through the
Asger Encoding.h header file). These
Jean-Marc Lasgouttes wrote:
I do not have this problem here. What compiler are you using? Did you
specify --with-included-string?
It doesn't help, it crashes again with the same output. I'm using egcs
1.1.1 on a (mostly unmodified) SuSE 6.0 system.
Regards
Daniel
--
PGP Key fingerprint =
"Daniel" == Daniel Naber [EMAIL PROTECTED] writes:
Daniel Jean-Marc Lasgouttes wrote:
I do not have this problem here. What compiler are you using? Did
you specify --with-included-string?
Daniel It doesn't help, it crashes again with the same output. I'm
Daniel using egcs 1.1.1 on a (mostly
"Brad" == [EMAIL PROTECTED] writes:
Brad ENVIRONMENT: Insert a field of type Section* (probably plain
Brad Section as well) with a page break above it
Brad GUI PATH: Insert-Import ASCII File-Import as Lines choose a
Brad file from the file browser
Brad Insert a
JMarc What is the linke that your gcc uses? I think it might be a resurgence
JMarc of the infamous static initialization order for the LString
JMarc class. Could you provide us with a backtrace with debug information?
Hi again,
gcc uses the GNU linker from
Asger,
Sorry, I have not read your document nor followed this thread, but I have
a question: are the math encodings contempled in your scheme? I'm not sure
if they are part of unicode but in the MathML page there are listed
several encodings for symbols and Greek:
Hello,
I just want to report a compiler warning:
lyxlib.h: In function `char * date()':
In file included from *manyfiles*
lyxlib.h:27: warning: comparison between signed and unsigned
Compiler bug or wrong declaration somewhere? I suppose its harmless,
but as I know nothing about *serious*
Sorry, I have not read your document nor followed this thread, but I have
a question: are the math encodings contempled in your scheme? I'm not sure
if they are part of unicode but in the MathML page there are listed
several encodings for symbols and Greek: http://www.w3.org/TR/REC-MathML/.
I did that, but only to find out that it does not compile because it
does not know what wstring is. So, should I disable the build of
encoding now? I'd rather build it even if it is not used.
Cool, thanks.
Since things do not compile for you, I can tell you are using a lame compiler
;-)
(All the math glyphs are part of Unicode.)
Sorry, this is not true. What I meant was that we can make sure all the needed
math glyphs are part of our Unicode encoding, using the private area.
Greets,
Asger
On Wed, 10 Mar 1999, Jean-Marc Lasgouttes wrote:
"Daniel" == Daniel Naber [EMAIL PROTECTED] writes:
Daniel Jean-Marc Lasgouttes wrote:
I do not have this problem here. What compiler are you using? Did
you specify --with-included-string?
Daniel It doesn't help, it crashes again with
> After reading it, the idea makes indeed sense. But this means that we
> will disallow all compilers where C++ string is not good enough (gcc
> 2.7.x and even 2.8.x currently, not too mention probably many
> proprietary compilers).
Maybe we have to build our own standard string and wstring
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes:
Amir> Has something like this been mentioned before? When you
Amir> collapse a figure, you get a little red "fig". Wouldn't it be
Amir> neat if instead you got the label with which you had labelled
Amir> that fig? (Of course, this wouldn't
> "Serge" == Serge Winitzki <[EMAIL PROTECTED]> writes:
Serge> Hi, This is to report some minor problems and troubles I've had
Serge> with the latest LyX 1.0.1.
Serge> Compiling lyx 1.0.1 on linux 2.0.34 slackware 3.5 (libc5) using
Serge> gcc version egcs-1.1b (egcs-2.91.57): compilation
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> After reading it, the idea makes indeed sense. But this means that
>> we will disallow all compilers where C++ string is not good enough
>> (gcc 2.7.x and even 2.8.x currently, not too mention probably many
>> proprietary
> "Pawel" == Pawel Sokolowski <[EMAIL PROTECTED]> writes:
Pawel> The following bug only occurs when I set LANG environment to
Pawel> pl, however I only tested: pl,de,no and C. It occurs when
Pawel> there is no any document opened ( only gray background ) and I
Pawel> select menu (pl):
> "Daniel" == Daniel Naber <[EMAIL PROTECTED]> writes:
Daniel> Asger Alstrup Nielsen wrote:
>> 1.1 does work for implementing new things, although it's unstable.
>> If you can build the stuff, you should be able to port it. If you
>> can't build it, let us know what fails, and we should fix
> "Volker" == Volker Enderlein <[EMAIL PROTECTED]> writes:
Volker> Hi, I've got some problems while running LyX 1.0.0 (02/23/99)
Volker> and 1.0.1 (03/04/99) on my SGI-Workstation (SGI Indigo2 IMPACT
Volker> 1, IRIX64 wega 6.2 06101031 IP28). During the Compilation
Volker> with the
> "fpetitje" == fpetitje <[EMAIL PROTECTED]> writes:
fpetitje> In Solaris development tools there is a nice bcheck
fpetitje> script. With it, we can run any non stripped ELF executable
fpetitje> under the debugger and a report on memory related problems
fpetitje> is produced. bcheck -all
On Tue, 9 Mar 1999 12:23:05 +0100 (MET), Jean-Marc Lasgouttes
<[EMAIL PROTECTED]> said:
ost> Anyway, by a binary search I found out that the offending
ost> function is
ost> void MathedIter::Insert(MathedInset* p, int type) { ...
> Yes. If you have any idea on why it happens, we'd be
> "Martin" == Martin Ostermann <[EMAIL PROTECTED]> writes:
Martin> On Tue, 9 Mar 1999 12:23:05 +0100 (MET), Jean-Marc Lasgouttes
Martin> <[EMAIL PROTECTED]> said:
ost> Anyway, by a binary search I found out that the offending
ost> function is
ost> void MathedIter::Insert(MathedInset* p, int
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
>> No. T1 is an output encoding, that is the encoding of the font used
>> in the dvi file. This has nothing to do with the input encoding,
>> which is the encoding that LaTeX reads, in order to translate
>> internally to its
Hi!
I updated the Encoding stuff in the CVS according to the new design document
about it.
I split the support into two halves: An EncodingConverter hierarchy that does
the dirty work of converting, and then a bunch of functions that the outside
world sees (through the Encoding.h header file).
The bug is still there in 1.0.1 when you have several error boxes in a
row: all but the right-most only respond to clicks on the left-hand end of
the box.
--
http://www.cl.cam.ac.uk/users/rrt1001/ | maxim, n. wisdom for fools
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I split the support into two halves: An EncodingConverter
Asger> hierarchy that does the dirty work of converting, and then a
Asger> bunch of functions that the outside world sees (through the
Asger> Encoding.h header
Jean-Marc Lasgouttes wrote:
> I do not have this problem here. What compiler are you using? Did you
> specify --with-included-string?
It doesn't help, it crashes again with the same output. I'm using egcs
1.1.1 on a (mostly unmodified) SuSE 6.0 system.
Regards
Daniel
--
PGP Key fingerprint
> "Daniel" == Daniel Naber <[EMAIL PROTECTED]> writes:
Daniel> Jean-Marc Lasgouttes wrote:
>> I do not have this problem here. What compiler are you using? Did
>> you specify --with-included-string?
Daniel> It doesn't help, it crashes again with the same output. I'm
Daniel> using egcs 1.1.1
> "Brad" == <[EMAIL PROTECTED]> writes:
Brad> ENVIRONMENT: Insert a field of type Section* (probably plain
Brad> Section as well) with a page break above it
Brad> GUI PATH: Insert->Import ASCII File->Import as Lines choose a
Brad> file from the file browser
JMarc> What is the linke that your gcc uses? I think it might be a resurgence
JMarc> of the infamous static initialization order for the LString
JMarc> class. Could you provide us with a backtrace with debug information?
Hi again,
gcc uses the GNU linker from
Asger,
Sorry, I have not read your document nor followed this thread, but I have
a question: are the math encodings contempled in your scheme? I'm not sure
if they are part of unicode but in the MathML page there are listed
several encodings for symbols and Greek:
Hello,
I just want to report a compiler warning:
lyxlib.h: In function `char * date()':
In file included from *manyfiles*
lyxlib.h:27: warning: comparison between signed and unsigned
Compiler bug or wrong declaration somewhere? I suppose its harmless,
but as I know nothing about *serious*
> Sorry, I have not read your document nor followed this thread, but I have
> a question: are the math encodings contempled in your scheme? I'm not sure
> if they are part of unicode but in the MathML page there are listed
> several encodings for symbols and Greek:
> I did that, but only to find out that it does not compile because it
> does not know what wstring is. So, should I disable the build of
> encoding now? I'd rather build it even if it is not used.
Cool, thanks.
Since things do not compile for you, I can tell you are using a lame compiler
;-)
> (All the math glyphs are part of Unicode.)
Sorry, this is not true. What I meant was that we can make sure all the needed
math glyphs are part of our Unicode encoding, using the private area.
Greets,
Asger
On Wed, 10 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Daniel" == Daniel Naber <[EMAIL PROTECTED]> writes:
>
> Daniel> Jean-Marc Lasgouttes wrote:
> >> I do not have this problem here. What compiler are you using? Did
> >> you specify --with-included-string?
>
> Daniel> It doesn't help, it
48 matches
Mail list logo
