Re: Problem compiling lyx1.1.6fix1 on rh7.0 alpha (bis)
Jean-Marc Lasgouttes wrote: > > > "Yann" == Yann MORERE <[EMAIL PROTECTED]> writes: > > Yann> Hello the dream team... I've got problem compiling the 1.1.6fix1 > Yann> release of lyx > > Replace your xforms package with the one found in > ftp.sylvan.com/pub/lyx. This is a better one. > > For the warning with "_", I don't know what this means. Do you have > the latest gcc updates for RH7? It compiled successfully after downloading the good release of xforms and after configuring with --nls-disable. but the degug compiled source is very large as you see before stripping -rwxrwxr-x1 yann yann 57510862 mai 1 02:29 ./lyx9 /usr/local/bin/lyx after stripping -rwxr-xr-x1 root root 5326104 mai 2 204 like a jpeg conversion ratio :-) yann > JMarc
Re: Problem compiling lyx1.1.6fix1 on rh7.0 alpha (bis)
> "Yann" == Yann MORERE <[EMAIL PROTECTED]> writes: Yann> Hello the dream team... I've got problem compiling the 1.1.6fix1 Yann> release of lyx Replace your xforms package with the one found in ftp.sylvan.com/pub/lyx. This is a better one. For the warning with "_", I don't know what this means. Do you have the latest gcc updates for RH7? JMarc
Problem compiling lyx1.1.6fix1 on rh7.0 alpha (bis)
Hello the dream team... I've got problem compiling the 1.1.6fix1 release of lyx here is the gcc compiler [yann@noemi yann]$ gcc -v Reading specs from /usr/lib/gcc-lib/alpha-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.0) [yann@noemi yann]$ here is the linux box [yann@noemi lyx-1.1.6fix1]$ uname -a Linux noemi.univ-valenciennes.fr 2.2.17-4 #1 Mon Oct 23 15:19:13 EDT 2000 alpha unknown [yann@noemi lyx-1.1.6fix1]$ i test 2 configure command ./configure and ./configure --with-included-string here is the results make[3]: Entre dans le répertoire `/home/yann/temp/lyx-1.1.6fix1/src/mathed' /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -g -O2 -fno-exceptions -c formula.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -g -O2 -fno-exceptions -c formula.C -o formula.o formula.C:942:2: warning: #warning This is a terrible hack! We should find a better solution. formula.C:1067:2: warning: #warning This is a terrible hack! We should find a better solution. In file included from ../../src/insets/lyxinset.h:23, from formula.h:27, from formula.C:25: ../../src/gettext.h:46: warning: identifier name `_' conflicts with GNU C++ internal naming strategy ../../src/gettext.h:48: warning: identifier name `_' conflicts with GNU C++ internal naming strategy In file included from formula.C:30: ../../src/minibuffer.h:17: using directive `Object' introduced ambiguous type `_ObjectRec *' formula.C: In method `const string InsetFormula::EditMessage () const': formula.C:486: warning: identifier name `_' conflicts with GNU C++ internal naming strategyformula.C: In method `UpdatableInset::RESULT InsetFormula::LocalDispatch (BufferView *, int, const string &)': formula.C:881: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:892: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:894: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:909: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:924: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:927: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:1085: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:1087: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:1122: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:1131: warning: identifier name `_' conflicts with GNU C++ internal naming strategy formula.C:1251: warning: identifier name `_' conflicts with GNU C++ internal naming strategy make[3]: *** [formula.lo] Erreur 1 make[3]: Quitte le répertoire `/home/yann/temp/lyx-1.1.6fix1/src/mathed' make[2]: *** [all-recursive] Erreur 1 make[2]: Quitte le répertoire `/home/yann/temp/lyx-1.1.6fix1/src' make[1]: *** [all-recursive-am] Erreur 2 make[1]: Quitte le répertoire `/home/yann/temp/lyx-1.1.6fix1/src' make: *** [all-recursive] Erreur 1 [yann@noemi lyx-1.1.6fix1]$ has someone an idea? Yann -- The Principal of Greenbow County Central Schools: "Your momma sure does care 'bout your schoolin' son" "Y faut liiirrreee, Arlequin, Champion de l'amou" Dany Boon --- (Yann MORERE mailto:[EMAIL PROTECTED] ) (Docteur en Automatique http://ymorere.multimania.com/ )
RE: segfault in LyX1.1.6fix1
On 27-Mar-2001 Ben Stanley wrote: > Here's a backtrace from the core dump Well the backtrace is not really verbose. You should start lyx with gdb and then do the backtrace on the segfault. Also go up the tree and do 'bt' AND you should have a non striped binary! Ah an last but not least you should tell us what you did to get the crash! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Life is a serious burden, which no thinking, humane person would wantonly inflict on someone else. -- Clarence Darrow
segfault in LyX1.1.6fix1
Here's a backtrace from the core dump
ben [15:23:05] ~/Documents/PhD_Thesis/Document $ gdb `which lyx` core
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `lyx -dbg latex'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libforms.so.0.88...done.
Loaded symbols for /usr/lib/libforms.so.0.88
Reading symbols from /usr/X11R6/lib/libXpm.so.4...done.
Loaded symbols for /usr/X11R6/lib/libXpm.so.4
Reading symbols from /lib/libpthread.so.0...done.
rw_common (): write: Success.
warning: unable to set global thread event mask
[New Thread 1024 (LWP 2075)]
rw_common (): write: Success.
warning: stop_or_attach_thread: generic error
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /usr/X11R6/lib/libSM.so.6...done.
Loaded symbols for /usr/X11R6/lib/libSM.so.6
Reading symbols from /usr/X11R6/lib/libICE.so.6...done.
Loaded symbols for /usr/X11R6/lib/libICE.so.6
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...done.
Loaded symbols for /usr/lib/libstdc++-libc6.2-2.so.3
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
#0 0x4024da21 in __kill () from /lib/libc.so.6
(gdb) bt
#0 0x4024da21 in __kill () from /lib/libc.so.6
#1 0x400c401e in raise (sig=6) at signals.c:65
#2 0x4024ee04 in abort () at ../sysdeps/generic/abort.c:88
#3 0x82676eb in lyx::abort () at abort.C:9
#4 0x81062e1 in error_handler (err_sig=11) at ../src/lyx_main.C:877
#5 0x400c4329 in pthread_sighandler (signo=11, ctx={gs = 0, __gsh = 0,
fs = 0, __fsh = 0, es = 43,
__esh = 0, ds = 43, __dsh = 0, edi = 0, esi = 0, ebp = 322152,
esp = 322144,
ebx = 1074370632, edx = 137905600, ecx = 1, eax = 0, trapno = 14,
err = 4, eip = 1074138504,
cs = 35, __csh = 0, eflags = 66050, esp_at_signal = 322144, ss
= 43, __ssh = 0,
fpstate = 0xb2e8, oldmask = 2147483648, cr2 = 188}) at
signals.c:97
#6
#7 0x40060d88 in fl_find_object () from /usr/lib/libforms.so.0.88
#8 0x40060e38 in fl_find_first () from /usr/lib/libforms.so.0.88
#9 0x40053bdc in fl_handle_form () from /usr/lib/libforms.so.0.88
#10 0x400540dd in fl_handle_automatic () from /usr/lib/libforms.so.0.88
#11 0x400544aa in do_interaction_step () from /usr/lib/libforms.so.0.88
#12 0x40054b49 in fl_treat_interaction_events () from
/usr/lib/libforms.so.0.88
#13 0x40054b84 in fl_check_forms () from /usr/lib/libforms.so.0.88
#14 0x82049e0 in GUIRunTime::runTime () at GUIRunTime.C:79
#15 0x80f76bc in LyXGUI::runTime (this=0x83541f8) at lyx_gui.C:419
#16 0x80f9850 in LyX::LyX (this=0x400c2194, argc=0xb660,
argv=0xb6c4) at ../src/lyx_main.C:168
#17 0x81442fc in main (argc=1, argv=0xb6c4) at ../src/main.C:40
#18 0x4023cb5c in __libc_start_main (main=0x814416c , argc=3,
ubp_av=0xb6c4,
init=0x804e644 <_init>, fini=0x82e2b54 <_fini>, rtld_fini=0x4000d634
<_dl_fini>, stack_end=0xb6bc)
at ../sysdeps/generic/libc-start.c:129
(gdb)
I'm using a LyX that I compiled myself from the stock source on a RH 7.0
box with compiler and C++ library updates.
Ben.
--
Ben Stanley |barf [ba:rf] 2. "He suggested using FORTRAN,
PhD Student | and everybody barfed." - From the Shogakukan
SITACS| DICTIONARY OF NEW ENGLISH (Second Edition)
University of Wollongong |
Australia |http://www.uow.edu.au/~bds02
Re: A bug/fix report for language option in LyX1.1.6fix1
Min Xu <[EMAIL PROTECTED]> writes:
| Thanks. A new version of hyperref solves the problem. But putting the language
| as a global option does break some other packages, for example, the newest
| slide making package "prosper" will be broken if the global language option is
| used.
Then this is a bug in prosper. File a bug report please.
| Does it make more sense that the language option is specified at the place
| where it is used, i.e., by:
| \usepackage[language]{babel}
It is not only babel that use the language string, and that is the
pooint in setting in the documentclass option: all packages that can
be laguage tunable can then take advantage of it.
Lgb
Re: A bug/fix report for language option in LyX1.1.6fix1
On Fri, Feb 09, 2001 at 08:49:49AM -0500, Min Xu wrote:
> Thanks. A new version of hyperref solves the problem. But putting the language
> as a global option does break some other packages, for example, the newest
> slide making package "prosper" will be broken if the global language option is
> used.
Report this bug to the author(s) of prosper (and the other packages).
> Does it make more sense that the language option is specified at the place
> where it is used, i.e., by:
> \usepackage[language]{babel}
No, because there are other packages that use the language option.
Re: A bug/fix report for language option in LyX1.1.6fix1
Thanks. A new version of hyperref solves the problem. But putting the language
as a global option does break some other packages, for example, the newest
slide making package "prosper" will be broken if the global language option is
used.
Does it make more sense that the language option is specified at the place
where it is used, i.e., by:
\usepackage[language]{babel}
Min
> > ! LaTeX Error: Missing \begin{document}.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H for immediate help.
> > ...
> >
> > l.1478 \ProcessOptionsWithKV{Hyp}
>
> I think that the problem here is the hyperref package.
> Try installing the latest version of hyperref from CTAN.
PGP signature
Re: A bug/fix report for language option in LyX1.1.6fix1
On Thu, Feb 08, 2001 at 10:05:28AM -0500, Min Xu wrote:
> The LyX1.1.6fix1 handles the language option by putting it as a global
> option. Recently, I found this placement make the pdflatex fail with the
> following message:
>
> ! LaTeX Error: Missing \begin{document}.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type H for immediate help.
> ...
>
> l.1478 \ProcessOptionsWithKV{Hyp}
I think that the problem here is the hyperref package.
Try installing the latest version of hyperref from CTAN.
Re: A bug/fix report for language option in LyX1.1.6fix1
Min Xu <[EMAIL PROTECTED]> writes: | Hi, | | The LyX1.1.6fix1 handles the language option by putting it as a global | option. Recently, I found this placement make the pdflatex fail with | the following message: If so, this is a bug in pdflatex or the documentclass or a package file... Can you send a test document that shows this behaviour? Lgb
A bug/fix report for language option in LyX1.1.6fix1
Hi,
The LyX1.1.6fix1 handles the language option by putting it as a global
option. Recently, I found this placement make the pdflatex fail with the
following message:
! LaTeX Error: Missing \begin{document}.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.1478 \ProcessOptionsWithKV{Hyp}
While after removing the language global option and replace the babel
line by:
\usepackage[american]{babel}
fixed the problem.
This bug appears in a foils lyx file which can be found at Oscar's web
site. http://www.iit.upco.es/~oscar/download/Presentation.tgz
Please cc to [EMAIL PROTECTED] as I am not subscribed to this
mailing list.
Min Xu
Re: lyx1.1.6fix1
On 06-Feb-2001 Jean-Marc Lasgouttes wrote: > > Lars> We use it to validate the format of the layout file, if the > Lars> validation fails we do not load the layout file. > > OK, that's one good reason. And think of something like a layout-wizard (if we find someone who would write such a thing ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 is not doing the thing we like to do, but liking the thing we have to do, that makes life blessed. -- Goethe
Re: lyx1.1.6fix1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Agree, we should be sober about what the xml format gives. What | Lars> it gives is a defined syntax + libraries for parsing/validation. | Lars> Easier interaction with external tools because of this. | | And are the said libraries light enough to justifiy their use? Or are | we going to have a lot of bloat due to that? There are beginning to come a lot of prorams that use xml libraries so if we use one of those we will not be bloating. If we are including our onw xml lib we can most likely use a stripped down version. Lgb
Re: lyx1.1.6fix1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Agree, we should be sober about what the xml format gives. What Lars> it gives is a defined syntax + libraries for parsing/validation. Lars> Easier interaction with external tools because of this. And are the said libraries light enough to justifiy their use? Or are we going to have a lot of bloat due to that? JMarc
Re: lyx1.1.6fix1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Jose> The point is that by changing it to XML we can use lots of | Jose> software that work with it. The parser is one of them. | | What I do not like in this stance is that it looks so much like when | people told us we should switch to java. XML (for now) seems to me | more like hype than a _real_ gain. Agree, we should be sober about what the xml format gives. What it gives is a defined syntax + libraries for parsing/validation. Easier interaction with external tools because of this. Other than this the advantage is not huge. Lgb
Re: lyx1.1.6fix1
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: Jose> As Lars said with XML and a dtd it is possible to validate the Jose> layout files. Now as it is, LyX can load a faulty file that can Jose> crash it. This shouldn't happen. I'd be interested to see a layout file that would crash LyX, whereas an xml version would work. Jose> The point is that by changing it to XML we can use lots of Jose> software that work with it. The parser is one of them. What I do not like in this stance is that it looks so much like when people told us we should switch to java. XML (for now) seems to me more like hype than a _real_ gain. JMarc
Re: lyx1.1.6fix1
On Tue, Feb 06, 2001 at 12:32:28PM +, John Levon wrote: > which validating parser are you planning to use ? > > RXP ? There are several alternatives, another is libxml. There is some dicussion on the thread about the XML cvs branch. I suppose we want one to use directly in lyx. If that is from James Clark I guess there should be an API to call it from lyx. I am just guessing here. > john > -- > "Ou trouver les sources du lovely-fucky color-ls ?" > - Saintjoanis Emmanuel -- José
Re: lyx1.1.6fix1
On Tue, 6 Feb 2001, Jose Abilio Oliveira Matos wrote: > The point is that by changing it to XML we can use lots of software that > work with it. The parser is one of them. which validating parser are you planning to use ? RXP ? john -- "Ou trouver les sources du lovely-fucky color-ls ?" - Saintjoanis Emmanuel
Re: lyx1.1.6fix1
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Jose Abilio Oliveira Matos wrote: | > | > On Tue, Feb 06, 2001 at 10:27:02AM +0100, Lars Gullik Bjønnes wrote: | > > | | > > imho hte layout files are close to xml already, just bissing some <> | > > and change the name of some endtags. | > | > I totally agree. | > | > > Lgb | They seem to work, why fix them? Is there a potential gain in | functionality? Yes, validation of layout files When we support online generation of paragraph layouts/floats/theorems etc. an xml format (or any format that can ge fun through a validator) will be a boon. Aslo to have all files read by lyx use the same "engine" is good. I think we all agree that LyXLex is not perfect and that we misuse it in a lot of places. Lgb
Re: lyx1.1.6fix1
On Tue, Feb 06, 2001 at 08:20:36AM -0400, Garst R. Reese wrote: > They seem to work, why fix them? Is there a potential gain in > functionality? Yes. As Lars said with XML and a dtd it is possible to validate the layout files. Now as it is, LyX can load a faulty file that can crash it. This shouldn't happen. The point is that by changing it to XML we can use lots of software that work with it. The parser is one of them. > Garst -- José
Re: lyx1.1.6fix1
Jose Abilio Oliveira Matos wrote: > > On Tue, Feb 06, 2001 at 10:27:02AM +0100, Lars Gullik Bjønnes wrote: > > > > imho hte layout files are close to xml already, just bissing some <> > > and change the name of some endtags. > > I totally agree. > > > Lgb They seem to work, why fix them? Is there a potential gain in functionality? Garst
Re: lyx1.1.6fix1
On Tue, Feb 06, 2001 at 10:27:02AM +0100, Lars Gullik Bjønnes wrote: > > | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | > | Lars> Why not switch to an xml like format? > | > | Lars> This could also perhaps help the xml-format project a bit. > | > | I really do not see what we gain from that, actually... > > Primarily the same parser code for all the lyx files, the possibillity > of haveing a dtd for layout files, language files, bind files, > keyboard files. First, I know that I like XML, now LyX even outputs an XML version of docbook. :-) We talked before about changing the layout files to script files using python/perl/scheme/javascript or whatever language we choose to access the lyx kernel. Does this means that we are postponing this decision? One option that is simultaneously XML and a script language is xls, but that is to take with lots of salt, with the size of an ocean. :-) What I am raising is this, do we want the layout files to be scripts or data declarations (as the XML solution implies)? > | Whereas the > | gain is clear for the .lyx format which requires some structure, the > | layout format is fine as it is. Since layouts are edited by hand, I > | really feel the current format is much more intelligible. > > imho hte layout files are close to xml already, just bissing some <> > and change the name of some endtags. I totally agree. > Lgb -- José
Re: lyx1.1.6fix1
On Tue, Feb 06, 2001 at 10:13:43AM +0100, Jean-Marc Lasgouttes wrote: > I really do not see what we gain from that, actually... Whereas the > gain is clear for the .lyx format which requires some structure, the > layout format is fine as it is. Since layouts are edited by hand, I In the future, we may have a layout editor.
Re: lyx1.1.6fix1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> We use it to validate the format of the layout file, if the Lars> validation fails we do not load the layout file. OK, that's one good reason. JMarc
Re: lyx1.1.6fix1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Primarily the same parser code for all the lyx files, the | Lars> possibillity of haveing a dtd for layout files, language files, | Lars> bind files, keyboard files. | | I have to admit that I still do not see what the wonderful advantages | of xml are... What will we do with a DTD? Print it out and frame it on | the wall? We use it to validate the format of the layout file, if the validation fails we do not load the layout file. Lgb
Re: lyx1.1.6fix1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Primarily the same parser code for all the lyx files, the Lars> possibillity of haveing a dtd for layout files, language files, Lars> bind files, keyboard files. I have to admit that I still do not see what the wonderful advantages of xml are... What will we do with a DTD? Print it out and frame it on the wall? JMarc
Re: lyx1.1.6fix1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Why not switch to an xml like format? | | Lars> This could also perhaps help the xml-format project a bit. | | I really do not see what we gain from that, actually... Primarily the same parser code for all the lyx files, the possibillity of haveing a dtd for layout files, language files, bind files, keyboard files. | Whereas the | gain is clear for the .lyx format which requires some structure, the | layout format is fine as it is. Since layouts are edited by hand, I | really feel the current format is much more intelligible. imho hte layout files are close to xml already, just bissing some <> and change the name of some endtags. Lgb
Re: lyx1.1.6fix1
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Why not switch to an xml like format? Lars> This could also perhaps help the xml-format project a bit. I really do not see what we gain from that, actually... Whereas the gain is clear for the .lyx format which requires some structure, the layout format is fine as it is. Since layouts are edited by hand, I really feel the current format is much more intelligible. JMarc
Re: lyx1.1.6fix1
On Mon, 5 Feb 2001, Amir Karger wrote: [...] > Attached you'll find layout2xml.pl. The other attachment is the converted > stdlists.inc [...] Gee, you must be really enthusiastic about your thesis at the moment! Allan. (ARRae)
Re: lyx1.1.6fix1
On Mon, Feb 05, 2001 at 10:31:40PM +0200, Dekel Tsur wrote:
> On Mon, Feb 05, 2001 at 09:22:07PM +0100, Lars Gullik BjRnnes wrote:
> > Why not switch to an xml like format?
> >
> > This could also perhaps help the xml-format project a bit.
> >
> >
> > afrikaans
> > afrikaans
> > Afrikaans
> > iso8859-1
> >
>
> So the layouts files should also be stored in xml format.
> I will let others do these changes.
OK.
Attached you'll find layout2xml.pl. The other attachment is the converted
stdlists.inc
I don't actually know xml, so I've done a very rudimentary job. I'm hoping
someone will give me a bit more detail on exactly what you want. Right now:
- ... is placed
around the whole document (Since I only remove .layout, .inc remains, by
the way. Of course that could be changed.)
- each comment line turns into
- Style & other blocks that nest turn into ...
- Attributes become something like
- Preamble is copied verbatim until EndPreamble and put inside
a ... block.
- Some rudimentary formatting is done to make the xml human-readable
I've tried it so far on the files stdlists.inc and revtex4.layout, and it
seems to handle everything. I didn't do anything special with Input, and
an attribute like Columns, which applies to the whole textclass, is treated
the same way as a style sub-attribute like AlignPossible. So let me know
what needs to be changed.
You probably want to be more sophisticated than using 'value="whatever"' for
everything. For example, you may want to have some text not actually in the
<> blocks. But I've never written xml, so I wouldn't know. Try running it on
a couple files, and see what you get, and tell me what changes I should make.
-Amir
#!/usr/bin/perl -w
use strict;
my $Verbatim = 0;
my %BlockEnd = (
"Font" => "EndFont",
"LabelFont" => "EndFont",
"TextFont" => "EndFont",
"Style" => "End",
"ClassOptions" => "End",
);
my @ExpectedEnd = ();
my @Block = ();
my $name = $ARGV[0];
$name =~ s/\.layout$//;
print qq(\n\n);
while (<>) {
if ($Verbatim) {
if (/^\s*EndPreamble/) {
$Verbatim = 0;
print " " x @Block;
print "\n";
} else {
print;
}
# Empty line
} elsif (/^\s*$/) {
print;
# Comment
} elsif (/^\s*#/) {
s/#(.*)//;
print;
# End of current block
} elsif (@ExpectedEnd && /^\s*$ExpectedEnd[-1]\s*$/) {
pop @ExpectedEnd;
my $str = pop @Block;
print " " x @Block;
print qq(\n);
# Beginning of other block
} elsif (/^\s*(\w+)(\s+(\w+))?/i && exists $BlockEnd{$1}) {
my $blockname = $1;
my $val = $3;
my $valstr = $val ? qq( value="$val") : "";
# Indent before pushing onto @Block
print " " x @Block;
print qq(<$blockname$valstr>\n);
push @Block, $blockname;
push @ExpectedEnd, $BlockEnd{$blockname};
# Attribute
} elsif (/\s*(\w+)\s+(\S.*)/) {
my ($name, $val) = ($1, $2);
print " " x @Block;
print qq(<$name value="$val">\n);
} elsif (/\s*Preamble/) {
$Verbatim = 1;
print " " x @Block;
print "\n";
} else {
warn "unhandled line: $_, expect is @ExpectedEnd";
print;
}
}
print "\n";
Re: lyx1.1.6fix1
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Mon, Feb 05, 2001 at 09:22:07PM +0100, Lars Gullik Bjønnes wrote: | > Why not switch to an xml like format? | > | > This could also perhaps help the xml-format project a bit. | > | > | > afrikaans | > afrikaans | > Afrikaans | > iso8859-1 | > | | So the layouts files should also be stored in xml format. Yes, I belive that is the way to go. | I will let others do these changes. Hmm da hmm. Lgb
Re: lyx1.1.6fix1
On Mon, Feb 05, 2001 at 09:22:07PM +0100, Lars Gullik Bjønnes wrote: > Why not switch to an xml like format? > > This could also perhaps help the xml-format project a bit. > > > afrikaans > afrikaans > Afrikaans > iso8859-1 > So the layouts files should also be stored in xml format. I will let others do these changes.
Re: lyx1.1.6fix1
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Tue, Feb 06, 2001 at 01:04:57AM +0900, Miyata Shigeru wrote: | > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: | > etc. While it has been changed into | > | > # name babel name GUI nameRTL? encoding code latex options | > afrikaans afrikaans "Afrikaans" false iso8859-1 af_ZA "" | > americanamerican"American" false iso8859-1 en_US "" | > arabic arabic "Arabic"true iso8859-6 ar_SA "" | | I'm thinking of changing the format of the languages file to | Language afrikaans | Babel afrikaans | Name "Afrikaans" | Encoding iso8859-1 | etc. Why not switch to an xml like format? This could also perhaps help the xml-format project a bit. afrikaans afrikaans Afrikaans iso8859-1 Lgb
Re: lyx1.1.6fix1
On Tue, Feb 06, 2001 at 01:04:57AM +0900, Miyata Shigeru wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > etc. While it has been changed into > > # name babel name GUI nameRTL? encoding code latex options > afrikaans afrikaans "Afrikaans" false iso8859-1 af_ZA "" > americanamerican"American" false iso8859-1 en_US "" > arabic arabic "Arabic"true iso8859-6 ar_SA "" I'm thinking of changing the format of the languages file to Language afrikaans Babel afrikaans Name "Afrikaans" Encoding iso8859-1 etc.
Re: lyx1.1.6fix1
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Herbert, did you solve this problem?? It could maybe be a wrong > language description somewhere... Do you use greek? Do you have your > own language file? It is that lyxlex does not respect newlines. In 1.1.6 languages file looked like # name babel name GUI nameRTL? encoding code afrikaans afrikaans "Afrikaans" false iso8859-1 af_ZA americanamerican"American" false iso8859-1 en_US arabic arabic "Arabic"true iso8859-6 ar_SA etc. While it has been changed into # name babel name GUI nameRTL? encoding code latex options afrikaans afrikaans "Afrikaans" false iso8859-1 af_ZA "" americanamerican"American" false iso8859-1 en_US "" arabic arabic "Arabic"true iso8859-6 ar_SA "" etc. in 1.1.6fix1 Now LyX 1.1.6fix1 reads the old format languages file as # name babel name GUI nameRTL? encoding codelatex options afrikaans afrikaans "Afrikaans" false iso8859-1 af_ZA american american"American" false iso8859-1 en_US arabic arabic "Arabic"trueiso8859-6 ar_SA austrian austrian "Austrian" etc. After some thinking I come to the conclusion that it is not a bug but a feature of lyxlex. Since the default mode for lyxlex is escape == false (we have to deal with LaTeX commands), we cannot escape \n easily, which restricts the line length severely. So I won't submit a patch ;-) He had solved the problem by removing ~/.lyx/languages Probably running configure again could have fixed the problem, too. Regards, SMiyata
RE: LyX1.1.6fix1 - table
On 03-Feb-2001 Herbert Voss wrote:
> when i insert a table alignment for a cell, for example
>
>|>{\columncolor[gray]{.8}}c|
>
> and i want to edit this string, the cursor always jumps
> to the end of this string when i delete any of the characters
> inside this string. for example: delete "8" abd the cursor
> jumps to the right.
>
> this behaviour is only in the alignment-fields and not in
> the width-fields.
Because I removed the automatic update on the width fields, there you
have to press ENTER to be able to change them.
Now the question is should we do this for all of the input fields,
I opt for YES and will do the modifications if there are not votes
against this behaviour!
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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's page one, a preemptive strike?
-- Professor Freund, Communication, Ramapo State College
Re: lyx1.1.6fix1
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> some curious thing happens ... i can´t run any lyx-file
Herbert> without the error
Herbert> Package Babel error you haven't defined ...
Herbert> exporting to tex gives the following lyx-command:
Herbert> %% LyX specific LaTeX commands.
Herbert> \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
Herbert> greek
Herbert> %% User specified LaTeX commands.
Herbert, did you solve this problem?? It could maybe be a wrong
language description somewhere... Do you use greek? Do you have your
own language file?
JMarc
LyX1.1.6fix1 - table
when i insert a table alignment for a cell, for example
|>{\columncolor[gray]{.8}}c|
and i want to edit this string, the cursor always jumps
to the end of this string when i delete any of the characters
inside this string. for example: delete "8" abd the cursor
jumps to the right.
this behaviour is only in the alignment-fields and not in
the width-fields.
Herbert
--
[EMAIL PROTECTED]
http://perce.de/lyx/
Re: lyx1.1.6fix1
Herbert Voss <[EMAIL PROTECTED]> wrote:
> exporting to tex gives the following lyx-command:
>
> %% LyX specific LaTeX commands.
> \providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
> greek
>
> %% User specified LaTeX commands.
>
>
> maybe that i'm blinded by the light, but what's the word greek doing
> here?
Have you updated system global or your personal languages file?
It is probably in /usr/share/lyx directory on UNIX.
Regards,
SMiyata
lyx1.1.6fix1
some curious thing happens ...
i can´t run any lyx-file without the error
Package Babel error you haven't defined ...
exporting to tex gives the following lyx-command:
%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
greek
%% User specified LaTeX commands.
maybe that i'm blinded by the light, but what's the word greek doing
here?
deleting it, and running latex by hand works well! exporting from lyx
again gives the same situation.
this behaviour is with all my textes.
Herbert
--
[EMAIL PROTECTED]
http://perce.de/lyx/
