bug in cvs

[Herbert Voss]

can someone confirm?
- open new doc
- choose document-class-book(koma class)
- choose document-language-spanish
- write a word
- dvi-view gives an error

the command

\addto\extrasspanish{\bbl@deactivate{~}}

is unknown

Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Thursday 16 May 2002 18:53, Herbert Voss wrote:
 can someone confirm?

No, working here.

Kornel
- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt
AkvkZEkPQX8mvpT5f9RViQ+dLY6F6wcbtLTShC/rq9ogBHNbg6UEB0Gph1BlgvC8
ZMOvXgFqPkCQ1qNZVBjkKh5hjx1dSbCMYJYT2QvI+bBKFVM+hmp4GD/xRkE472Gt
oUxQrwVAZfo=
=6oO2
-END PGP SIGNATURE-

Re: bug in cvs

[Herbert Voss]

Kornel Benko wrote:

 -BEGIN PGP SIGNED MESSAGE-
 
 On Thursday 16 May 2002 18:53, Herbert Voss wrote:
 
can someone confirm?

 
 No, working here.


ok, I see,

thanks
Herbert


-- 
http://www.lyx.org/help/

bug in cvs

[Herbert Voss]

can someone confirm?
- open new doc
- choose document->class->book(koma class)
- choose document->language->spanish
- write a word
-> dvi-view gives an error

the command

\addto\extrasspanish{\bbl@deactivate{~}}

is unknown

Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Kornel Benko]

-BEGIN PGP SIGNED MESSAGE-

On Thursday 16 May 2002 18:53, Herbert Voss wrote:
> can someone confirm?

No, working here.

Kornel
- -- 
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: PGP 6.5.8

iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt
AkvkZEkPQX8mvpT5f9RViQ+dLY6F6wcbtLTShC/rq9ogBHNbg6UEB0Gph1BlgvC8
ZMOvXgFqPkCQ1qNZVBjkKh5hjx1dSbCMYJYT2QvI+bBKFVM+hmp4GD/xRkE472Gt
oUxQrwVAZfo=
=6oO2
-END PGP SIGNATURE-

Re: bug in cvs

[Herbert Voss]

Kornel Benko wrote:

> -BEGIN PGP SIGNED MESSAGE-
> 
> On Thursday 16 May 2002 18:53, Herbert Voss wrote:
> 
>>can someone confirm?
>>
> 
> No, working here.


ok, I see,

thanks
Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Juergen Vigna]

On 09-Apr-2002 Jean-Marc Lasgouttes wrote:

 Would having prepareFile return RemoveExtension(filename_) fix this?
 
 Of course the converted files should be generated in /tmp in this
 case. However this gives rise to the same complications as in
 insetinclude. So this is more work.

I think we should generate files always in the tmp dir. We never should
generate temporary files in another dir (also if use_tempdir is false).
I understand that someone could wish to have all it's LaTeX regarding stuff
in one dir and uses use_tempdir==false, but generatring temporary files in
some dir we don't know if we will destroy already existing ones is not
really nice is it?

 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

To err is human, to repent, divine, to persist, devilish.
-- Benjamin Franklin

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Juergen == Juergen Vigna [EMAIL PROTECTED] writes:

Juergen I think we should generate files always in the tmp dir. We
Juergen never should generate temporary files in another dir (also if
Juergen use_tempdir is false). I understand that someone could wish
Juergen to have all it's LaTeX regarding stuff in one dir and uses
Juergen use_tempdir==false, but generatring temporary files in some
Juergen dir we don't know if we will destroy already existing ones is
Juergen not really nice is it?

The problem with that is for example if your file is not in the docs
dir. What name will you give to it? Maybe we should just give a unique
name like file1234.eps, or something. THen this should also be done for
include files instead of the current foo/bar.lyx = [EMAIL PROTECTED] hack.
Or we could use this scheme also for insetgraphics. 

JMarc

Re: bug in cvs

[Juergen Vigna]

On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
 Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
 
 Juergen I think we should generate files always in the tmp dir. We
 Juergen never should generate temporary files in another dir (also if
 Juergen use_tempdir is false). I understand that someone could wish
 Juergen to have all it's LaTeX regarding stuff in one dir and uses
 Juergen use_tempdir==false, but generatring temporary files in some
 Juergen dir we don't know if we will destroy already existing ones is
 Juergen not really nice is it?
 
 The problem with that is for example if your file is not in the docs
 dir. What name will you give to it? Maybe we should just give a unique
 name like file1234.eps, or something. THen this should also be done for
 include files instead of the current foo/bar.lyx = [EMAIL PROTECTED] hack.
 Or we could use this scheme also for insetgraphics. 

Is it possible to add a search path as a LaTeX command to the single LaTeX
file? So that for example all external filenames inside the LaTeX file are
without path.

   Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

I have the power to HALT PRODUCTION on all TEENAGE SEX COMEDIES!!

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Juergen == Juergen Vigna [EMAIL PROTECTED] writes:

Juergen On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
 Juergen == Juergen Vigna [EMAIL PROTECTED] writes:

Juergen I think we should generate files always in the tmp dir. We
Juergen never should generate temporary files in another dir (also if
Juergen use_tempdir is false). I understand that someone could wish
Juergen to have all it's LaTeX regarding stuff in one dir and uses
Juergen use_tempdir==false, but generatring temporary files in some
Juergen dir we don't know if we will destroy already existing ones is
Juergen not really nice is it?
  The problem with that is for example if your file is not in the
 docs dir. What name will you give to it? Maybe we should just give
 a unique name like file1234.eps, or something. THen this should
 also be done for include files instead of the current foo/bar.lyx
 = [EMAIL PROTECTED] hack. Or we could use this scheme also for
 insetgraphics.

Juergen Is it possible to add a search path as a LaTeX command to the
Juergen single LaTeX file? So that for example all external filenames
Juergen inside the LaTeX file are without path.

This is what the \input@path macro does, if I understand correctly
your question.

JMarc

Re: bug in cvs

[Juergen Vigna]

On 10-Apr-2002 Jean-Marc Lasgouttes wrote:

 Juergen Is it possible to add a search path as a LaTeX command to the
 Juergen single LaTeX file? So that for example all external filenames
 Juergen inside the LaTeX file are without path.
 
 This is what the \input@path macro does, if I understand correctly
 your question.

And do we use it? If not why? Is there a drawback using this?

Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

It was a book to kill time for those who liked it better dead.

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Juergen == Juergen Vigna [EMAIL PROTECTED] writes:

Juergen On 10-Apr-2002 Jean-Marc Lasgouttes wrote:

Juergen Is it possible to add a search path as a LaTeX command to the
Juergen single LaTeX file? So that for example all external filenames
Juergen inside the LaTeX file are without path.
  This is what the \input@path macro does, if I understand correctly
 your question.

Juergen And do we use it? If not why? Is there a drawback using this?

Yes, we do use it. It works for all latex macros that honor it, like
\includegraphics and \input/include.

I think we have everything in place to have things working `just well
enough', but this stuff will eventually need a redesign.

Unfortunately, I do not have much time to investigate, but I think
making it work with insetgraphics is just a few tweaks away.

JMarc

Re: bug in cvs

[Juergen Vigna]

On 09-Apr-2002 Jean-Marc Lasgouttes wrote:

> Would having prepareFile return RemoveExtension(filename_) fix this?
> 
> Of course the converted files should be generated in /tmp in this
> case. However this gives rise to the same complications as in
> insetinclude. So this is more work.

I think we should generate files always in the tmp dir. We never should
generate temporary files in another dir (also if use_tempdir is false).
I understand that someone could wish to have all it's LaTeX regarding stuff
in one dir and uses use_tempdir==false, but generatring temporary files in
some dir we don't know if we will destroy already existing ones is not
really nice is it?

 Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

To err is human, to repent, divine, to persist, devilish.
-- Benjamin Franklin

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:

Juergen> I think we should generate files always in the tmp dir. We
Juergen> never should generate temporary files in another dir (also if
Juergen> use_tempdir is false). I understand that someone could wish
Juergen> to have all it's LaTeX regarding stuff in one dir and uses
Juergen> use_tempdir==false, but generatring temporary files in some
Juergen> dir we don't know if we will destroy already existing ones is
Juergen> not really nice is it?

The problem with that is for example if your file is not in the docs
dir. What name will you give to it? Maybe we should just give a unique
name like file1234.eps, or something. THen this should also be done for
include files instead of the current foo/bar.lyx => [EMAIL PROTECTED] hack.
Or we could use this scheme also for insetgraphics. 

JMarc

Re: bug in cvs

[Juergen Vigna]

On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
> 
> Juergen> I think we should generate files always in the tmp dir. We
> Juergen> never should generate temporary files in another dir (also if
> Juergen> use_tempdir is false). I understand that someone could wish
> Juergen> to have all it's LaTeX regarding stuff in one dir and uses
> Juergen> use_tempdir==false, but generatring temporary files in some
> Juergen> dir we don't know if we will destroy already existing ones is
> Juergen> not really nice is it?
> 
> The problem with that is for example if your file is not in the docs
> dir. What name will you give to it? Maybe we should just give a unique
> name like file1234.eps, or something. THen this should also be done for
> include files instead of the current foo/bar.lyx => [EMAIL PROTECTED] hack.
> Or we could use this scheme also for insetgraphics. 

Is it possible to add a search path as a LaTeX command to the single LaTeX
file? So that for example all external filenames inside the LaTeX file are
without path.

   Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

I have the power to HALT PRODUCTION on all TEENAGE SEX COMEDIES!!

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:

Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote:
>>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>>
Juergen> I think we should generate files always in the tmp dir. We
Juergen> never should generate temporary files in another dir (also if
Juergen> use_tempdir is false). I understand that someone could wish
Juergen> to have all it's LaTeX regarding stuff in one dir and uses
Juergen> use_tempdir==false, but generatring temporary files in some
Juergen> dir we don't know if we will destroy already existing ones is
Juergen> not really nice is it?
>>  The problem with that is for example if your file is not in the
>> docs dir. What name will you give to it? Maybe we should just give
>> a unique name like file1234.eps, or something. THen this should
>> also be done for include files instead of the current foo/bar.lyx
>> => [EMAIL PROTECTED] hack. Or we could use this scheme also for
>> insetgraphics.

Juergen> Is it possible to add a search path as a LaTeX command to the
Juergen> single LaTeX file? So that for example all external filenames
Juergen> inside the LaTeX file are without path.

This is what the \input@path macro does, if I understand correctly
your question.

JMarc

Re: bug in cvs

[Juergen Vigna]

On 10-Apr-2002 Jean-Marc Lasgouttes wrote:

> Juergen> Is it possible to add a search path as a LaTeX command to the
> Juergen> single LaTeX file? So that for example all external filenames
> Juergen> inside the LaTeX file are without path.
> 
> This is what the \input@path macro does, if I understand correctly
> your question.

And do we use it? If not why? Is there a drawback using this?

Jug

--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen   Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

It was a book to kill time for those who liked it better dead.

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:

Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote:

Juergen> Is it possible to add a search path as a LaTeX command to the
Juergen> single LaTeX file? So that for example all external filenames
Juergen> inside the LaTeX file are without path.
>>  This is what the \input@path macro does, if I understand correctly
>> your question.

Juergen> And do we use it? If not why? Is there a drawback using this?

Yes, we do use it. It works for all latex macros that honor it, like
\includegraphics and \input/include.

I think we have everything in place to have things working `just well
enough', but this stuff will eventually need a redesign.

Unfortunately, I do not have much time to investigate, but I think
making it work with insetgraphics is just a few tweaks away.

JMarc

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Herbert == Herbert Voss [EMAIL PROTECTED] writes:

Herbert the patch
Herbert http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html

Herbert is buggy when you insert a graphic file which is in a deeper
Herbert dir than the one from the doc. In this case the absolut path
Herbert is missing, the converted image is written into the doc dir
Herbert and latex fails, because it searchs the image in the temp
Herbert dir, which is the right place.

But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in the doc dir.

JMarc

Re: bug in cvs

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

Herbert == Herbert Voss [EMAIL PROTECTED] writes:

 
 Herbert the patch
 Herbert http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
 
 Herbert is buggy when you insert a graphic file which is in a deeper
 Herbert dir than the one from the doc. In this case the absolut path
 Herbert is missing, the converted image is written into the doc dir
 Herbert and latex fails, because it searchs the image in the temp
 Herbert dir, which is the right place.
 
 But why does latex search in the tmp dir? We give it a nice
 \input@path to tell that it should also look in the doc dir.


this belongs to non-(e)ps-files which were converted.

HErbert



-- 
http://www.lyx.org/help/

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Herbert == Herbert Voss [EMAIL PROTECTED] writes:

 But why does latex search in the tmp dir? We give it a nice
 \input@path to tell that it should also look in the doc dir.


Herbert this belongs to non-(e)ps-files which were converted.

Could you explain a bit more? 

JMarc

Re: bug in cvs

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

Herbert == Herbert Voss [EMAIL PROTECTED] writes:

 
But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in the doc dir.

 
 
 Herbert this belongs to non-(e)ps-files which were converted.
 
 Could you explain a bit more? 


open a new doc and insert a graphic which is two dirs deeper
than the doc dir.

[FormGraphics]out_name: texte/Aufsatz/Digitus/nand-neu.gif
Attempting to convert image file: ~/texte/Aufsatz/Digitus/nand-neu.gif
[latex]filename = texte/Aufsatz/Digitus/nand-neu.gif
Recognised Fileformat: gif
decideOutput: lyxrc.pdf_mode = 0
decideOutput: we have PostScript mode
tempname = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0/nand-neu.gif
buf::tmppath = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0
filename_ = texte/Aufsatz/Digitus/nand-neu.gif
outfile_base = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0/nand-neu

but the temp dir contains only:

voss@maria:/tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0 ls -l
total 12
-rw-r--r--1 voss users6230 Apr  9 17:58 demo.log
-rw-r--r--1 voss users 806 Apr  9 17:58 demo.tex
voss@maria:/tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0 cd ..

the converted nand-neu.gif is missing. but in the graphics home
dir we have the converted one

voss@maria:~ ls -l texte/Aufsatz/Digitus/nand*
-rw-r--r--1 voss users   24237 Apr  9 17:58 
texte/Aufsatz/Digitus/nand-neu.eps   --- !!!
-rw---1 voss users1294 May 22  1999 
texte/Aufsatz/Digitus/nand-neu.gif

hope, this helps

Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Herbert == Herbert Voss [EMAIL PROTECTED] writes:

Herbert open a new doc and insert a graphic which is two dirs deeper
Herbert than the doc dir.
[...]
Herbert hope, this helps

I guess it does, but I do not know when I will have time to
investigate this.

JMarc

Re: bug in cvs

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

Herbert == Herbert Voss [EMAIL PROTECTED] writes:

 
 Herbert open a new doc and insert a graphic which is two dirs deeper
 Herbert than the doc dir.
 [...]
 Herbert hope, this helps
 
 I guess it does, but I do not know when I will have time to
 investigate this.


but remember that this is an important bug! Therefore

it seems to be better to make the path absolute, than
all works well. Is this not a better solution? But I have
no idea about such stuff.

http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35468.html

Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Jean-Marc Lasgouttes]

 Herbert == Herbert Voss [EMAIL PROTECTED] writes:

Herbert Jean-Marc Lasgouttes wrote:
 Herbert == Herbert Voss [EMAIL PROTECTED]
 writes:
 

 But why does latex search in the tmp dir? We give it a nice
 \input@path to tell that it should also look in the doc dir.
 
Herbert this belongs to non-(e)ps-files which were converted.
 Could you explain a bit more?


Herbert open a new doc and insert a graphic which is two dirs deeper
Herbert than the doc dir.

Would having prepareFile return RemoveExtension(filename_) fix this?

Of course the converted files should be generated in /tmp in this
case. However this gives rise to the same complications as in
insetinclude. So this is more work.

JMarc

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:

Herbert> the patch
Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html

Herbert> is buggy when you insert a graphic file which is in a deeper
Herbert> dir than the one from the doc. In this case the absolut path
Herbert> is missing, the converted image is written into the doc dir
Herbert> and latex fails, because it searchs the image in the temp
Herbert> dir, which is the right place.

But why does latex search in the tmp dir? We give it a nice
\input@path to tell that it should also look in the doc dir.

JMarc

Re: bug in cvs

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
> 
> Herbert> the patch
> Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html
> 
> Herbert> is buggy when you insert a graphic file which is in a deeper
> Herbert> dir than the one from the doc. In this case the absolut path
> Herbert> is missing, the converted image is written into the doc dir
> Herbert> and latex fails, because it searchs the image in the temp
> Herbert> dir, which is the right place.
> 
> But why does latex search in the tmp dir? We give it a nice
> \input@path to tell that it should also look in the doc dir.


this belongs to non-(e)ps-files which were converted.

HErbert



-- 
http://www.lyx.org/help/

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:

>> But why does latex search in the tmp dir? We give it a nice
>> \input@path to tell that it should also look in the doc dir.


Herbert> this belongs to non-(e)ps-files which were converted.

Could you explain a bit more? 

JMarc

Re: bug in cvs

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
> 
>>>But why does latex search in the tmp dir? We give it a nice
>>>\input@path to tell that it should also look in the doc dir.
>>>
> 
> 
> Herbert> this belongs to non-(e)ps-files which were converted.
> 
> Could you explain a bit more? 


open a new doc and insert a graphic which is two dirs deeper
than the doc dir.

[FormGraphics]out_name: texte/Aufsatz/Digitus/nand-neu.gif
Attempting to convert image file: ~/texte/Aufsatz/Digitus/nand-neu.gif
[latex]filename = texte/Aufsatz/Digitus/nand-neu.gif
Recognised Fileformat: gif
decideOutput: lyxrc.pdf_mode = 0
decideOutput: we have PostScript mode
tempname = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0/nand-neu.gif
buf::tmppath = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0
filename_ = texte/Aufsatz/Digitus/nand-neu.gif
outfile_base = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0/nand-neu

but the temp dir contains only:

voss@maria:/tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0> ls -l
total 12
-rw-r--r--1 voss users6230 Apr  9 17:58 demo.log
-rw-r--r--1 voss users 806 Apr  9 17:58 demo.tex
voss@maria:/tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0> cd ..

the converted nand-neu.gif is missing. but in the graphics home
dir we have the converted one

voss@maria:~> ls -l texte/Aufsatz/Digitus/nand*
-rw-r--r--1 voss users   24237 Apr  9 17:58 
texte/Aufsatz/Digitus/nand-neu.eps   <--- !!!
-rw---1 voss users1294 May 22  1999 
texte/Aufsatz/Digitus/nand-neu.gif

hope, this helps

Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:

Herbert> open a new doc and insert a graphic which is two dirs deeper
Herbert> than the doc dir.
[...]
Herbert> hope, this helps

I guess it does, but I do not know when I will have time to
investigate this.

JMarc

Re: bug in cvs

[Herbert Voss]

Jean-Marc Lasgouttes wrote:

>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
> 
> Herbert> open a new doc and insert a graphic which is two dirs deeper
> Herbert> than the doc dir.
> [...]
> Herbert> hope, this helps
> 
> I guess it does, but I do not know when I will have time to
> investigate this.


but remember that this is an important bug! Therefore

it seems to be better to make the path absolute, than
all works well. Is this not a better solution? But I have
no idea about such stuff.

http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35468.html

Herbert


-- 
http://www.lyx.org/help/

Re: bug in cvs

[Jean-Marc Lasgouttes]

> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:

Herbert> Jean-Marc Lasgouttes wrote:
>>> "Herbert" == Herbert Voss <[EMAIL PROTECTED]>
>>> writes:
>>> 
>>
 But why does latex search in the tmp dir? We give it a nice
 \input@path to tell that it should also look in the doc dir.
 
Herbert> this belongs to non-(e)ps-files which were converted.
>> Could you explain a bit more?


Herbert> open a new doc and insert a graphic which is two dirs deeper
Herbert> than the doc dir.

Would having prepareFile return RemoveExtension(filename_) fix this?

Of course the converted files should be generated in /tmp in this
case. However this gives rise to the same complications as in
insetinclude. So this is more work.

JMarc

bug in cvs

[Herbert Voss]

the patch

http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html

is buggy when you insert a graphic file which is in a deeper dir
than the one from the doc. In this case the absolut path is missing,
the converted image is written into the doc dir and latex fails,
because it searchs the image in the temp dir, which is the right
place.

Herbert

-- 
http://www.lyx.org/help/

bug in cvs

[Herbert Voss]

the patch

http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html

is buggy when you insert a graphic file which is in a deeper dir
than the one from the doc. In this case the absolut path is missing,
the converted image is written into the doc dir and latex fails,
because it searchs the image in the temp dir, which is the right
place.

Herbert

-- 
http://www.lyx.org/help/

BUG in cvs

[Herbert Voss]

can anybody confirm?

- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
--- the caption is outside the float

this happens only for graphic insets.

Herbert

-- 
http://www.lyx.org/help/

Re: BUG in cvs

[John Levon]

On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:

 - insert float
 - insert into the float a graphic
 - and insert a caption
 - save and close
 - reopen
 --- the caption is outside the float

no, I can't spot any problems like this ...

john

-- 
Way back at the beginning of time around 1970 the first man page was
 handed down from on high. Every one since is an edited copy.
- John Hasler [EMAIL PROTECTED]

Re: BUG in cvs

[Herbert Voss]

John Levon wrote:

 On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
 
 
- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
--- the caption is outside the float

 
 no, I can't spot any problems like this ...


thanks, than it's my own fault.


Herbert



-- 
http://www.lyx.org/help/

BUG in cvs

[Herbert Voss]

can anybody confirm?

- insert float
- insert into the float a graphic
- and insert a caption
- save and close
- reopen
---> the caption is outside the float

this happens only for graphic insets.

Herbert

-- 
http://www.lyx.org/help/

Re: BUG in cvs

[John Levon]

On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:

> - insert float
> - insert into the float a graphic
> - and insert a caption
> - save and close
> - reopen
> ---> the caption is outside the float

no, I can't spot any problems like this ...

john

-- 
"Way back at the beginning of time around 1970 the first man page was
 handed down from on high. Every one since is an edited copy."
- John Hasler <[EMAIL PROTECTED]>

Re: BUG in cvs

[Herbert Voss]

John Levon wrote:

> On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote:
> 
> 
>>- insert float
>>- insert into the float a graphic
>>- and insert a caption
>>- save and close
>>- reopen
>>---> the caption is outside the float
>>
> 
> no, I can't spot any problems like this ...


thanks, than it's my own fault.


Herbert



-- 
http://www.lyx.org/help/

Citations only shown as [?]. Bug in CVS?

[R. Lahaye]

Hi,

I am using a bibtex file, which is included at the bottom of the document.
All the bibtex-entries appear in the Citation-dialog.
There's no problem with the bibtex file, since it works fine with LyX 1.1.6.

The cited refs are correctly listed at the end of the paper, but
the references themselves appear as question-marks in the text [?]
when view DVI or PS.

The following ls -s is in /tmp (CsSA.lyx is the main lyx file):

   3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.aux
   3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.bbl
   1 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.blg
  29 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.dvi
   9 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.log
3144 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.ps
  21 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex
   3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex.dep



Is this problem due to a bug in CVS, or has something been corrupted
at my side?

Thanks,
Rob.

Re: Citations only shown as [?]. Bug in CVS?

[Allan Rae]

It would seem that another latex run may be needed to fill in the
labels.  Check the latex log file to see if there are any error
messages in the log.  Also check to see if a warning line exists that
says something like need another latex run as this is also used to
trigger additional latex runs.

Allan. (ARRae)

Re: Citations only shown as [?]. Bug in CVS?

[R. Lahaye]

R. Lahaye wrote:

 the references themselves appear as question-marks in the text [?]

Sorry, my mistake. I had a look at the LaTeX log file and two equations
were labeled with exactly the same label. For some reason that skrewed
up the referencing table (why?).

Removing one of the equation labels solved the problem.

Rob.

Re: Citations only shown as [?]. Bug in CVS?

[Allan Rae]

On Wed, 13 Feb 2002, R. Lahaye wrote:

 R. Lahaye wrote:
 
  the references themselves appear as question-marks in the text [?]

 Sorry, my mistake. I had a look at the LaTeX log file and two equations
 were labeled with exactly the same label. For some reason that skrewed
 up the referencing table (why?).

 Removing one of the equation labels solved the problem.

What may be happening is that LyX sees the error and stops without
reporting the error or, more likely, LyX sees that the exit value of
latex says somethings wrong but LyX doesn't know what and stays quiet.

An extra latex run is what was required but as latex reported an error
LyX never makes that extra call.  So what we need is for lyx to report
the error about multiply defined labels.

Allan. (ARRae)

Citations only shown as [?]. Bug in CVS?

[R. Lahaye]

Hi,

I am using a bibtex file, which is included at the bottom of the document.
All the bibtex-entries appear in the Citation-dialog.
There's no problem with the bibtex file, since it works fine with LyX 1.1.6.

The cited refs are correctly listed at the end of the paper, but
the references themselves appear as question-marks in the text [?]
when view DVI or PS.

The following "ls -s" is in /tmp (CsSA.lyx is the main lyx file):

   3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.aux
   3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.bbl
   1 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.blg
  29 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.dvi
   9 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.log
3144 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.ps
  21 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex
   3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex.dep



Is this problem due to a bug in CVS, or has something been corrupted
at my side?

Thanks,
Rob.

Re: Citations only shown as [?]. Bug in CVS?

[Allan Rae]

It would seem that another latex run may be needed to fill in the
labels.  Check the latex log file to see if there are any error
messages in the log.  Also check to see if a warning line exists that
says something like "need another latex run" as this is also used to
trigger additional latex runs.

Allan. (ARRae)

Re: Citations only shown as [?]. Bug in CVS?

[R. Lahaye]

R. Lahaye wrote:
>
> the references themselves appear as question-marks in the text [?]

Sorry, my mistake. I had a look at the LaTeX log file and two equations
were labeled with exactly the same label. For some reason that skrewed
up the referencing table (why?).

Removing one of the equation labels solved the problem.

Rob.

Re: Citations only shown as [?]. Bug in CVS?

[Allan Rae]

On Wed, 13 Feb 2002, R. Lahaye wrote:

> R. Lahaye wrote:
> >
> > the references themselves appear as question-marks in the text [?]
>
> Sorry, my mistake. I had a look at the LaTeX log file and two equations
> were labeled with exactly the same label. For some reason that skrewed
> up the referencing table (why?).
>
> Removing one of the equation labels solved the problem.

What may be happening is that LyX sees the error and stops without
reporting the error or, more likely, LyX sees that the exit value of
latex says somethings wrong but LyX doesn't know what and stays quiet.

An extra latex run is what was required but as latex reported an error
LyX never makes that extra call.  So what we need is for lyx to report
the error about multiply defined labels.

Allan. (ARRae)

[BUG] HEAD cvs InsetNote() causes assert failure

[Ben Stanley]

This constructor passes an un-initialised pos to insertStringAsLines. I 
presume it should be initialised to 0?

This causes an assert failure down in Pragraph::pimpl::insertChar().

// This constructor is used for reading old InsetInfo
InsetNote::InsetNote(Buffer const * buf, string const  contents,
 bool collapsed)
: InsetCollapsable(collapsed)
{
init();

Paragraph * par = inset.paragraph();
LyXFont font(LyXFont::ALL_INHERIT, buf-params.language);

// Since XForms doesn't support RTL, we can assume that old notes
// in RTL documents are written in English.
if (font.language()-RightToLeft())
font.setLanguage(default_language);

lyx::pos_type pos;
buf-insertStringAsLines(par, pos, font, strip(contents, '\n'));
}

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Andre Poenitz]

On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
 This constructor passes an un-initialised pos to insertStringAsLines. I 
 presume it should be initialised to 0?

Gasp! Yes. Certainly. And it used to be. My fault.

I can even explain how this evolved... but I'll try to fix it first.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Andre Poenitz]

On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
 This constructor passes an un-initialised pos to insertStringAsLines. I 
 presume it should be initialised to 0?

And now to the explanation: I saw the useless variable, removed it. Then
noticed that the parameter was passed by (non-const) reference, and
re-introduced it. And of course forgot that there was a initilization in
the beginning.

I hope this is the explantion for all those sudden crashes that came up
suspiciously soon after the introduction of lyx::pos_type...

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Ben Stanley]

Andre Poenitz wrote:

On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:

This constructor passes an un-initialised pos to insertStringAsLines. I 
presume it should be initialised to 0?


And now to the explanation: I saw the useless variable, removed it. Then
noticed that the parameter was passed by (non-const) reference, and
re-introduced it. And of course forgot that there was a initilization in
the beginning.

I hope this is the explantion for all those sudden crashes that came up
suspiciously soon after the introduction of lyx::pos_type...

Andre'

I propose a grep for lyx::pos_type and a double check...

Where one bug has been found, similar ones usually lurk...

Ben.

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Andre Poenitz]

On Thu, Nov 29, 2001 at 04:15:29AM +1100, Ben Stanley wrote:
 I propose a grep for lyx::pos_type and a double check...

Guess what I did the last ten minutes...

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

[BUG] HEAD cvs InsetNote() causes assert failure

[Ben Stanley]

This constructor passes an un-initialised pos to insertStringAsLines. I 
presume it should be initialised to 0?

This causes an assert failure down in Pragraph::pimpl::insertChar().

// This constructor is used for reading old InsetInfo
InsetNote::InsetNote(Buffer const * buf, string const & contents,
 bool collapsed)
: InsetCollapsable(collapsed)
{
init();

Paragraph * par = inset.paragraph();
LyXFont font(LyXFont::ALL_INHERIT, buf->params.language);

// Since XForms doesn't support RTL, we can assume that old notes
// in RTL documents are written in English.
if (font.language()->RightToLeft())
font.setLanguage(default_language);

lyx::pos_type pos;
buf->insertStringAsLines(par, pos, font, strip(contents, '\n'));
}

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Andre Poenitz]

On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
> This constructor passes an un-initialised pos to insertStringAsLines. I 
> presume it should be initialised to 0?

Gasp! Yes. Certainly. And it used to be. My fault.

I can even explain how this evolved... but I'll try to fix it first.

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Andre Poenitz]

On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
> This constructor passes an un-initialised pos to insertStringAsLines. I 
> presume it should be initialised to 0?

And now to the explanation: I saw the "useless" variable, removed it. Then
noticed that the parameter was passed by (non-const) reference, and
re-introduced it. And of course forgot that there was a initilization in
the beginning.

I hope this is the explantion for all those sudden crashes that came up
suspiciously soon after the introduction of lyx::pos_type...

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Ben Stanley]

Andre Poenitz wrote:

>On Thu, Nov 29, 2001 at 03:47:50AM +1100, Ben Stanley wrote:
>
>>This constructor passes an un-initialised pos to insertStringAsLines. I 
>>presume it should be initialised to 0?
>>
>
>And now to the explanation: I saw the "useless" variable, removed it. Then
>noticed that the parameter was passed by (non-const) reference, and
>re-introduced it. And of course forgot that there was a initilization in
>the beginning.
>
>I hope this is the explantion for all those sudden crashes that came up
>suspiciously soon after the introduction of lyx::pos_type...
>
>Andre'
>
I propose a grep for lyx::pos_type and a double check...

Where one bug has been found, similar ones usually lurk...

Ben.

Re: [BUG] HEAD cvs InsetNote() causes assert failure

[Andre Poenitz]

On Thu, Nov 29, 2001 at 04:15:29AM +1100, Ben Stanley wrote:
> I propose a grep for lyx::pos_type and a double check...

Guess what I did the last ten minutes...

Andre'

-- 
André Pönitz .. [EMAIL PROTECTED]

Re: mathed-bug latest cvs

[Andre Poenitz]

On Sat, Sep 08, 2001 at 07:02:44AM +0200, Herbert Voss wrote:
 in a displayed formula a fraction should be in displaystyle,
 but it's in scriptstyle in dvi output.

This is nigh to impossible... This would mean I'd explicitly write a
\scriptstyle on output which I certainly don't.

How does the exported LaTeX look like?

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

Re: mathed-bug latest cvs

[Andre Poenitz]

On Sat, Sep 08, 2001 at 07:02:44AM +0200, Herbert Voss wrote:
> in a displayed formula a fraction should be in displaystyle,
> but it's in scriptstyle in dvi output.

This is nigh to impossible... This would mean I'd explicitly write a
\scriptstyle on output which I certainly don't.

How does the exported LaTeX look like?

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

mathed-bug latest cvs

[Herbert Voss]

in a displayed formula a fraction should be in displaystyle,
but it's in scriptstyle in dvi output. on screen the
charactersize is correct.

Herbert


-- 
http://www.educat.hu-berlin.de/~voss/lyx/

mathed-bug latest cvs

[Herbert Voss]

in a displayed formula a fraction should be in displaystyle,
but it's in scriptstyle in dvi output. on screen the
charactersize is correct.

Herbert


-- 
http://www.educat.hu-berlin.de/~voss/lyx/

math bug in cvs

[Herbert Voss]

1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like

\begin_inset Formula \begin{eqnarray*}
11  21  31\\
21  22  23\\
31  32 - missing cell!
\end{eqnarray*}

\end_inset 

in 1.1.6 this doesn't matter, the lyxfile is always
read well.

reading this formula with 1.2.0 gives always the message
that the file may be corrupted (truncated). 
so far so good, but lyx ignores all the text behind 
this formula.

I suppose, that \end_inset is not a real delimiter
for parsing formulas. 

Herbert
 
-- 
http://www.educat.hu-berlin.de/~voss/lyx/

Re: math bug in cvs

[Herbert Voss]

Andre Poenitz wrote:
 
  1.1.6fix3:
  in an equnarray you can delete the lower right cell.
  the formula than looks like
 
  \begin_inset Formula \begin{eqnarray*}
  11  21  31\\
  21  22  23\\
  31  32 - missing cell!
  \end{eqnarray*}
 
  \end_inset
 
 But that's no well formed LaTeX, even if 1.1.6 allows you to create such
 beasts.

sure! but it was lyx which allowed the user to do that! 
and btw: it's no problem to run this with latex! means
it's allowed latex stuff ...

 It would be pretty difficult to parse bad input, given that it's already a
 pain to parse correct input...

this is another question. why do you have environments
\begin_inset TYPE
\end_inset

when you never stop parsing TYPE with reaching \end_inset???

  I suppose, that \end_inset is not a real delimiter
  for parsing formulas.
 
 It is not. Actually, it does not even fit well into the scheme, since it
 contains an underscore which is usually not allowed in latex macro names...

I don't know if I understand well: you mean, that all
lyx1.1.6 and older files can't be read with 1.2.0 when 
they have this little unimportant bug in a formula

Herbert


-- 
http://www.educat.hu-berlin.de/~voss/lyx/

Re: math bug in cvs

[Andre Poenitz]

 sure! but it was lyx which allowed the user to do that! 
 and btw: it's no problem to run this with latex! means
 it's allowed latex stuff ...

Ok. I did not know that, so this has to be fixed indeed.

  It would be pretty difficult to parse bad input, given that it's already a
  pain to parse correct input...
 
 this is another question. why do you have environments
 \begin_inset TYPE
 \end_inset
 
 when you never stop parsing TYPE with reaching \end_inset???

That's how the outside world does insets. The math parser reads from a $,
\[, \begin{eqnarray} to the corresponding end token. In this case the end
token gets swallowed when the parser tries to read the second but last cell
of the eqnarray which it expects to be terminated by a  and nothing else.

  It is not. Actually, it does not even fit well into the scheme, since it
  contains an underscore which is usually not allowed in latex macro names...
 
 I don't know if I understand well: you mean, that all
 lyx1.1.6 and older files can't be read with 1.2.0 when 
 they have this little unimportant bug in a formula

I don't know that either ;-)

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

Re: math bug in cvs

[Andre Poenitz]

 | reading this formula with 1.2.0 gives always the message
 | that the file may be corrupted (truncated). 
 | so far so good, but lyx ignores all the text behind 
 | this formula.
 
 so the formula parser does not read (and remove) the \end_inset...

It ignores after its own end everything up to the next \end_inset.

I think the only comparatively safe way is to have the lexer reading into a
vectortoken up to an \end_inset and let the real parser operate on
this thing. So an \end_inset cannot be ignored by some wierd structure the
parser does not understand...

Maybe I should simply do that.

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

Re: math bug in cvs

[Andre Poenitz]

 (if I understands this correctly)... yes why not.
 
 ...but to avoid rewriting anything in the parser, output it into a
 ostringstream and pass that to the parser just as usual.

That would be the simple solution. Indeed.

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

math bug in cvs

[Herbert Voss]

1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like

\begin_inset Formula \begin{eqnarray*}
11 & 21 & 31\\
21 & 22 & 23\\
31 & 32 <- missing cell!
\end{eqnarray*}

\end_inset 

in 1.1.6 this doesn't matter, the lyxfile is always
read well.

reading this formula with 1.2.0 gives always the message
that the file may be corrupted (truncated). 
so far so good, but lyx ignores all the text behind 
this formula.

I suppose, that "\end_inset" is not a real delimiter
for parsing formulas. 

Herbert
 
-- 
http://www.educat.hu-berlin.de/~voss/lyx/

Re: math bug in cvs

[Herbert Voss]

Andre Poenitz wrote:
> 
> > 1.1.6fix3:
> > in an equnarray you can delete the lower right cell.
> > the formula than looks like
> >
> > \begin_inset Formula \begin{eqnarray*}
> > 11 & 21 & 31\\
> > 21 & 22 & 23\\
> > 31 & 32 <- missing cell!
> > \end{eqnarray*}
> >
> > \end_inset
> >
> But that's no well formed LaTeX, even if 1.1.6 allows you to create such
> beasts.

sure! but it was lyx which allowed the user to do that! 
and btw: it's no problem to run this with latex! means
it's allowed latex stuff ...

> It would be pretty difficult to parse bad input, given that it's already a
> pain to parse correct input...

this is another question. why do you have environments
\begin_inset TYPE
\end_inset

when you never stop parsing TYPE with reaching \end_inset???

> > I suppose, that "\end_inset" is not a real delimiter
> > for parsing formulas.
> 
> It is not. Actually, it does not even fit well into the scheme, since it
> contains an underscore which is usually not allowed in latex macro names...

I don't know if I understand well: you mean, that all
lyx1.1.6 and older files can't be read with 1.2.0 when 
they have this little unimportant bug in a formula

Herbert


-- 
http://www.educat.hu-berlin.de/~voss/lyx/

Re: math bug in cvs

[Andre Poenitz]

> sure! but it was lyx which allowed the user to do that! 
> and btw: it's no problem to run this with latex! means
> it's allowed latex stuff ...

Ok. I did not know that, so this has to be fixed indeed.

> > It would be pretty difficult to parse bad input, given that it's already a
> > pain to parse correct input...
> 
> this is another question. why do you have environments
> \begin_inset TYPE
> \end_inset
> 
> when you never stop parsing TYPE with reaching \end_inset???

That's how the outside world does insets. The math parser reads from a $,
\[, \begin{eqnarray} to the corresponding end token. In this case the end
token gets swallowed when the parser tries to read the second but last cell
of the eqnarray which it expects to be terminated by a & and nothing else.

> > It is not. Actually, it does not even fit well into the scheme, since it
> > contains an underscore which is usually not allowed in latex macro names...
> 
> I don't know if I understand well: you mean, that all
> lyx1.1.6 and older files can't be read with 1.2.0 when 
> they have this little unimportant bug in a formula

I don't know that either ;-)

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

Re: math bug in cvs

[Andre Poenitz]

> | reading this formula with 1.2.0 gives always the message
> | that the file may be corrupted (truncated). 
> | so far so good, but lyx ignores all the text behind 
> | this formula.
> 
> so the formula parser does not read (and remove) the \end_inset...

It ignores after its own end everything up to the next \end_inset.

I think the only comparatively safe way is to have the lexer reading into a
vector up to an \end_inset and let the "real parser" operate on
this thing. So an \end_inset cannot be ignored by some wierd structure the
parser does not understand...

Maybe I should simply do that.

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

Re: math bug in cvs

[Andre Poenitz]

> (if I understands this correctly)... yes why not.
> 
> ...but to avoid rewriting anything in the parser, output it into a
> ostringstream and pass that to the parser just as usual.

That would be the simple solution. Indeed.

Andre'

-- 
André Pönitz . [EMAIL PROTECTED]

Re: bug: Latest CVS preferences and converters

[Angus Leeming]

On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
 I can't add/modify converters using the Edit-Preferences screens,
 I had to add them by hand into my .lyx/preferences.

Fixed now!
Angus

Re: bug: Latest CVS preferences and converters

[John Levon]

On Tue, Jun 12, 2001 at 12:36:36PM +0100, Angus Leeming wrote:

 On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
  I can't add/modify converters using the Edit-Preferences screens,
  I had to add them by hand into my .lyx/preferences.
 
 Fixed now!
 Angus

while we're on this, we need somewhere in Preferences to set

\view_dvi_paper_option 

or whatever, to allow us to inter-operate with KDE2's kdvi that
doesn't allow -paper.

I'm not sure where it should go ?

thanks
john

-- 
Please let's not resume the argument with the usual whining about how
 this feature will wipe out humanity or bring us to the promised land.
- Charles Campbell on magic words in Subject: headers

Re: bug: Latest CVS preferences and converters

[Angus Leeming]

On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
> I can't add/modify converters using the Edit->Preferences screens,
> I had to add them by hand into my .lyx/preferences.

Fixed now!
Angus

Re: bug: Latest CVS preferences and converters

[John Levon]

On Tue, Jun 12, 2001 at 12:36:36PM +0100, Angus Leeming wrote:

> On Monday 28 May 2001 08:52, Kayvan A. Sylvan wrote:
> > I can't add/modify converters using the Edit->Preferences screens,
> > I had to add them by hand into my .lyx/preferences.
> 
> Fixed now!
> Angus

while we're on this, we need somewhere in Preferences to set

\view_dvi_paper_option ""

or whatever, to allow us to inter-operate with KDE2's kdvi that
doesn't allow -paper.

I'm not sure where it should go ?

thanks
john

-- 
"Please let's not resume the argument with the usual whining about how
 this feature will wipe out humanity or bring us to the promised land."
- Charles Campbell on magic words in Subject: headers

bug: Latest CVS preferences and converters

[Kayvan A. Sylvan]

I can't add/modify converters using the Edit-Preferences screens,
I had to add them by hand into my .lyx/preferences.

---Kayvan
-- 
Kayvan A. Sylvan   | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory

bug: Latest CVS preferences and converters

[Kayvan A. Sylvan]

I can't add/modify converters using the Edit->Preferences screens,
I had to add them by hand into my .lyx/preferences.

---Kayvan
-- 
Kayvan A. Sylvan   | Proud husband of  | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory

Keymap selection [was Re: Bug in CVS]

[Dekel Tsur]

On Thu, Sep 28, 2000 at 11:40:22PM +0300, Dekel Tsur wrote:
 The problem is in Intl::InitKeyMapper: Since the "default" language is
 removed, n should be initialized to 0.

This reminds me that I plan to add automatic keymap switching according to
the current language (this is currently done with Hebrew/English).
This means that the old keymap selection dialog should not be ported to the
preferences dialog (however, I don't know when I will be able to do this, as
I need to finish the export code first. So if porting the dialog isn't very
time consuming, it can be done).

Keymap selection [was Re: Bug in CVS]

[Dekel Tsur]

On Thu, Sep 28, 2000 at 11:40:22PM +0300, Dekel Tsur wrote:
> The problem is in Intl::InitKeyMapper: Since the "default" language is
> removed, n should be initialized to 0.

This reminds me that I plan to add automatic keymap switching according to
the current language (this is currently done with Hebrew/English).
This means that the old keymap selection dialog should not be ported to the
preferences dialog (however, I don't know when I will be able to do this, as
I need to finish the export code first. So if porting the dialog isn't very
time consuming, it can be done).

Re: Bug in CVS

[Jean-Marc Lasgouttes]

 "Dekel" == Dekel Tsur [EMAIL PROTECTED] writes:

Dekel But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since
Dekel the "default" language is removed, n should be initialized to
Dekel 0. I've attached a patch that does both fixes.
   
Applied.

JMarc

Re: Bug in CVS

[Jean-Marc Lasgouttes]

> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:

Dekel> But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since
Dekel> the "default" language is removed, n should be initialized to
Dekel> 0. I've attached a patch that does both fixes.
   
Applied.

JMarc

Re: Bug in CVS

[Lars Gullik Bjønnes]

Andre Poenitz [EMAIL PROTECTED] writes:

|  #3  0x815ec58 in lyx::abort () at abort.C:9
|  #4  0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
|  ^ This causes
|the crash
| 
| If lyxstring really mimics std::string, the assert is correct: You should
| never call a string's constructor on a NULL pointer.  I think until a day
| or two ago lyxstring behaved wrong by quietly accepting the NULL pointer
| and creating an empty string.

Correct.

| 
| The actual problem is here:
| 
|  #5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
| 
| This line should read:
| 
|   return browser ? fl_get_browser_line(browser, sel) : string();
| 
| instead of:
| 
|   return browser ? fl_get_browser_line(browser, sel) : 0;

fixed.

Lgb

Re: Bug in CVS

[Dekel Tsur]

On Thu, Sep 28, 2000 at 05:49:02PM +0200, Lars Gullik Bjnnes wrote:
 | The actual problem is here:
 | 
 |  #5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
 | 
 | This line should read:
 | 
 |   return browser ? fl_get_browser_line(browser, sel) : string();
 | 
 | instead of:
 | 
 |   return browser ? fl_get_browser_line(browser, sel) : 0;
 
 fixed.
 

This doesn't solve the problem, as the crash occurs with browser != 0.
The problem is that sel = 0, so fl_get_browser_line(browser, sel) returns 0.
So the fix should be
   return (browser  sel  0) ? fl_get_browser_line(browser, sel) : string();
   
But why sel is 0 ?
The problem is in Intl::InitKeyMapper: Since the "default" language is
removed, n should be initialized to 0.
I've attached a patch that does both fixes.
   

 patch.gz

Re: Bug in CVS

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| > #3  0x815ec58 in lyx::abort () at abort.C:9
| > #4  0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
| > ^ This causes
| >   the crash
| 
| If lyxstring really mimics std::string, the assert is correct: You should
| never call a string's constructor on a NULL pointer.  I think until a day
| or two ago lyxstring behaved wrong by quietly accepting the NULL pointer
| and creating an empty string.

Correct.

| 
| The actual problem is here:
| 
| > #5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
| 
| This line should read:
| 
|   return browser ? fl_get_browser_line(browser, sel) : string();
| 
| instead of:
| 
|   return browser ? fl_get_browser_line(browser, sel) : 0;

fixed.

Lgb

Re: Bug in CVS

[Dekel Tsur]

On Thu, Sep 28, 2000 at 05:49:02PM +0200, Lars Gullik Bjnnes wrote:
> | The actual problem is here:
> | 
> | > #5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
> | 
> | This line should read:
> | 
> |   return browser ? fl_get_browser_line(browser, sel) : string();
> | 
> | instead of:
> | 
> |   return browser ? fl_get_browser_line(browser, sel) : 0;
> 
> fixed.
> 

This doesn't solve the problem, as the crash occurs with browser != 0.
The problem is that sel = 0, so fl_get_browser_line(browser, sel) returns 0.
So the fix should be
   return (browser && sel > 0) ? fl_get_browser_line(browser, sel) : string();
   
But why sel is 0 ?
The problem is in Intl::InitKeyMapper: Since the "default" language is
removed, n should be initialized to 0.
I've attached a patch that does both fixes.
   

 patch.gz

Bug in CVS

[Dekel Tsur]

When \kbmap is true, LyX crashes on startup. This bug is very recent (last day
or two).
The backtrace:

#0  0x401e1a01 in kill ()
#1  0x401e1863 in gsignal ()
#2  0x401e28c5 in abort ()
#3  0x815ec58 in lyx::abort () at abort.C:9
#4  0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
^ This causes
  the crash
#5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
#6  0x8088e5e in Intl::Keymap (this=0x81fb8a0, code=23) at intl.C:339
#7  0x8088cf3 in Intl::InitKeyMapper (this=0x81fb8a0, on=true) at intl.C:308
#8  0x80640bf in LyXView::init (this=0x81f3080) at LyXView.C:326
#9  0x8095aa1 in LyXGUI::init (this=0x81d3e40) at lyx_gui.C:251
#10 0x80971c6 in LyX::LyX (this=0xbb40, argc=0xbb60, argv=0xbb74)
at ../src/lyx_main.C:105
#11 0x80b5fd6 in main (argc=1, argv=0xbb74) at ../src/main.C:40

Re: Bug in CVS

[Andre Poenitz]

 #3  0x815ec58 in lyx::abort () at abort.C:9
 #4  0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
 ^ This causes
   the crash

If lyxstring really mimics std::string, the assert is correct: You should
never call a string's constructor on a NULL pointer.  I think until a day
or two ago lyxstring behaved wrong by quietly accepting the NULL pointer
and creating an empty string.

The actual problem is here:

 #5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224

This line should read:

  return browser ? fl_get_browser_line(browser, sel) : string();

instead of:

  return browser ? fl_get_browser_line(browser, sel) : 0;


Andre'

-- 
Andre' Poenitz  [EMAIL PROTECTED]

Bug in CVS

[Dekel Tsur]

When \kbmap is true, LyX crashes on startup. This bug is very recent (last day
or two).
The backtrace:

#0  0x401e1a01 in kill ()
#1  0x401e1863 in gsignal ()
#2  0x401e28c5 in abort ()
#3  0x815ec58 in lyx::abort () at abort.C:9
#4  0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
^ This causes
  the crash
#5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224
#6  0x8088e5e in Intl::Keymap (this=0x81fb8a0, code=23) at intl.C:339
#7  0x8088cf3 in Intl::InitKeyMapper (this=0x81fb8a0, on=true) at intl.C:308
#8  0x80640bf in LyXView::init (this=0x81f3080) at LyXView.C:326
#9  0x8095aa1 in LyXGUI::init (this=0x81d3e40) at lyx_gui.C:251
#10 0x80971c6 in LyX::LyX (this=0xbb40, argc=0xbb60, argv=0xbb74)
at ../src/lyx_main.C:105
#11 0x80b5fd6 in main (argc=1, argv=0xbb74) at ../src/main.C:40

Re: Bug in CVS

[Andre Poenitz]

> #3  0x815ec58 in lyx::abort () at abort.C:9
> #4  0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24
> ^ This causes
>   the crash

If lyxstring really mimics std::string, the assert is correct: You should
never call a string's constructor on a NULL pointer.  I think until a day
or two ago lyxstring behaved wrong by quietly accepting the NULL pointer
and creating an empty string.

The actual problem is here:

> #5  0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224

This line should read:

  return browser ? fl_get_browser_line(browser, sel) : string();

instead of:

  return browser ? fl_get_browser_line(browser, sel) : 0;


Andre'

-- 
Andre' Poenitz  [EMAIL PROTECTED]

Re: Bug in CVS 18/05/00 #4

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of them again (reloaded).

Is this repeatable?
And this is the the cvs version, right?

|   FMR: Free memory read
|   This is occurring while in:
| bool text_fits::operator()(LyXText*)
| [QCfYDL9Ishn54ITXVBUe.o]
| __type_0
| std::find_ifLyXText**,text_fits(__type_0,__type_0,__type_1)
| [algorithm]

The only reason why this should happen is if there is a text* in the
TextCache that is not supposed to be there. (it would point into the
void), for the revert/reload I can't see how this can happen,
BufferStorage::release should take care of it.

What platform was this on?
Can this be a platform issue?

Jean-Marc, can you see this when you run purify?

Lgb

Re: Bug in CVS 18/05/00 #5

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

| Hi,
| 
| yet another bug report. 

Can you have a look at this Jürgen?

Lgb

Re: Bug in CVS 18/05/00 #6

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

|   UMR: Uninitialized memory read (2 times)
|   This is occurring while in:
| bool MathedXIter::Next() [math_iter.C:632]

Ok, should be fixed now.

Lgb

Re: Bug in CVS 18/05/00 #2.2

[Lars Gullik Bjønnes]

Michael Schmitt [EMAIL PROTECTED] writes:

| I got another warning when clicking at the end of the loaded document:
| 
|   UMR: Uninitialized memory read
|   This is occurring while in:
| int
| WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
| [WorkArea.C:299]

Hmm, this is either the X lib or XForms not initializing one or more
variables in the event struct. Strange.

Lgb
| ==

Re: Bug in CVS 18/05/00 #4

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| I opened a couple of files (it seems like two are not sufficient), made
| _no_ changes, then opened one of them again (reloaded).

Is this repeatable?
And this is the the cvs version, right?

|   FMR: Free memory read
|   This is occurring while in:
| bool text_fits::operator()(LyXText*&)
| [QCfYDL9Ishn54ITXVBUe.o]
| __type_0
| std::find_if(__type_0,__type_0,__type_1)
| [algorithm]

The only reason why this should happen is if there is a text* in the
TextCache that is not supposed to be there. (it would point into the
void), for the revert/reload I can't see how this can happen,
BufferStorage::release should take care of it.

What platform was this on?
Can this be a platform issue?

Jean-Marc, can you see this when you run purify?

Lgb

Re: Bug in CVS 18/05/00 #5

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| Hi,
| 
| yet another bug report. 

Can you have a look at this Jürgen?

Lgb

Re: Bug in CVS 18/05/00 #6

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

|   UMR: Uninitialized memory read (2 times)
|   This is occurring while in:
| bool MathedXIter::Next() [math_iter.C:632]

Ok, should be fixed now.

Lgb

Re: Bug in CVS 18/05/00 #2.2

[Lars Gullik Bjønnes]

Michael Schmitt <[EMAIL PROTECTED]> writes:

| I got another warning when clicking at the end of the loaded document:
| 
|   UMR: Uninitialized memory read
|   This is occurring while in:
| int
| WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
| [WorkArea.C:299]

Hmm, this is either the X lib or XForms not initializing one or more
variables in the event struct. Strange.

Lgb
| ==

Bug in CVS 18/05/00 #1

[Michael Schmitt]

Hi,

despite the most recent fixes there is still a problem with cutting a
region covering two paragraphs:

  FMR: Free memory read
  This is occurring while in:
LyXParagraph*LyXParagraph::Next() [paragraph.C:1197]
void LyXText::CutSelection(bool) [text2.C:2227]
void BufferView::cut() [BufferView2.C:587]
   
std::basic_stringchar,std::char_traitschar,std::allocatorchar
LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main   [main.C:75]
_start [crt1.o]
  Reading 4 bytes from 0xcfc97c in the heap.
  Address 0xcfc97c is 196 bytes into a freed  block at 0xcfc8b8 of
260 bytes.
  This block was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv_ [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
void LyXParagraph::BreakParagraphConservative(int)
[paragraph.C:1570]
bool
CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int,char,bool)
[CutAndPaste.C:96]
void LyXText::CutSelection(bool) [text2.C:2221]
void BufferView::cut() [BufferView2.C:587]
   
std::basic_stringchar,std::char_traitschar,std::allocatorchar
LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main   [main.C:75]
_start [crt1.o]
  There have been 0 frees since this block was freed from:
free   [rtlib.o]
c2k6FPv_v_ [libCrun.so.1]
void operator delete(void*) [rtlib.o]
void LyXParagraph::PasteParagraph() [paragraph.C:1624]
bool
CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int,char,bool)
[CutAndPaste.C:129]
void LyXText::CutSelection(bool) [text2.C:2221]
void BufferView::cut() [BufferView2.C:587]
   
std::basic_stringchar,std::char_traitschar,std::allocatorchar
LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main   [main.C:75]
_start [crt1.o]
  FMR: Free memory read
  This is occurring while in:
LyXParagraph*LyXParagraph::Next() [paragraph.C:1209]
void LyXText::CutSelection(bool) [text2.C:2227]
void BufferView::cut() [BufferView2.C:587]
   
std::basic_stringchar,std::char_traitschar,std::allocatorchar
LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main   [main.C:75]
_start [crt1.o]
  Reading 4 bytes from 0xcfc97c in the heap.
  Address 0xcfc97c is 196 bytes into a freed  block at 0xcfc8b8 of
260 bytes.
  This block was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv_ [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
void LyXParagraph::BreakParagraphConservative(int)
[paragraph.C:1570]
bool
CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int,char,bool)
[CutAndPaste.C:96]
void LyXText::CutSelection(bool) [text2.C:2221]
void BufferView::cut() [BufferView2.C:587]
   
std::basic_stringchar,std::char_traitschar,std::allocatorchar

Bug in CVS 18/05/00 #2

[Michael Schmitt]

Hi,

importing the ascii file README (from lyx) results in the following
message:

  UMR: Uninitialized memory read
  This is occurring while in:
void LyXText::SetSelection() [text2.C:1024]
int BufferView::Pimpl::resizeCurrentBuffer()
[BufferView_pimpl.C:260]
void BufferView::Pimpl::resize() [BufferView_pimpl.C:173]
void BufferView::resize() [BufferView.C:78]
void Buffer::resize() [bufferlist.o]
void BufferList::resize() [bufferlist.C:147]
void BufferView::Pimpl::workAreaExpose()
[BufferView_pimpl.C:987]
void BufferView::workAreaExpose() [BufferView.C:187]
int
WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
[WorkArea.C:284]
C_WorkArea_work_area_handler [WorkArea.C:48]
fl_handle_it   [libforms.a]
fl_handle_object [libforms.a]
redraw_marked  [libforms.a]
fl_handle_form [libforms.a]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main   [main.C:75]
_start [crt1.o]
  Reading 4 bytes from 0xa8f128 in the heap.
  Address 0xa8f128 is 240 bytes into a malloc'd block at 0xa8f038 of
376 bytes.
  This block was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv_ [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
int BufferView::Pimpl::resizeCurrentBuffer()
[BufferView_pimpl.C:231]
void BufferView::Pimpl::resize() [BufferView_pimpl.C:173]
void BufferView::resize() [BufferView.C:78]
void Buffer::resize() [bufferlist.o]
void BufferList::resize() [bufferlist.C:147]
void BufferView::Pimpl::workAreaExpose()
[BufferView_pimpl.C:987]
void BufferView::workAreaExpose() [BufferView.C:187]
int
WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*)
[WorkArea.C:284]
C_WorkArea_work_area_handler [WorkArea.C:48]
fl_handle_it   [libforms.a]
fl_handle_object [libforms.a]
redraw_marked  [libforms.a]
fl_handle_form [libforms.a]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main   [main.C:75]
_start [crt1.o]

-- 
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics   secretary: +49 451 500 3721
Medical University of Luebeck  fax:   +49 451 500 3722
Ratzeburger Allee 160  eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany   WWW:   http://www.itm.mu-luebeck.de
==