subject:"CVS Update\: lyx\-devel"

RE: CVS Update: lyx-devel

2002-02-28 Thread Juergen Vigna



On 28-Feb-2002 lasgouttes wrote:

 Log message:
   ding-dong, the witch is dead!, says John

Well I now get a segfault every time I load the UserGuide! Not a real
improvement. And why didn't you wait for Friday to commit this one?

 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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

C++ is the best example of second-system effect since OS/360.

RE: CVS Update: lyx-devel

2002-02-28 Thread Juergen Vigna



On 28-Feb-2002 Juergen Vigna wrote:

 Well I now get a segfault every time I load the UserGuide! Not a real
 improvement. And why didn't you wait for Friday to commit this one?

Sorry you should have sent this tomorrow it was obviously a problem
with MY three, so now today you have to add smilies to your reply #:O)

 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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

What happened last night can happen again.

RE: CVS Update: lyx-devel

2002-02-28 Thread Juergen Vigna

On 28-Feb-2002 lasgouttes wrote:

> Log message:
>   "ding-dong, the witch is dead!", says John

Well I now get a segfault every time I load the UserGuide! Not a real
improvement. And why didn't you wait for Friday to commit this one?

 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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

C++ is the best example of second-system effect since OS/360.

RE: CVS Update: lyx-devel

2002-02-28 Thread Juergen Vigna



On 28-Feb-2002 Juergen Vigna wrote:

> Well I now get a segfault every time I load the UserGuide! Not a real
> improvement. And why didn't you wait for Friday to commit this one?

Sorry you should have sent this tomorrow it was obviously a problem
with MY three, so now today you have to add smilies to your reply #:O)

 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
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

What happened last night can happen again.

Re: CVS Update: lyx-devel

2002-02-20 Thread Angus Leeming


On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote:
 CVSROOT:  /usr/local/lyx/cvsroot
 Module name:  lyx-devel
 Repository:   lyx-devel/src/frontends/
 Changes by:   [EMAIL PROTECTED]  02/02/19 20:45:53
 
 Modified files:
   lyx-devel/src/frontends/: Makefile.am 
 
 Log message:
   better dep tracking

I take it there was something wrong after all?

Anyway, things still aren't right. Try changing something in the xforms 
directory. The file is remade, the lib is remade, but thereafter neither the 
frontends lib not lyx itself are linked in.

Regards,
Angus

Making all in xforms
make[4]: Entering directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms'
deccxx -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images 
-I../../../src/-I../../../src/frontends/
-I../../../src/frontends/controllers-I../../.. -I../../.. 
-I../../../boost  -I../../../src/cheaders  -I/usr/local/include
  -msg_display_number -msg_disable 11,193,236,261,401,611 -w0 -ptr 
/usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -c FormForks.C

cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I../../../src 
-I../../../images -I../../../src/ -I../../../src/frontends/ 
-I../../../src/frontends/controllers -I../../.. -I../../.. -I../../../boost 
-I../../../src/cheaders -I/usr/local/include -msg_display_number -msg_disable 
11,193,236,261,401,611 -w0 -ptr 
/usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -MD -c 
FormForks.C
cxx: Warning: /usr/include/cxx/algorithm.cc, line 110: #1115-D external 
routine
  uses unnamed type or namespace.
InputIterator find_if (InputIterator first, InputIterator last, Predicate 
pred)
--^
rm -f ../libxforms.objects.new
for fil in Alert_pimpl.o bmtable.o Color.o combox.o Dialogs.o DropDown.o 
FileDialog.o FormFiledialog.o form_filedialog.o GUIRunTime.o FormAboutlyx.o 
form_aboutlyx.o FormBase.o FormBaseDeprecated.o FormBibitem.o form_bibitem.o 
FormBibtex.o form_bibtex.o FormBrowser.o form_browser.o FormCharacter.o 
form_character.o FormCitation.o form_citation.o FormDocument.o 
form_document.o FormError.o form_error.o FormERT.o form_ert.o FormExternal.o 
form_external.o FormFloat.o form_float.o FormForks.o form_forks.o 
FormGraphics.o form_graphics.o FormInclude.o form_include.o FormIndex.o 
form_index.o FormInset.o FormLog.o FormMathsBitmap.o FormMathsDeco.o 
form_maths_deco.o FormMathsDelim.o form_maths_delim.o FormMathsMatrix.o 
form_maths_matrix.o FormMathsPanel.o form_maths_panel.o FormMathsSpace.o 
form_maths_space.o FormMathsStyle.o form_maths_style.o FormMinipage.o 
form_minipage.o FormParagraph.o form_paragraph.o FormPreamble.o 
form_preamble.o FormPreferences.o form_preferences.o FormPrint.o form_print.o 
FormRef.o form_ref.o FormSearch.o form_search.o FormShowFile.o 
FormSpellchecker.o form_spellchecker.o FormTabular.o form_tabular.o 
FormTabularCreate.o form_tabular_create.o FormTexinfo.o form_texinfo.o 
FormThesaurus.o form_thesaurus.o FormToc.o form_toc.o FormUrl.o form_url.o 
FormVCLog.o input_validators.o MathsSymbols.o Menubar_pimpl.o 
RadioButtonGroup.o
Timeout_pimpl.o Toolbar_pimpl.o Tooltips.o xforms_helpers.o xformsBC.o ; do \
echo xforms/$fil  ../libxforms.objects.new ; \
done
if [ -f ../libxforms.objects ] ; then \
cmp -s ../libxforms.objects ../libxforms.objects.new || mv 
../libxforms.objects.new ../libxforms.objects ; \
else \
mv ../libxforms.objects.new ../libxforms.objects ; \
fi
make[4]: Leaving directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms'
make[4]: Entering directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends'
make[3]: Leaving directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends'
make[3]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
Making all in lib
make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
Making all in reLyX
make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX'
make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel'
aleem@pneumon:devel-

Re: CVS Update: lyx-devel

2002-02-20 Thread Angus Leeming


On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote:
 | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote:
  CVSROOT:   /usr/local/lyx/cvsroot
  Module name:   lyx-devel
  Repository:lyx-devel/src/frontends/
  Changes by:[EMAIL PROTECTED]  02/02/19 20:45:53
  
  Modified files:
 lyx-devel/src/frontends/: Makefile.am 
  
  Log message:
 better dep tracking
 
 | I take it there was something wrong after all?
 
 | Anyway, things still aren't right. Try changing something in the xforms 
 | directory. The file is remade, the lib is remade, but thereafter neither 
the 
 | frontends lib not lyx itself are linked in.
 
 Can you try this patch?
 You have to be in src/frontends when patching

So you're basically reverting the changes you made to Makefile.ams in the 
frontends?

Yes, this appears to work.

Angus

Re: CVS Update: lyx-devel

2002-02-20 Thread Angus Leeming


On Wednesday 20 February 2002 12:18 pm, Lars Gullik Bjønnes wrote:
 Angus Leeming [EMAIL PROTECTED] writes:
 
 | On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote:
  | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote:
   CVSROOT:/usr/local/lyx/cvsroot
   Module name:lyx-devel
   Repository: lyx-devel/src/frontends/
   Changes by: [EMAIL PROTECTED]  02/02/19 20:45:53
   
   Modified files:
   lyx-devel/src/frontends/: Makefile.am 
   
   Log message:
   better dep tracking
  
  | I take it there was something wrong after all?
  
  | Anyway, things still aren't right. Try changing something in the 
xforms 
  | directory. The file is remade, the lib is remade, but thereafter 
neither 
 | the 
  | frontends lib not lyx itself are linked in.
  
  Can you try this patch?
  You have to be in src/frontends when patching
 
 | So you're basically reverting the changes you made to Makefile.ams in the 
 | frontends?
 
 No, not quite. Simplifying is a better word.
 
 | Yes, this appears to work.
 
 also the dependency tracking?

Seems to. I'll keep an eye out for things going wrong.

Needless to say, you're a b-tard for making me rebuild practically the whole 
tree for the Xth time in a week! ;-)

Angus

Re: CVS Update: lyx-devel

2002-02-20 Thread Angus Leeming


On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote:
> CVSROOT:  /usr/local/lyx/cvsroot
> Module name:  lyx-devel
> Repository:   lyx-devel/src/frontends/
> Changes by:   [EMAIL PROTECTED]  02/02/19 20:45:53
> 
> Modified files:
>   lyx-devel/src/frontends/: Makefile.am 
> 
> Log message:
>   better dep tracking

I take it there was something wrong after all?

Anyway, things still aren't right. Try changing something in the xforms 
directory. The file is remade, the lib is remade, but thereafter neither the 
frontends lib not lyx itself are linked in.

Regards,
Angus

Making all in xforms
make[4]: Entering directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms'
deccxx -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images 
-I../../../src/-I../../../src/frontends/
-I../../../src/frontends/controllers-I../../.. -I../../.. 
-I../../../boost  -I../../../src/cheaders  -I/usr/local/include
  -msg_display_number -msg_disable 11,193,236,261,401,611 -w0 -ptr 
/usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -c FormForks.C

cxx -std strict_ansi -nocleanup -DHAVE_CONFIG_H -I. -I. -I../../../src 
-I../../../images -I../../../src/ -I../../../src/frontends/ 
-I../../../src/frontends/controllers -I../../.. -I../../.. -I../../../boost 
-I../../../src/cheaders -I/usr/local/include -msg_display_number -msg_disable 
11,193,236,261,401,611 -w0 -ptr 
/usr/users/aleem/OTHERS_CODE/lyx/devel/lyx_cxx_repository -O2 -MD -c 
FormForks.C
cxx: Warning: /usr/include/cxx/algorithm.cc, line 110: #1115-D external 
routine
  uses unnamed type or namespace.
InputIterator find_if (InputIterator first, InputIterator last, Predicate 
pred)
--^
rm -f ../libxforms.objects.new
for fil in Alert_pimpl.o bmtable.o Color.o combox.o Dialogs.o DropDown.o 
FileDialog.o FormFiledialog.o form_filedialog.o GUIRunTime.o FormAboutlyx.o 
form_aboutlyx.o FormBase.o FormBaseDeprecated.o FormBibitem.o form_bibitem.o 
FormBibtex.o form_bibtex.o FormBrowser.o form_browser.o FormCharacter.o 
form_character.o FormCitation.o form_citation.o FormDocument.o 
form_document.o FormError.o form_error.o FormERT.o form_ert.o FormExternal.o 
form_external.o FormFloat.o form_float.o FormForks.o form_forks.o 
FormGraphics.o form_graphics.o FormInclude.o form_include.o FormIndex.o 
form_index.o FormInset.o FormLog.o FormMathsBitmap.o FormMathsDeco.o 
form_maths_deco.o FormMathsDelim.o form_maths_delim.o FormMathsMatrix.o 
form_maths_matrix.o FormMathsPanel.o form_maths_panel.o FormMathsSpace.o 
form_maths_space.o FormMathsStyle.o form_maths_style.o FormMinipage.o 
form_minipage.o FormParagraph.o form_paragraph.o FormPreamble.o 
form_preamble.o FormPreferences.o form_preferences.o FormPrint.o form_print.o 
FormRef.o form_ref.o FormSearch.o form_search.o FormShowFile.o 
FormSpellchecker.o form_spellchecker.o FormTabular.o form_tabular.o 
FormTabularCreate.o form_tabular_create.o FormTexinfo.o form_texinfo.o 
FormThesaurus.o form_thesaurus.o FormToc.o form_toc.o FormUrl.o form_url.o 
FormVCLog.o input_validators.o MathsSymbols.o Menubar_pimpl.o 
RadioButtonGroup.o
Timeout_pimpl.o Toolbar_pimpl.o Tooltips.o xforms_helpers.o xformsBC.o ; do \
echo xforms/$fil >> ../libxforms.objects.new ; \
done
if [ -f ../libxforms.objects ] ; then \
cmp -s ../libxforms.objects ../libxforms.objects.new || mv 
../libxforms.objects.new ../libxforms.objects ; \
else \
mv ../libxforms.objects.new ../libxforms.objects ; \
fi
make[4]: Leaving directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends/xforms'
make[4]: Entering directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends'
make[3]: Leaving directory 
`/usr/users/aleem/OTHERS_CODE/lyx/devel/src/frontends'
make[3]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/src'
Making all in lib
make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
Making all in reLyX
make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib/reLyX'
make[2]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel/lib'
make[1]: Entering directory `/usr/users/aleem/OTHERS_CODE/lyx/devel'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/usr/users/aleem/OTHERS_CODE/lyx/devel'
aleem@pneumon:devel->

Re: CVS Update: lyx-devel

2002-02-20 Thread Angus Leeming


On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote:
> | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote:
> >> CVSROOT:   /usr/local/lyx/cvsroot
> >> Module name:   lyx-devel
> >> Repository:lyx-devel/src/frontends/
> >> Changes by:[EMAIL PROTECTED]  02/02/19 20:45:53
> >> 
> >> Modified files:
> >>lyx-devel/src/frontends/: Makefile.am 
> >> 
> >> Log message:
> >>better dep tracking
> >
> | I take it there was something wrong after all?
> >
> | Anyway, things still aren't right. Try changing something in the xforms 
> | directory. The file is remade, the lib is remade, but thereafter neither 
the 
> | frontends lib not lyx itself are linked in.
> 
> Can you try this patch?
> You have to be in src/frontends when patching

So you're basically reverting the changes you made to Makefile.ams in the 
frontends?

Yes, this appears to work.

Angus

Re: CVS Update: lyx-devel

2002-02-20 Thread Angus Leeming


On Wednesday 20 February 2002 12:18 pm, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> | On Wednesday 20 February 2002 11:25 am, Lars Gullik Bjønnes wrote:
> >> | On Tuesday 19 February 2002 8:45 pm, [EMAIL PROTECTED] wrote:
> >> >> CVSROOT:/usr/local/lyx/cvsroot
> >> >> Module name:lyx-devel
> >> >> Repository: lyx-devel/src/frontends/
> >> >> Changes by: [EMAIL PROTECTED]  02/02/19 20:45:53
> >> >> 
> >> >> Modified files:
> >> >> lyx-devel/src/frontends/: Makefile.am 
> >> >> 
> >> >> Log message:
> >> >> better dep tracking
> >> >
> >> | I take it there was something wrong after all?
> >> >
> >> | Anyway, things still aren't right. Try changing something in the 
xforms 
> >> | directory. The file is remade, the lib is remade, but thereafter 
neither 
> | the 
> >> | frontends lib not lyx itself are linked in.
> >> 
> >> Can you try this patch?
> >> You have to be in src/frontends when patching
> >
> | So you're basically reverting the changes you made to Makefile.ams in the 
> | frontends?
> 
> No, not quite. Simplifying is a better word.
> 
> | Yes, this appears to work.
> 
> also the dependency tracking?

Seems to. I'll keep an eye out for things going wrong.

Needless to say, you're a b-tard for making me rebuild practically the whole 
tree for the Xth time in a week! ;-)

Angus

Re: CVS Update: lyx-devel - compile error

2002-02-16 Thread Herbert Voss


[EMAIL PROTECTED] wrote:

  CVSROOT: /usr/local/lyx/cvsroot
  Module name: lyx-devel
  Repository:  lyx-devel/src/support/
  Changes by:  [EMAIL PROTECTED]  02/02/16 16:59:55




After cvs update:
---
Configuration
   Host type:  i686-pc-linux-gnu
   Special build flags:warnings assertions included-libsigc
   C   Compiler:   gcc
   C   Compiler flags: -g -O2
   C++ Compiler:   g++ (2.95.3)
   C++ Compiler flags: -g -O -fno-exceptions -W -Wall
   Linker flags:
   Frontend:   xforms
 libXpm version:   4.11
 libforms version: 0.89.6
   LyX binary dir: /usr/local/bin
   LyX files dir:  /usr/local/share/lyx
-

[...]make  all-recursive
make[2]: Entering directory `/home/voss/lyx-devel.orig/src'
Making all in mathed
make[3]: Entering directory `/home/voss/lyx-devel.orig/src/mathed'
cd ../..  automake --foreign src/mathed/Makefile
automake: src/mathed/Makefile.am: `libmathed.o' is not a standard 
libtool library name
make[3]: *** [Makefile.in] Error 1

[...]



HErbert



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

Re: CVS Update: lyx-devel - compile error

2002-02-16 Thread Herbert Voss


Herbert Voss wrote:

 [...]make  all-recursive
 make[2]: Entering directory `/home/voss/lyx-devel.orig/src'
 Making all in mathed
 make[3]: Entering directory `/home/voss/lyx-devel.orig/src/mathed'
 cd ../..  automake --foreign src/mathed/Makefile
 automake: src/mathed/Makefile.am: `libmathed.o' is not a standard 
 libtool library name
 make[3]: *** [Makefile.in] Error 1


ok, got it ...

Herbert

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

Re: CVS Update: lyx-devel

2002-02-16 Thread John Levon


On Sat, Feb 16, 2002 at 05:12:26PM +0100, Lars Gullik Bjønnes wrote:

 - qt2 and gnome should not depend on the live xforms code, but rather
   take a snapshot to be kept in their own dirs.

what do you mean ? cvs add ? /bin/cp ?

regards
john

-- 
I'd rather be rudely informed than politely left in the dark.

Re: CVS Update: lyx-devel - compile error

2002-02-16 Thread Herbert Voss

[EMAIL PROTECTED] wrote:

 > CVSROOT: /usr/local/lyx/cvsroot
 > Module name: lyx-devel
 > Repository:  lyx-devel/src/support/
 > Changes by:  [EMAIL PROTECTED]  02/02/16 16:59:55

After cvs update:
---
Configuration
   Host type:  i686-pc-linux-gnu
   Special build flags:warnings assertions included-libsigc
   C   Compiler:   gcc
   C   Compiler flags: -g -O2
   C++ Compiler:   g++ (2.95.3)
   C++ Compiler flags: -g -O -fno-exceptions -W -Wall
   Linker flags:
   Frontend:   xforms
 libXpm version:   4.11
 libforms version: 0.89.6
   LyX binary dir: /usr/local/bin
   LyX files dir:  /usr/local/share/lyx
-

[...]make  all-recursive
make[2]: Entering directory `/home/voss/lyx-devel.orig/src'
Making all in mathed
make[3]: Entering directory `/home/voss/lyx-devel.orig/src/mathed'
cd ../.. && automake --foreign src/mathed/Makefile
automake: src/mathed/Makefile.am: `libmathed.o' is not a standard 
libtool library name
make[3]: *** [Makefile.in] Error 1

[...]

HErbert

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

Re: CVS Update: lyx-devel - compile error

2002-02-16 Thread Herbert Voss


Herbert Voss wrote:

> [...]make  all-recursive
> make[2]: Entering directory `/home/voss/lyx-devel.orig/src'
> Making all in mathed
> make[3]: Entering directory `/home/voss/lyx-devel.orig/src/mathed'
> cd ../.. && automake --foreign src/mathed/Makefile
> automake: src/mathed/Makefile.am: `libmathed.o' is not a standard 
> libtool library name
> make[3]: *** [Makefile.in] Error 1


ok, got it ...

Herbert

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

Re: CVS Update: lyx-devel

2002-02-16 Thread John Levon


On Sat, Feb 16, 2002 at 05:12:26PM +0100, Lars Gullik Bjønnes wrote:

> - qt2 and gnome should not depend on the live xforms code, but rather
>   take a snapshot to be kept in their own dirs.

what do you mean ? cvs add ? /bin/cp ?

regards
john

-- 
"I'd rather be rudely informed than politely left in the dark."

Re: CVS Update: lyx-devel

2002-02-12 Thread Andre Poenitz


On Tue, Feb 12, 2002 at 01:56:47PM +, [EMAIL PROTECTED] wrote:
 Log message:
   make inset-toggle work when cursor is inside inset

Thanks.

Now the redraw problem  really shines ;-}

Andre'

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

Re: CVS Update: lyx-devel

2002-02-12 Thread Jean-Marc Lasgouttes


 Andre == Andre Poenitz [EMAIL PROTECTED] writes:

Andre On Tue, Feb 12, 2002 at 01:56:47PM +, [EMAIL PROTECTED]
Andre wrote:
 Log message: make inset-toggle work when cursor is inside inset

Andre Thanks.

Andre Now the redraw problem really shines ;-}

I have to admit that I did all my testing with footnote :)

JMarc

Re: CVS Update: lyx-devel

2002-02-12 Thread Andre Poenitz


On Tue, Feb 12, 2002 at 01:56:47PM +, [EMAIL PROTECTED] wrote:
> Log message:
>   make inset-toggle work when cursor is inside inset

Thanks.

Now the redraw problem  really shines ;-}

Andre'

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

Re: CVS Update: lyx-devel

2002-02-12 Thread Jean-Marc Lasgouttes


> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> On Tue, Feb 12, 2002 at 01:56:47PM +, [EMAIL PROTECTED]
Andre> wrote:
>> Log message: make inset-toggle work when cursor is inside inset

Andre> Thanks.

Andre> Now the redraw problem really shines ;-}

I have to admit that I did all my testing with footnote :)

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


[EMAIL PROTECTED] wrote:

   his one-line fix to updateWidgetsFromLengthString,


it maybe not important, but I suppose that the unit %

will be misleading to a lot of users. Shouldn't we
better delete this one? Otherwise we always have the
questions: 100% of what?


Herbert


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

Re: CVS Update: lyx-devel

2002-02-04 Thread Juergen Spitzmueller


Herbert Voss wrote:
 [EMAIL PROTECTED] wrote:
  his one-line fix to updateWidgetsFromLengthString,

 it maybe not important, but I suppose that the unit %

 will be misleading to a lot of users. Shouldn't we
 better delete this one? Otherwise we always have the
 questions: 100% of what?

Agreed. 100p% and 100c% are sufficiant.
But note if you delete it that Minipage is currently set to 100% as 
default. Should be changed to 100p% (c% ?) instead then.

Juergen.

 Herbert

Re: CVS Update: lyx-devel

2002-02-04 Thread Angus Leeming


On Monday 04 February 2002 3:42 pm, Herbert Voss wrote:
 [EMAIL PROTECTED] wrote:
 
  his one-line fix to updateWidgetsFromLengthString,
 
 
 it maybe not important, but I suppose that the unit %
 will be misleading to a lot of users. Shouldn't we
 better delete this one? Otherwise we always have the
 questions: 100% of what?

Here's what I think about it:

updateWidgetsFromLengthString was really meant to interact with LyXString I 
guess. If '%' makes no sense to a LyXString, then '%' should go. Otherwise, 
we can just explain to some pedantic user that all is oK.

I've already forgotten why the '%' was needed, having read that mail more 
than 1 hour ago ;-). 

Angus

Re: CVS Update: lyx-devel

2002-02-04 Thread Angus Leeming


On Monday 04 February 2002 3:51 pm, Juergen Spitzmueller wrote:
 Herbert Voss wrote:
  [EMAIL PROTECTED] wrote:
 his one-line fix to updateWidgetsFromLengthString,
 
  it maybe not important, but I suppose that the unit %
 
  will be misleading to a lot of users. Shouldn't we
  better delete this one? Otherwise we always have the
  questions: 100% of what?
 
 Agreed. 100p% and 100c% are sufficiant.
 But note if you delete it that Minipage is currently set to 100% as 
 default. Should be changed to 100p% (c% ?) instead then.

If this is what 100% really means, then YES.
A

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


Juergen Spitzmueller wrote:

 Herbert Voss wrote:
 
[EMAIL PROTECTED] wrote:

 his one-line fix to updateWidgetsFromLengthString,

it maybe not important, but I suppose that the unit %

will be misleading to a lot of users. Shouldn't we
better delete this one? Otherwise we always have the
questions: 100% of what?

 
 Agreed. 100p% and 100c% are sufficiant.
 But note if you delete it that Minipage is currently set to 100% as 
 default. Should be changed to 100p% (c% ?) instead then.


always c%, because there are only some few cases

where p% makes sense, from my point as a lyx-user.
The only unit, which makes sense in different to
c% is t(extwidth)%, when in twocolumnmode.


Herbert


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

Re: CVS Update: lyx-devel

2002-02-04 Thread Jean-Marc Lasgouttes


 Herbert == Herbert Voss [EMAIL PROTECTED] writes:

Herbert [EMAIL PROTECTED] wrote:
 his one-line fix to updateWidgetsFromLengthString,


Herbert it maybe not important, but I suppose that the unit %

Herbert will be misleading to a lot of users. Shouldn't we better
Herbert delete this one? Otherwise we always have the questions: 100%
Herbert of what?

This reminds me of a question I had when working on those lyxlength
recently:

The latex output for the different type of % gives:

switch(unit_) {
case PW:
case PE:
buffer  abs(static_castint(val_/100))  .
abs(static_castint(val_)%100)  \\columnwidth;
break;
case PP:
buffer  abs(static_castint(val_/100))  .
abs(static_castint(val_)%100)  \\paperwidth;
break;
case PL:
buffer  abs(static_castint(val_/100))  .
abs(static_castint(val_)%100)  \\linewidth;
break;

This means that we do not have anything which does % of \textwidth!
(\paperwidth was \pagewidth before, which does not exist).

I think that PW, which is I think related to % should have a 
case PW:
buffer  abs(static_castint(val_/100))  .
abs(static_castint(val_)%100)  \\textwidth;
break;

Thoughts?

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Jean-Marc Lasgouttes


 Herbert == Herbert Voss [EMAIL PROTECTED] writes:

Herbert always c%, because there are only some few cases
Herbert where p% makes sense, from my point as a lyx-user. The only
Herbert unit, which makes sense in different to c% is t(extwidth)%,
Herbert when in twocolumnmode.

Before reading the code (see my other message), I thought % was t%...

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


Jean-Marc Lasgouttes wrote:

 This means that we do not have anything which does % of \textwidth!
 (\paperwidth was \pagewidth before, which does not exist).
 
 I think that PW, which is I think related to % should have a 
   case PW:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\textwidth;
   break;
 
 Thoughts?


than let us do it in a consequently way:


PW - t% - \textwidth


Herbert



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

Re: CVS Update: lyx-devel

2002-02-04 Thread Angus Leeming


On Monday 04 February 2002 4:06 pm, Jean-Marc Lasgouttes wrote:
  Herbert == Herbert Voss [EMAIL PROTECTED] writes:
 
 Herbert [EMAIL PROTECTED] wrote:
  his one-line fix to updateWidgetsFromLengthString,
 
 
 Herbert it maybe not important, but I suppose that the unit %
 
 Herbert will be misleading to a lot of users. Shouldn't we better
 Herbert delete this one? Otherwise we always have the questions: 100%
 Herbert of what?
 
 This reminds me of a question I had when working on those lyxlength
 recently:
 
 The latex output for the different type of % gives:
 
   switch(unit_) {
   case PW:
   case PE:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\columnwidth;
   break;
   case PP:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\paperwidth;
   break;
   case PL:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\linewidth;
   break;
 
 This means that we do not have anything which does % of \textwidth!
 (\paperwidth was \pagewidth before, which does not exist).
 
 I think that PW, which is I think related to % should have a 
   case PW:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\textwidth;
   break;
 
 Thoughts?
 
 JMarc

Minor thought: why are you using static_castint(val_) instead of int(val_) 
since val_ is a double?

Re: CVS Update: lyx-devel

2002-02-04 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Minor thought: why are you using static_castint(val_) instead
Angus of int(val_) since val_ is a double?

Because Lars prefers that, I think.

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


[EMAIL PROTECTED] wrote:

 Log message:
   basic support for \xymatrix

what's this??

Herbert


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

Re: CVS Update: lyx-devel

2002-02-04 Thread Dekel Tsur


On Mon, Feb 04, 2002 at 07:44:51PM +, [EMAIL PROTECTED] wrote:
   basic support for \xymatrix

I'd rather see full support for AMS math, before supporting other packages.

Missing environments:
flalign,flalign*,gathered, aligned, alignedat

Some missing commands:
\intertext
\hdotsfor
\dddot, \ot
\overleftrightarrow,\underleftarrow,\underrightarrow,\underleftrightarrow,
\xleftarrow,\xrightarroow
\tag
\raisetag

Re: CVS Update: lyx-devel

2002-02-04 Thread Allan Rae


On 4 Feb 2002, Jean-Marc Lasgouttes wrote:

  Herbert == Herbert Voss [EMAIL PROTECTED] writes:

 Herbert [EMAIL PROTECTED] wrote:
  his one-line fix to updateWidgetsFromLengthString,


 Herbert it maybe not important, but I suppose that the unit %

 Herbert will be misleading to a lot of users. Shouldn't we better
 Herbert delete this one? Otherwise we always have the questions: 100%
 Herbert of what?

 This reminds me of a question I had when working on those lyxlength
 recently:

 The latex output for the different type of % gives:

   switch(unit_) {
   case PW:
   case PE:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\columnwidth;
   break;
   case PP:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\paperwidth;
   break;
   case PL:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\linewidth;
   break;

 This means that we do not have anything which does % of \textwidth!
 (\paperwidth was \pagewidth before, which does not exist).

 I think that PW, which is I think related to % should have a
   case PW:
   buffer  abs(static_castint(val_/100))  .
   abs(static_castint(val_)%100)  \\textwidth;
   break;

 Thoughts?


I have several 1.1.6 etc. files that have figures where I set the
height as a percentage.  When converted to 1.2.0cvs these are now
exported to latex as a % of \pagewidth. While in 1.1.6 they were
exported as a % of \textheight.

It would be very handy to have any height percentages be of heights
rather than widths.

Allan. (ARRae)

Re: CVS Update: lyx-devel

2002-02-04 Thread Andre Poenitz


On Mon, Feb 04, 2002 at 07:52:52PM +0100, Herbert Voss wrote:
  basic support for \xymatrix
 
 what's this??

Don't know. Ask Jules.

From mathed's technical point of view it is an array ;-)

Andre'

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

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


[EMAIL PROTECTED] wrote:

>   his one-line fix to updateWidgetsFromLengthString,


it maybe not important, but I suppose that the unit "%"

will be misleading to a lot of users. Shouldn't we
better delete this one? Otherwise we always have the
questions: 100% of what?


Herbert


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

Re: CVS Update: lyx-devel

2002-02-04 Thread Juergen Spitzmueller

Herbert Voss wrote:
> [EMAIL PROTECTED] wrote:
> > his one-line fix to updateWidgetsFromLengthString,
>
> it maybe not important, but I suppose that the unit "%"
>
> will be misleading to a lot of users. Shouldn't we
> better delete this one? Otherwise we always have the
> questions: 100% of what?

Agreed. 100p% and 100c% are sufficiant.
But note if you delete it that Minipage is currently set to 100% as 
default. Should be changed to 100p% (c% ?) instead then.

Juergen.

> Herbert

Re: CVS Update: lyx-devel

2002-02-04 Thread Angus Leeming

On Monday 04 February 2002 3:42 pm, Herbert Voss wrote:
> [EMAIL PROTECTED] wrote:
> 
> > his one-line fix to updateWidgetsFromLengthString,
> 
> 
> it maybe not important, but I suppose that the unit "%"
> will be misleading to a lot of users. Shouldn't we
> better delete this one? Otherwise we always have the
> questions: 100% of what?

Here's what I think about it:

updateWidgetsFromLengthString was really meant to interact with LyXString I 
guess. If '%' makes no sense to a LyXString, then '%' should go. Otherwise, 
we can just explain to some pedantic user that all is oK.

I've already forgotten why the '%' was needed, having read that mail more 
than 1 hour ago ;-). 

Angus

Re: CVS Update: lyx-devel

2002-02-04 Thread Angus Leeming


On Monday 04 February 2002 3:51 pm, Juergen Spitzmueller wrote:
> Herbert Voss wrote:
> > [EMAIL PROTECTED] wrote:
> > >   his one-line fix to updateWidgetsFromLengthString,
> >
> > it maybe not important, but I suppose that the unit "%"
> >
> > will be misleading to a lot of users. Shouldn't we
> > better delete this one? Otherwise we always have the
> > questions: 100% of what?
> 
> Agreed. 100p% and 100c% are sufficiant.
> But note if you delete it that Minipage is currently set to 100% as 
> default. Should be changed to 100p% (c% ?) instead then.

If this is what 100% really means, then YES.
A

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


Juergen Spitzmueller wrote:

> Herbert Voss wrote:
> 
>>[EMAIL PROTECTED] wrote:
>>
>>> his one-line fix to updateWidgetsFromLengthString,
>>>
>>it maybe not important, but I suppose that the unit "%"
>>
>>will be misleading to a lot of users. Shouldn't we
>>better delete this one? Otherwise we always have the
>>questions: 100% of what?
>>
> 
> Agreed. 100p% and 100c% are sufficiant.
> But note if you delete it that Minipage is currently set to 100% as 
> default. Should be changed to 100p% (c% ?) instead then.


always c%, because there are only some few cases

where p% makes sense, from my point as a lyx-user.
The only unit, which makes sense in different to
c% is t(extwidth)%, when in twocolumnmode.


Herbert


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

Re: CVS Update: lyx-devel

2002-02-04 Thread Jean-Marc Lasgouttes

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

Herbert> [EMAIL PROTECTED] wrote:
>> his one-line fix to updateWidgetsFromLengthString,

Herbert> it maybe not important, but I suppose that the unit "%"

Herbert> will be misleading to a lot of users. Shouldn't we better
Herbert> delete this one? Otherwise we always have the questions: 100%
Herbert> of what?

This reminds me of a question I had when working on those lyxlength
recently:

The latex output for the different type of % gives:

switch(unit_) {
case PW:
case PE:
buffer << abs(static_cast(val_/100)) << "."
   << abs(static_cast(val_)%100) << "\\columnwidth";
break;
case PP:
buffer << abs(static_cast(val_/100)) << "."
   << abs(static_cast(val_)%100) << "\\paperwidth";
break;
case PL:
buffer << abs(static_cast(val_/100)) << "."
   << abs(static_cast(val_)%100) << "\\linewidth";
break;

This means that we do not have anything which does % of \textwidth!
(\paperwidth was \pagewidth before, which does not exist).

I think that PW, which is I think related to "%" should have a 
case PW:
buffer << abs(static_cast(val_/100)) << "."
   << abs(static_cast(val_)%100) << "\\textwidth";
break;

Thoughts?

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Jean-Marc Lasgouttes


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

Herbert> always c%, because there are only some few cases
Herbert> where p% makes sense, from my point as a lyx-user. The only
Herbert> unit, which makes sense in different to c% is t(extwidth)%,
Herbert> when in twocolumnmode.

Before reading the code (see my other message), I thought % was t%...

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


Jean-Marc Lasgouttes wrote:

> This means that we do not have anything which does % of \textwidth!
> (\paperwidth was \pagewidth before, which does not exist).
> 
> I think that PW, which is I think related to "%" should have a 
>   case PW:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\textwidth";
>   break;
> 
> Thoughts?


than let us do it in a consequently way:


PW -> t% -> \textwidth


Herbert



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

Re: CVS Update: lyx-devel

2002-02-04 Thread Angus Leeming


On Monday 04 February 2002 4:06 pm, Jean-Marc Lasgouttes wrote:
> > "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
> 
> Herbert> [EMAIL PROTECTED] wrote:
> >> his one-line fix to updateWidgetsFromLengthString,
> 
> 
> Herbert> it maybe not important, but I suppose that the unit "%"
> 
> Herbert> will be misleading to a lot of users. Shouldn't we better
> Herbert> delete this one? Otherwise we always have the questions: 100%
> Herbert> of what?
> 
> This reminds me of a question I had when working on those lyxlength
> recently:
> 
> The latex output for the different type of % gives:
> 
>   switch(unit_) {
>   case PW:
>   case PE:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\columnwidth";
>   break;
>   case PP:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\paperwidth";
>   break;
>   case PL:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\linewidth";
>   break;
> 
> This means that we do not have anything which does % of \textwidth!
> (\paperwidth was \pagewidth before, which does not exist).
> 
> I think that PW, which is I think related to "%" should have a 
>   case PW:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\textwidth";
>   break;
> 
> Thoughts?
> 
> JMarc

Minor thought: why are you using static_cast(val_) instead of int(val_) 
since val_ is a double?

Re: CVS Update: lyx-devel

2002-02-04 Thread Jean-Marc Lasgouttes


> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Minor thought: why are you using static_cast(val_) instead
Angus> of int(val_) since val_ is a double?

Because Lars prefers that, I think.

JMarc

Re: CVS Update: lyx-devel

2002-02-04 Thread Herbert Voss


[EMAIL PROTECTED] wrote:

> Log message:
>   basic support for \xymatrix

what's this??

Herbert


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

Re: CVS Update: lyx-devel

2002-02-04 Thread Dekel Tsur


On Mon, Feb 04, 2002 at 07:44:51PM +, [EMAIL PROTECTED] wrote:
>   basic support for \xymatrix

I'd rather see full support for AMS math, before supporting other packages.

Missing environments:
flalign,flalign*,gathered, aligned, alignedat

Some missing commands:
\intertext
\hdotsfor
\dddot, \ot
\overleftrightarrow,\underleftarrow,\underrightarrow,\underleftrightarrow,
\xleftarrow,\xrightarroow
\tag
\raisetag

Re: CVS Update: lyx-devel

2002-02-04 Thread Allan Rae


On 4 Feb 2002, Jean-Marc Lasgouttes wrote:

> > "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>
> Herbert> [EMAIL PROTECTED] wrote:
> >> his one-line fix to updateWidgetsFromLengthString,
>
>
> Herbert> it maybe not important, but I suppose that the unit "%"
>
> Herbert> will be misleading to a lot of users. Shouldn't we better
> Herbert> delete this one? Otherwise we always have the questions: 100%
> Herbert> of what?
>
> This reminds me of a question I had when working on those lyxlength
> recently:
>
> The latex output for the different type of % gives:
>
>   switch(unit_) {
>   case PW:
>   case PE:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\columnwidth";
>   break;
>   case PP:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\paperwidth";
>   break;
>   case PL:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\linewidth";
>   break;
>
> This means that we do not have anything which does % of \textwidth!
> (\paperwidth was \pagewidth before, which does not exist).
>
> I think that PW, which is I think related to "%" should have a
>   case PW:
>   buffer << abs(static_cast(val_/100)) << "."
>  << abs(static_cast(val_)%100) << "\\textwidth";
>   break;
>
> Thoughts?


I have several 1.1.6 etc. files that have figures where I set the
height as a percentage.  When converted to 1.2.0cvs these are now
exported to latex as a % of \pagewidth. While in 1.1.6 they were
exported as a % of \textheight.

It would be very handy to have any height percentages be of heights
rather than widths.

Allan. (ARRae)

Re: CVS Update: lyx-devel

2002-02-04 Thread Andre Poenitz


On Mon, Feb 04, 2002 at 07:52:52PM +0100, Herbert Voss wrote:
> > basic support for \xymatrix
> 
> what's this??

Don't know. Ask Jules.

>From mathed's technical point of view it is an array ;-)

Andre'

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

Re: CVS Update: lyx-devel

2002-01-30 Thread Edwin Leuven


 Hummm, what do we want this for ?

viewing latex style files from the texinfo dialog?

 The Qt2 way is to use QWhatsThis.

but this is like a big tooltip right? not so suitable for viewing large files 
though...

you want it out?

Just getting rid of xforms cruft, Ed.

Re: CVS Update: lyx-devel

2002-01-30 Thread John Levon


On Wed, Jan 30, 2002 at 10:14:17AM +0100, Edwin Leuven wrote:

  Hummm, what do we want this for ?
 
 viewing latex style files from the texinfo dialog?

ah OK I thought it only got used for the short help files. My mistake.

regards
john

-- 
24-hour boredom
I'm convicted instantly
- Manic Street Preachers

Re: CVS Update: lyx-devel

2002-01-30 Thread Herbert Voss


it would be nice if you can commit my patch from yesterday
evening, too.

Herbert



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

Re: CVS Update: lyx-devel

2002-01-30 Thread Edwin Leuven


> Hummm, what do we want this for ?

viewing latex style files from the texinfo dialog?

> The Qt2 way is to use QWhatsThis.

but this is like a big tooltip right? not so suitable for viewing large files 
though...

you want it out?

Just getting rid of xforms cruft, Ed.

Re: CVS Update: lyx-devel

2002-01-30 Thread John Levon


On Wed, Jan 30, 2002 at 10:14:17AM +0100, Edwin Leuven wrote:

> > Hummm, what do we want this for ?
> 
> viewing latex style files from the texinfo dialog?

ah OK I thought it only got used for the short help files. My mistake.

regards
john

-- 
"24-hour boredom
I'm convicted instantly"
- Manic Street Preachers

Re: CVS Update: lyx-devel

2002-01-30 Thread Herbert Voss


it would be nice if you can commit my patch from yesterday
evening, too.

Herbert



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

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 12:01:45PM +, Angus Leeming wrote:

 On Tuesday 29 January 2002 10:21 am, Lars Gullik Bjønnes wrote:
  [EMAIL PROTECTED] writes:
  
  | Log message:
  |   Herbert's big graphics patch.
  
  So no the only missing part is async rendering?
 
 That and being able to set the size of the image on the LyX screen.

and rotation on screen. I'm not sure anyone cares about that though.

regards
john

-- 
In no sense is [in]stability a reason to move to a new version. It's never a
reason.
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 11:05:10AM +, [EMAIL PROTECTED] wrote:

   lyx-devel/src/frontends/qt2/: QShowFile.C QShowFile.h 

Hummm, what do we want this for ?

The Qt2 way is to use QWhatsThis.

regards
john

-- 
In no sense is [in]stability a reason to move to a new version. It's never a
reason.
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread Herbert Voss


John Levon wrote:

 On Tue, Jan 29, 2002 at 12:01:45PM +, Angus Leeming wrote:
 
 
On Tuesday 29 January 2002 10:21 am, Lars Gullik Bjønnes wrote:

[EMAIL PROTECTED] writes:

| Log message:
|Herbert's big graphics patch.

So no the only missing part is async rendering?

That and being able to set the size of the image on the LyX screen.

 
 and rotation on screen. I'm not sure anyone cares about that though.

but this is a new feature. Nice when there, but not important 

for 1.2.0


Herbert


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

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 08:12:48PM +0100, Herbert Voss wrote:

 and rotation on screen. I'm not sure anyone cares about that though.
 
 but this is a new feature.

er, no it's not. it's a regression against old-figure.

 Nice when there, but not important 

agreed

regards
john

-- 
In no sense is [in]stability a reason to move to a new version. It's never a
reason.
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 08:24:01PM +0100, Herbert Voss wrote:

 er, no it's not. it's a regression against old-figure.
 
 images were rotated on screen in which lyx-version

for as long as I've used lyx, up to present CVS

regards
john

-- 
In no sense is [in]stability a reason to move to a new version. It's never a
reason.
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 12:01:45PM +, Angus Leeming wrote:

> On Tuesday 29 January 2002 10:21 am, Lars Gullik Bjønnes wrote:
> > [EMAIL PROTECTED] writes:
> > 
> > | Log message:
> > |   Herbert's big graphics patch.
> > 
> > So no the only missing part is async rendering?
> 
> That and being able to set the size of the image on the LyX screen.

and rotation on screen. I'm not sure anyone cares about that though.

regards
john

-- 
"In no sense is [in]stability a reason to move to a new version. It's never a
reason."
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 11:05:10AM +, [EMAIL PROTECTED] wrote:

>   lyx-devel/src/frontends/qt2/: QShowFile.C QShowFile.h 

Hummm, what do we want this for ?

The Qt2 way is to use QWhatsThis.

regards
john

-- 
"In no sense is [in]stability a reason to move to a new version. It's never a
reason."
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread Herbert Voss


John Levon wrote:

> On Tue, Jan 29, 2002 at 12:01:45PM +, Angus Leeming wrote:
> 
> 
>>On Tuesday 29 January 2002 10:21 am, Lars Gullik Bjønnes wrote:
>>
>>>[EMAIL PROTECTED] writes:
>>>
>>>| Log message:
>>>|Herbert's big graphics patch.
>>>
>>>So no the only missing part is async rendering?
>>>
>>That and being able to set the size of the image on the LyX screen.
>>
> 
> and rotation on screen. I'm not sure anyone cares about that though.

but this is a new feature. Nice when there, but not important 

for 1.2.0


Herbert


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

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 08:12:48PM +0100, Herbert Voss wrote:

> >and rotation on screen. I'm not sure anyone cares about that though.
> 
> but this is a new feature.

er, no it's not. it's a regression against old-figure.

> Nice when there, but not important 

agreed

regards
john

-- 
"In no sense is [in]stability a reason to move to a new version. It's never a
reason."
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-29 Thread John Levon


On Tue, Jan 29, 2002 at 08:24:01PM +0100, Herbert Voss wrote:

> >er, no it's not. it's a regression against old-figure.
> 
> images were rotated on screen in which lyx-version

for as long as I've used lyx, up to present CVS

regards
john

-- 
"In no sense is [in]stability a reason to move to a new version. It's never a
reason."
- Bill Gates

Re: CVS Update: lyx-devel

2002-01-21 Thread Jean-Marc Lasgouttes


 Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Can someone show me the code that fails?

Lars A small example please, not the code from LyX.

I'm not sure Angus has found the exact case. 

JMarc

Re: CVS Update: lyx-devel

2002-01-21 Thread Jean-Marc Lasgouttes


> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Can someone show me the code that fails?

Lars> A small example please, not the code from LyX.

I'm not sure Angus has found the exact case. 

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Thursday 17 January 2002 5:20 pm, Jean-Marc Lasgouttes wrote:
  Dekel == Dekel Tsur [EMAIL PROTECTED] writes:
 
 Dekel On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
 Dekel wrote:
  Tidy up the file mathed.lyx. Still doesn't run without bolting the
  lyxcode definition in the preamble but is otherwise Ok I think.
 
 Dekel It does work for me. Can you trace the problem ? Does anyone
 Dekel else have this problem ?
 
 I would think it is due to his use of cxx stl library (either a bug in
 the library or in the way we use it).

This suggests that you have some idea where/how this bug is triggered? Care 
to through me some pointers?

Angus

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus On Thursday 17 January 2002 5:20 pm, Jean-Marc Lasgouttes
Angus wrote:
  Dekel == Dekel Tsur [EMAIL PROTECTED] writes:
 
Dekel On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
Dekel wrote:
  Tidy up the file mathed.lyx. Still doesn't run without bolting
 the  lyxcode definition in the preamble but is otherwise Ok I
 think.
 
Dekel It does work for me. Can you trace the problem ? Does anyone
Dekel else have this problem ?
  I would think it is due to his use of cxx stl library (either a
 bug in the library or in the way we use it).

Angus This suggests that you have some idea where/how this bug is
Angus triggered? Care to through me some pointers?

Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
vector of bool (which should be safe) and stringstreams. I seem to
remember I have seen cases where cxx stringstream did not behave as
gnu version, but this is very hazy for me.

I would try to add some debug statements in there.

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 10:55 am, you wrote:
  Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
 Angus On Thursday 17 January 2002 5:20 pm, Jean-Marc Lasgouttes
 Angus wrote:
   Dekel == Dekel Tsur [EMAIL PROTECTED] writes:
  
 Dekel On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
 Dekel wrote:
   Tidy up the file mathed.lyx. Still doesn't run without bolting
  the  lyxcode definition in the preamble but is otherwise Ok I
  think.
  
 Dekel It does work for me. Can you trace the problem ? Does anyone
 Dekel else have this problem ?
   I would think it is due to his use of cxx stl library (either a
  bug in the library or in the way we use it).
 
 Angus This suggests that you have some idea where/how this bug is
 Angus triggered? Care to through me some pointers?
 
 Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
 vector of bool (which should be safe) and stringstreams. I seem to
 remember I have seen cases where cxx stringstream did not behave as
 gnu version, but this is very hazy for me.
 
 I would try to add some debug statements in there.
 
 JMarc

That, indeed, highlights the problem. Jean-Marc. I added the print statements 
below to LaTeXFeatures.C and ran lyx on lib/examples/mathed.lyx to produce 
the output below. As you can see, tcpreamble should be full of stuff and 
isn't. I've used ostringstream in the past without any problems, but this is 
wierd!

Angus

Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.53
diff -u -p -r1.53 LaTeXFeatures.C
--- src/LaTeXFeatures.C 2002/01/10 10:05:43 1.53
+++ src/LaTeXFeatures.C 2002/01/18 11:11:33
@@ -343,11 +343,14 @@ string const LaTeXFeatures::getTClassPre
tcpreamble  tclass.preamble();

for (layout_type i = 0; i  tclass.numLayouts(); ++i) {
+   std::cerr  layout[i] tclass[i].name()  
std::endl;
if (layout[i]) {
+   std::cerr  tclass[i].preamble()  std::endl;
tcpreamble   tclass[i].preamble();
}
}

+   std::cerr  The whole thing\n  tcpreamble.str()  std::endl;
return tcpreamble.str().c_str();
 }


aleem@pneumon:src- ./lyx
1 Standard

0 Itemize
0 Enumerate
0 Description
0 List
0 Part
1 Section

0 Subsection
0 Subsubsection
0 Paragraph
0 Subparagraph
0 Part*
0 Section*
0 Subsection*
0 Subsubsection*
0 Paragraph*
0 Subparagraph*
0 Title
0 Author
0 Date
0 Abstract
0 Bibliography
1 LyX-Code
 \newenvironment{lyxcode}
   {\begin{list}{}{
 \setlength{\rightmargin}{\leftmargin}
 \raggedright
 \setlength{\itemsep}{0pt}
 \setlength{\parsep}{0pt}
 \normalfont\ttfamily}%
\item[]}
   {\end{list}}

0 Comment
0 Address
0 Right Address
0 Quotation
0 Quote
0 Verse
1 Caption

0 LaTeX Title
The whole thing

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus On Friday 18 January 2002 10:55 am, Jean-Marc Lasgouttes wrote:
 Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
 vector of bool (which should be safe) and stringstreams. I seem to
 remember I have seen cases where cxx stringstream did not behave as
 gnu version, but this is very hazy for me.

Angus The patch, attached, gets everything working. Are you happy to
Angus let this one into the source?

It sure looks weird :) What is the exact solution? That you have to
send a const char * before any lyxstring on a given line?

Could it be that the ostream  lyxstring operator is broken?

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 2:18 pm, Jean-Marc Lasgouttes wrote:
  Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
 Angus On Friday 18 January 2002 10:55 am, Jean-Marc Lasgouttes wrote:
  Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
  vector of bool (which should be safe) and stringstreams. I seem to
  remember I have seen cases where cxx stringstream did not behave as
  gnu version, but this is very hazy for me.
 
 Angus The patch, attached, gets everything working. Are you happy to
 Angus let this one into the source?
 
 It sure looks weird :) What is the exact solution? That you have to
 send a const char * before any lyxstring on a given line?
 
 Could it be that the ostream  lyxstring operator is broken?

That's ostringstream and std::string of course.

I have no idea what's going wrong. This little program works fine!
A

#include iostream
#include sstream

int main() 
{
std::ostringstream os;
os  std::string(Angus\nAngus\nAngus\n);
std::cerr  os.str().c_str()  std::endl;

return 0;
}

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus That's ostringstream and std::string of course.

I had to use lyxstring with cxx 6.2, due to a wrong assert in its
string implementation.

Angus I have no idea what's going wrong. This little program works
Angus fine! A

But then of course the code you propose is a bit strange... Could you
try to add a  std::flush, or whatever could put the string in a
'good' state.

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 3:37 pm, Jean-Marc Lasgouttes wrote:
  Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
 Angus That's ostringstream and std::string of course.
 
 I had to use lyxstring with cxx 6.2, due to a wrong assert in its
 string implementation.
 
 Angus I have no idea what's going wrong. This little program works
 Angus fine! A
 
 But then of course the code you propose is a bit strange... Could you
 try to add a  std::flush, or whatever could put the string in a
 'good' state.

Sorry. You've lost me. 

Do you mean my 5-line program is strange or the patch to LaTeXFeatures?
Where do you want me to add the std::flush?
Why does the top bit of code work, but not the bottom one?


int main() 
{
std::ostringstream os;
os  std::string(Angus\nAngus\nAngus);
std::cerr  os.str().c_str()  std::endl;

return 0;
}


string const LaTeXFeatures::getTClassPreamble() const
{
LyXTextClass const  tclass = textclasslist.TextClass(params.textclass);
ostringstream tcpreamble;

tcpreamble  tclass.preamble();

for (layout_type i = 0; i  tclass.numLayouts(); ++i) {
tcpreamble  tclass[i].preamble();
}

std::cerr  tcpreamble.str().c_str()  std::endl;
return tcpreamble.str().c_str();
}

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus On Friday 18 January 2002 3:37 pm, Jean-Marc Lasgouttes wrote:
  Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
Angus That's ostringstream and std::string of course.
  I had to use lyxstring with cxx 6.2, due to a wrong assert in its
 string implementation.
 
Angus I have no idea what's going wrong. This little program works
Angus fine! A
  But then of course the code you propose is a bit strange... Could
 you try to add a  std::flush, or whatever could put the string in
 a 'good' state.

Angus Sorry. You've lost me.

I don't know either where I am heading. 

Angus Do you mean my 5-line program is strange or the patch to
Angus LaTeXFeatures? 

The patch to LaTeXFeatures. It adds things to the output that I ma not
sure we want to see there. And also, this is very fragile code, since
we do not even know why it would work or not.

Angus Where do you want me to add the std::flush? 

Because I know it exists and because it may magically repair some
broken insternal thing. I don't know really.

Angus Why does the top bit of code work, but not the bottom one?

I really cannot understand that. What happens if you comment out
tcpreamble  tclass.preamble();

Can it be that sending an empty string is wrong?

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 4:04 pm, Jean-Marc Lasgouttes wrote:
 Angus Where do you want me to add the std::flush? 
 
 Because I know it exists and because it may magically repair some
 broken insternal thing. I don't know really.

That was where not why. But I'll try.

 Angus Why does the top bit of code work, but not the bottom one?
 
 I really cannot understand that. What happens if you comment out
   tcpreamble  tclass.preamble();
 
 Can it be that sending an empty string is wrong?

Well that was my first thought. That's the reason for the if (!empty()) 
tests. Without the added strings it made no difference.

I'll play further.
A

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus On Friday 18 January 2002 4:04 pm, Jean-Marc Lasgouttes wrote:
Angus Where do you want me to add the std::flush?
  Because I know it exists and because it may magically repair some
 broken insternal thing. I don't know really.

Angus That was where not why. But I'll try.

Right. I don't know actually.

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 4:29 pm, Jean-Marc Lasgouttes wrote:
  Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
 Angus On Friday 18 January 2002 4:04 pm, Jean-Marc Lasgouttes wrote:
 Angus Where do you want me to add the std::flush?
   Because I know it exists and because it may magically repair some
  broken insternal thing. I don't know really.
 
 Angus That was where not why. But I'll try.
 
 Right. I don't know actually.

Got it! The bug lies in the position counters of ostringstream. 
basic_stringbuf actually. Sometimes they ain't being set correctly.

Importantly, they are used by the basic_stringbuf::str() function. 

The code does some comparisons of position variables to ascertain what to 
print out. We can force things to behave as we expect by making an explicit 
ostringstream::seekp(std::ios::beg) call before calling ostringstream::str().

For reference, here's the code in basic_stringbuf::str(). Complex!

I've attached a patch that cures the problem reliablely.
Angus


/*
 * basic_string str() const
 */

templateclass charT, class traits, class Allocator
basic_stringcharT, traits, Allocator
basic_stringbufcharT, traits, Allocator::str() const
{

  if ( end_pos == 0 )  return string_type();

  if ( (end_pos  ( pptr() - pbase() ))  (end_pos  ( egptr() - eback() )) )
   return string_type(data_, end_pos);
  else 
   {
  if ( ( pptr() - pbase() )  ( egptr() - eback() ) )
   return string_type(data_, pptr() - pbase() );
  else
   return string_type(data_, egptr() - eback() );
   }
   
}



Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.53
diff -u -p -r1.53 LaTeXFeatures.C
--- src/LaTeXFeatures.C	2002/01/10 10:05:43	1.53
+++ src/LaTeXFeatures.C	2002/01/18 17:57:13
@@ -339,14 +339,18 @@ string const LaTeXFeatures::getTClassPre
 	// the text class specific preamble 
 	LyXTextClass const  tclass = textclasslist.TextClass(params.textclass);
 	ostringstream tcpreamble;
-	
+
 	tcpreamble  tclass.preamble();
 
 	for (layout_type i = 0; i  tclass.numLayouts(); ++i) {
 		if (layout[i]) {
-			tcpreamble   tclass[i].preamble();
+			tcpreamble  tclass[i].preamble();
 		}
 	}
+
+	// DEC's implementation of ostringstream has a bug which can be
+	// overcome with this forcing.
+	tcpreamble.seekp(std::ios::beg);
 
 	return tcpreamble.str().c_str();
 }

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Got it! The bug lies in the position counters of ostringstream.
Angus basic_stringbuf actually. Sometimes they ain't being set
Angus correctly.

Did you find out when? We have plenty of uses of this stream which
seem to work with you. It would be nice to find the style which work.

Angus Importantly, they are used by the basic_stringbuf::str()
Angus function.

Angus The code does some comparisons of position variables to
Angus ascertain what to print out. We can force things to behave as
Angus we expect by making an explicit
Angus ostringstream::seekp(std::ios::beg) call before calling
Angus ostringstream::str().

Funny... However, we won't be able to do that for each use of
ostringstream. Are you able to trace the code and see at what place
this happens? 

An alternative would be to define a getline(ostringstream, string),
or maybe tostr(ostringstring const ) which does the right thing.

But I suspect lars will not like it :)

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Thursday 17 January 2002 5:20 pm, Jean-Marc Lasgouttes wrote:
> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
> 
> Dekel> On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
> Dekel> wrote:
> >> Tidy up the file mathed.lyx. Still doesn't run without bolting the
> >> lyxcode definition in the preamble but is otherwise Ok I think.
> 
> Dekel> It does work for me. Can you trace the problem ? Does anyone
> Dekel> else have this problem ?
> 
> I would think it is due to his use of cxx stl library (either a bug in
> the library or in the way we use it).

This suggests that you have some idea where/how this bug is triggered? Care 
to through me some pointers?

Angus

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> On Thursday 17 January 2002 5:20 pm, Jean-Marc Lasgouttes
Angus> wrote:
>> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
>> 
Dekel> On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
Dekel> wrote:
>> >> Tidy up the file mathed.lyx. Still doesn't run without bolting
>> the >> lyxcode definition in the preamble but is otherwise Ok I
>> think.
>> 
Dekel> It does work for me. Can you trace the problem ? Does anyone
Dekel> else have this problem ?
>>  I would think it is due to his use of cxx stl library (either a
>> bug in the library or in the way we use it).

Angus> This suggests that you have some idea where/how this bug is
Angus> triggered? Care to through me some pointers?

Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
vector of bool (which should be safe) and stringstreams. I seem to
remember I have seen cases where cxx stringstream did not behave as
gnu version, but this is very hazy for me.

I would try to add some debug statements in there.

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 10:55 am, you wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> Angus> On Thursday 17 January 2002 5:20 pm, Jean-Marc Lasgouttes
> Angus> wrote:
> >> > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
> >> 
> Dekel> On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
> Dekel> wrote:
> >> >> Tidy up the file mathed.lyx. Still doesn't run without bolting
> >> the >> lyxcode definition in the preamble but is otherwise Ok I
> >> think.
> >> 
> Dekel> It does work for me. Can you trace the problem ? Does anyone
> Dekel> else have this problem ?
> >>  I would think it is due to his use of cxx stl library (either a
> >> bug in the library or in the way we use it).
> 
> Angus> This suggests that you have some idea where/how this bug is
> Angus> triggered? Care to through me some pointers?
> 
> Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
> vector of bool (which should be safe) and stringstreams. I seem to
> remember I have seen cases where cxx stringstream did not behave as
> gnu version, but this is very hazy for me.
> 
> I would try to add some debug statements in there.
> 
> JMarc

That, indeed, highlights the problem. Jean-Marc. I added the print statements 
below to LaTeXFeatures.C and ran lyx on lib/examples/mathed.lyx to produce 
the output below. As you can see, tcpreamble should be full of stuff and 
isn't. I've used ostringstream in the past without any problems, but this is 
wierd!

Angus

Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.53
diff -u -p -r1.53 LaTeXFeatures.C
--- src/LaTeXFeatures.C 2002/01/10 10:05:43 1.53
+++ src/LaTeXFeatures.C 2002/01/18 11:11:33
@@ -343,11 +343,14 @@ string const LaTeXFeatures::getTClassPre
tcpreamble << tclass.preamble();

for (layout_type i = 0; i < tclass.numLayouts(); ++i) {
+   std::cerr << layout[i] << " " << tclass[i].name() << 
std::endl;
if (layout[i]) {
+   std::cerr << tclass[i].preamble() << std::endl;
tcpreamble  << tclass[i].preamble();
}
}

+   std::cerr << "The whole thing\n" << tcpreamble.str() << std::endl;
return tcpreamble.str().c_str();
 }


aleem@pneumon:src-> ./lyx
1 Standard

0 Itemize
0 Enumerate
0 Description
0 List
0 Part
1 Section

0 Subsection
0 Subsubsection
0 Paragraph
0 Subparagraph
0 Part*
0 Section*
0 Subsection*
0 Subsubsection*
0 Paragraph*
0 Subparagraph*
0 Title
0 Author
0 Date
0 Abstract
0 Bibliography
1 LyX-Code
 \newenvironment{lyxcode}
   {\begin{list}{}{
 \setlength{\rightmargin}{\leftmargin}
 \raggedright
 \setlength{\itemsep}{0pt}
 \setlength{\parsep}{0pt}
 \normalfont\ttfamily}%
\item[]}
   {\end{list}}

0 Comment
0 Address
0 Right Address
0 Quotation
0 Quote
0 Verse
1 Caption

0 LaTeX Title
The whole thing

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> On Friday 18 January 2002 10:55 am, Jean-Marc Lasgouttes wrote:
>> Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
>> vector of bool (which should be safe) and stringstreams. I seem to
>> remember I have seen cases where cxx stringstream did not behave as
>> gnu version, but this is very hazy for me.

Angus> The patch, attached, gets everything working. Are you happy to
Angus> let this one into the source?

It sure looks weird :) What is the exact solution? That you have to
send a const char * before any lyxstring on a given line?

Could it be that the ostream << lyxstring operator is broken?

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 2:18 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> Angus> On Friday 18 January 2002 10:55 am, Jean-Marc Lasgouttes wrote:
> >> Try to take a look at LaTeXFeatures::getTClassPreamble(). It uses a
> >> vector of bool (which should be safe) and stringstreams. I seem to
> >> remember I have seen cases where cxx stringstream did not behave as
> >> gnu version, but this is very hazy for me.
> 
> Angus> The patch, attached, gets everything working. Are you happy to
> Angus> let this one into the source?
> 
> It sure looks weird :) What is the exact solution? That you have to
> send a const char * before any lyxstring on a given line?
> 
> Could it be that the ostream << lyxstring operator is broken?

That's ostringstream and std::string of course.

I have no idea what's going wrong. This little program works fine!
A

#include 
#include 

int main() 
{
std::ostringstream os;
os << std::string("Angus\nAngus\nAngus\n");
std::cerr << os.str().c_str() << std::endl;

return 0;
}

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> That's ostringstream and std::string of course.

I had to use lyxstring with cxx 6.2, due to a wrong assert in its
string implementation.

Angus> I have no idea what's going wrong. This little program works
Angus> fine! A

But then of course the code you propose is a bit strange... Could you
try to add a << std::flush, or whatever could put the string in a
'good' state.

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 3:37 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> Angus> That's ostringstream and std::string of course.
> 
> I had to use lyxstring with cxx 6.2, due to a wrong assert in its
> string implementation.
> 
> Angus> I have no idea what's going wrong. This little program works
> Angus> fine! A
> 
> But then of course the code you propose is a bit strange... Could you
> try to add a << std::flush, or whatever could put the string in a
> 'good' state.

Sorry. You've lost me. 

Do you mean my 5-line program is strange or the patch to LaTeXFeatures?
Where do you want me to add the std::flush?
Why does the top bit of code work, but not the bottom one?


int main() 
{
std::ostringstream os;
os << std::string("Angus\nAngus\nAngus");
std::cerr << os.str().c_str() << std::endl;

return 0;
}


string const LaTeXFeatures::getTClassPreamble() const
{
LyXTextClass const & tclass = textclasslist.TextClass(params.textclass);
ostringstream tcpreamble;

tcpreamble << tclass.preamble();

for (layout_type i = 0; i < tclass.numLayouts(); ++i) {
tcpreamble << tclass[i].preamble();
}

std::cerr << tcpreamble.str().c_str() << std::endl;
return tcpreamble.str().c_str();
}

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> On Friday 18 January 2002 3:37 pm, Jean-Marc Lasgouttes wrote:
>> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> 
Angus> That's ostringstream and std::string of course.
>>  I had to use lyxstring with cxx 6.2, due to a wrong assert in its
>> string implementation.
>> 
Angus> I have no idea what's going wrong. This little program works
Angus> fine! A
>>  But then of course the code you propose is a bit strange... Could
>> you try to add a << std::flush, or whatever could put the string in
>> a 'good' state.

Angus> Sorry. You've lost me.

I don't know either where I am heading. 

Angus> Do you mean my 5-line program is strange or the patch to
Angus> LaTeXFeatures? 

The patch to LaTeXFeatures. It adds things to the output that I ma not
sure we want to see there. And also, this is very fragile code, since
we do not even know why it would work or not.

Angus> Where do you want me to add the std::flush? 

Because I know it exists and because it may magically repair some
broken insternal thing. I don't know really.

Angus> Why does the top bit of code work, but not the bottom one?

I really cannot understand that. What happens if you comment out
tcpreamble << tclass.preamble();

Can it be that sending an empty string is wrong?

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 4:04 pm, Jean-Marc Lasgouttes wrote:
> Angus> Where do you want me to add the std::flush? 
> 
> Because I know it exists and because it may magically repair some
> broken insternal thing. I don't know really.

That was "where" not "why". But I'll try.

> Angus> Why does the top bit of code work, but not the bottom one?
> 
> I really cannot understand that. What happens if you comment out
>   tcpreamble << tclass.preamble();
> 
> Can it be that sending an empty string is wrong?

Well that was my first thought. That's the reason for the if (!empty()) 
tests. Without the added strings it made no difference.

I'll play further.
A

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> On Friday 18 January 2002 4:04 pm, Jean-Marc Lasgouttes wrote:
Angus> Where do you want me to add the std::flush?
>>  Because I know it exists and because it may magically repair some
>> broken insternal thing. I don't know really.

Angus> That was "where" not "why". But I'll try.

Right. I don't know actually.

JMarc

Re: CVS Update: lyx-devel

2002-01-18 Thread Angus Leeming


On Friday 18 January 2002 4:29 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> Angus> On Friday 18 January 2002 4:04 pm, Jean-Marc Lasgouttes wrote:
> Angus> Where do you want me to add the std::flush?
> >>  Because I know it exists and because it may magically repair some
> >> broken insternal thing. I don't know really.
> 
> Angus> That was "where" not "why". But I'll try.
> 
> Right. I don't know actually.

Got it! The bug lies in the position counters of ostringstream. 
basic_stringbuf actually. Sometimes they ain't being set correctly.

Importantly, they are used by the basic_stringbuf::str() function. 

The code does some comparisons of position variables to ascertain what to 
print out. We can force things to behave as we expect by making an explicit 
ostringstream::seekp(std::ios::beg) call before calling ostringstream::str().

For reference, here's the code in basic_stringbuf::str(). Complex!

I've attached a patch that cures the problem reliablely.
Angus


/*
 * basic_string str() const
 */

template
basic_string
basic_stringbuf::str() const
{

  if ( end_pos == 0 )  return string_type();

  if ( (end_pos > ( pptr() - pbase() )) && (end_pos > ( egptr() - eback() )) )
   return string_type(data_, end_pos);
  else 
   {
  if ( ( pptr() - pbase() ) > ( egptr() - eback() ) )
   return string_type(data_, pptr() - pbase() );
  else
   return string_type(data_, egptr() - eback() );
   }
   
}



Index: src/LaTeXFeatures.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LaTeXFeatures.C,v
retrieving revision 1.53
diff -u -p -r1.53 LaTeXFeatures.C
--- src/LaTeXFeatures.C	2002/01/10 10:05:43	1.53
+++ src/LaTeXFeatures.C	2002/01/18 17:57:13
@@ -339,14 +339,18 @@ string const LaTeXFeatures::getTClassPre
 	// the text class specific preamble 
 	LyXTextClass const & tclass = textclasslist.TextClass(params.textclass);
 	ostringstream tcpreamble;
-	
+
 	tcpreamble << tclass.preamble();
 
 	for (layout_type i = 0; i < tclass.numLayouts(); ++i) {
 		if (layout[i]) {
-			tcpreamble  << tclass[i].preamble();
+			tcpreamble << tclass[i].preamble();
 		}
 	}
+
+	// DEC's implementation of ostringstream has a bug which can be
+	// overcome with this forcing.
+	tcpreamble.seekp(std::ios::beg);
 
 	return tcpreamble.str().c_str();
 }

Re: CVS Update: lyx-devel

2002-01-18 Thread Jean-Marc Lasgouttes


> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Got it! The bug lies in the position counters of ostringstream.
Angus> basic_stringbuf actually. Sometimes they ain't being set
Angus> correctly.

Did you find out when? We have plenty of uses of this stream which
seem to work with you. It would be nice to find the style which work.

Angus> Importantly, they are used by the basic_stringbuf::str()
Angus> function.

Angus> The code does some comparisons of position variables to
Angus> ascertain what to print out. We can force things to behave as
Angus> we expect by making an explicit
Angus> ostringstream::seekp(std::ios::beg) call before calling
Angus> ostringstream::str().

Funny... However, we won't be able to do that for each use of
ostringstream. Are you able to trace the code and see at what place
this happens? 

An alternative would be to define a getline(ostringstream, string&),
or maybe tostr(ostringstring const &) which does the right thing.

But I suspect lars will not like it :)

JMarc

Re: CVS Update: lyx-devel

2002-01-17 Thread Jean-Marc Lasgouttes


 Dekel == Dekel Tsur [EMAIL PROTECTED] writes:

Dekel On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
Dekel wrote:
 Tidy up the file mathed.lyx. Still doesn't run without bolting the
 lyxcode definition in the preamble but is otherwise Ok I think.

Dekel It does work for me. Can you trace the problem ? Does anyone
Dekel else have this problem ?

I would think it is due to his use of cxx stl library (either a bug in
the library or in the way we use it).

JMarc

Re: CVS Update: lyx-devel

2002-01-17 Thread Jean-Marc Lasgouttes

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

Dekel> On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED]
Dekel> wrote:
>> Tidy up the file mathed.lyx. Still doesn't run without bolting the
>> lyxcode definition in the preamble but is otherwise Ok I think.

Dekel> It does work for me. Can you trace the problem ? Does anyone
Dekel> else have this problem ?

I would think it is due to his use of cxx stl library (either a bug in
the library or in the way we use it).

JMarc

Re: CVS Update: lyx-devel

2002-01-16 Thread Herbert Voss



Angus, I have three more insets in my own cvs, but they
make some problems after your changes. What have I to do
that it will compile again. Here the error messages for
the first inset, the other two have the same.

HErbert

In file included from Dialogs.C:20:
../../../src/frontends/controllers/GUI.h:133: type/value mismatch at 
argument 1 in template parameter list for `template class Controller, 
class GUIview, class Policy, class GUIbc 
GUIController,GUIview,Policy,GUIbc'
../../../src/frontends/controllers/GUI.h:133:   expected a type, got 
`ControlCreateFloat'
../../../src/frontends/controllers/GUI.h: In method 
`GUICreateFloatGUIview,GUIbc::GUICreateFloat(LyXView , Dialogs )':
../../../src/frontends/controllers/GUI.h:137: type/value mismatch at 
argument 1 in template parameter list for `template class Controller, 
class GUIview, class Policy, class GUIbc 
GUIController,GUIview,Policy,GUIbc'
../../../src/frontends/controllers/GUI.h:137:   expected a type, got 
`ControlCreateFLoat'
../../../src/frontends/controllers/GUI.h:137: class 
`GUICreateFloatGUIview,GUIbc' does not have any field named

Re: CVS Update: lyx-devel

2002-01-16 Thread Herbert Voss



Angus, I have three more insets in my own cvs, but they
make some problems after your changes. What have I to do
that it will compile again. Here the error messages for
the first inset, the other two have the same.

HErbert

In file included from Dialogs.C:20:
../../../src/frontends/controllers/GUI.h:133: type/value mismatch at 
argument 1 in template parameter list for `template  
GUI'
../../../src/frontends/controllers/GUI.h:133:   expected a type, got 
`ControlCreateFloat'
../../../src/frontends/controllers/GUI.h: In method 
`GUICreateFloat::GUICreateFloat(LyXView &, Dialogs &)':
../../../src/frontends/controllers/GUI.h:137: type/value mismatch at 
argument 1 in template parameter list for `template  
GUI'
../../../src/frontends/controllers/GUI.h:137:   expected a type, got 
`ControlCreateFLoat'
../../../src/frontends/controllers/GUI.h:137: class 
`GUICreateFloat' does not have any field named

Re: CVS Update: lyx-devel

2002-01-15 Thread Dekel Tsur


On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED] wrote:
   Tidy up the file mathed.lyx. Still doesn't run without bolting the lyxcode
   definition in the preamble but is otherwise Ok I think.

It does work for me. 
Can you trace the problem ?
Does anyone else have this problem ?

Re: CVS Update: lyx-devel

2002-01-15 Thread Dekel Tsur


On Tue, Jan 15, 2002 at 05:28:12PM +, [EMAIL PROTECTED] wrote:
>   Tidy up the file mathed.lyx. Still doesn't run without bolting the lyxcode
>   definition in the preamble but is otherwise Ok I think.

It does work for me. 
Can you trace the problem ?
Does anyone else have this problem ?

Re: CVS Update: lyx-devel

2002-01-13 Thread Jean-Marc Lasgouttes


John Levon wrote:

 On Sun, Jan 13, 2002 at 02:07:27PM +, [EMAIL PROTECTED] wrote:
 
 
  fix problem with nroff detection, remove dead code with old floats,
  bogus message when closing last buffer, toolbar status when changing

 ^^^%^^
 
 how did you fix this out of interest ?


LyXFunc::getStatus was using setErrorMessage (meaning it set an error 
even if we were not trying to dispatch). I added a 
LyXFunc::setStatusMessage method instead, and if a lfun is disabled, 
::dispatch sets the error message to the value of statusmessage. How 
clear is that?

JMarc

Re: CVS Update: lyx-devel

2002-01-13 Thread John Levon


On Sun, Jan 13, 2002 at 05:41:09PM +0100, Jean-Marc Lasgouttes wrote:

 LyXFunc::getStatus was using setErrorMessage (meaning it set an error 
 even if we were not trying to dispatch). I added a 
 LyXFunc::setStatusMessage method instead, and if a lfun is disabled, 
 ::dispatch sets the error message to the value of statusmessage. How 
 clear is that?

Perfectly clear. I'd missed the actual point the error got set.

regards
john

-- 
C is quirky, flawed, and an enormous success. 
- Dennis M. Ritchie

Re: CVS Update: lyx-devel

2002-01-13 Thread Jean-Marc Lasgouttes

John Levon wrote:

> On Sun, Jan 13, 2002 at 02:07:27PM +, [EMAIL PROTECTED] wrote:
> 
> 
>>  fix problem with nroff detection, remove dead code with old floats,
>>  bogus message when closing last buffer, toolbar status when changing
>>
> ^^^%^^
> 
> how did you fix this out of interest ?

LyXFunc::getStatus was using setErrorMessage (meaning it set an error 
even if we were not trying to dispatch). I added a 
LyXFunc::setStatusMessage method instead, and if a lfun is disabled, 
::dispatch sets the error message to the value of statusmessage. How 
clear is that?

JMarc

Re: CVS Update: lyx-devel

2002-01-13 Thread John Levon


On Sun, Jan 13, 2002 at 05:41:09PM +0100, Jean-Marc Lasgouttes wrote:

> LyXFunc::getStatus was using setErrorMessage (meaning it set an error 
> even if we were not trying to dispatch). I added a 
> LyXFunc::setStatusMessage method instead, and if a lfun is disabled, 
> ::dispatch sets the error message to the value of statusmessage. How 
> clear is that?

Perfectly clear. I'd missed the actual point the error got set.

regards
john

-- 
"C is quirky, flawed, and an enormous success." 
- Dennis M. Ritchie

1 2 3 4 5 >

1 - 100 of 438 matches

Mail list logo