Re: First attempt at using SAX for XML output.
On 06-Oct-2000 Gaillard Pierre-Olivier wrote: > Hello, the sources to the xml directory that I am using right now. It's > currently VERY SMALL. But when we start using libxml to be more > compliant with xml (unicode and so on) then we will have something much > bigger to bundle in LyX. But I guess we do not need to do that before > LyX 2.0. > > I have not sent patches because I would probably have made bad ones > anyway. And since all files are new to you, there is no problem I guess > (but I promise I'll make patches next time). > I've had a look at this and IMO we could integrate this in the LyX sources as start of the xml-like save format. Then to start I could change the write function of insettabuar (LyXTabular) to use this library. I know we don't want new stuff right now so I thought to forward this to LyX-Devel so that others can have a look at this too! Lars what do you think? Now or after 1.1.6? (I guess after we really should concentrate on removing the bugs we have and not continuing on introducing new stuff otherwise we won't get 1.1.6 out this year! (this applies also to Dekels last patch IMO or is it a bug-fix?) 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Where humor is concerned there are no standards -- no one can say what is good or bad, although you can be sure that everyone will. -- John Kenneth Galbraith xml.tgz
Re: lyxformat 2,00
> "Matthias" == Matthias Peick <[EMAIL PROTECTED]> writes: Matthias> Hello, 1. "export LANG=de_DE" 2. Make sure that Matthias> LC_-variables aren't set. 3. "lyx &" 4. Create a new Matthias> document from template "dinbrief.lyx". 5. Look at your Matthias> xterm: "Achtung: Benötige LyX-Format 2,15, die gewählte Matthias> Datei enthält 2,00" 6. See the grafical effects at Matthias> "Adresse:". Matthias> ',' is handled instead of '.' in the template files but the Matthias> version number is "2.15" . It's lyx version 1.1.14-fix3. Hello, thanks for the report. This should be fixed in version 1.1.5fix2. JMarc
Re: Formatting error: lyx or latex?
> "Ed" == Ed Hurst <[EMAIL PROTECTED]> writes: Ed> What would yuo need to see to examine this problem? -- I formatted Ed> an article for printing. I had a title, and author and date. Below Ed> the date, I inserted a medskip and a horizontal line. Then came a Ed> paragraph, all emphasized, followed by another medskip and Ed> horizontal line. The body of the article followed. Ed> In processing to ps for ghostscript, I got a leading page with the Ed> first horizontal line all by itself near the top, and the rest of Ed> the article began on the next page, minus the first horizontal Ed> line. When I removed this line, the article processed as expected Ed> and printed without the leading almost-blank-page. The layouts Title, Date and Author are special and you should not add skips to them. In fact, you cannot do much to change the way they appear. You can, however, add skips/lines to the paragraph which follows them. Hope this helps. JMarc
[PATCH]: Inset::Clone & xforms dialogs to update or hide
Attached are two patches. Both are physically large but very simple. patch_insets == In patch_insets, I modified the Inset::Clone method, so that it is passed a Buffer const & parameter. I also modified all Inset c-tors that are passed a Buffer *. They are now passed a Buffer const & also (it is impossible tfor an inset to be created without a buffer, so this is ok). Net result is to fix a bug with those insets that store a Buffer * and pass this on to a Cloned inset. I did not modify LyXParagraph to store a Buffer *. This patch is way big enough already! Consequently, the Inset::Clone() methods are passed a current_view->buffer(). Don't worry; this will change. With this patch, current_view is eliminated almost entirely from the subdirectories. It exists only in a couple of inset classes that are slated either for removal or for the GUI-I treatment. patch_xforms == the updateBufferDependent signal is now connected to FormBase::updateOrHide(). If the daughter class should ALWAYS be updated when the buffer changes, this is flagged by an enum passed to the FormBase c-tor. If it should hide when the buffer changes, then the enum reflects this. I consider both patches to be bug fixes, so would like them applied before 1.1.6. Angus patch_insets.bz2 patch_xforms.bz2
Re: Compiling LyX using AthlonGCC
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> I wanted to know if users of GCC 2.95.2 (the base for the Baruch> AthlonGCC) have any such troubles compiling LyX? I'm using the Baruch> --enable-assertions --enable-warnings configure options. I've got trouble compiling with 2.95.2 on my alpha station, if this means something. JMarc
Re: Compiling LyX using AthlonGCC
On Mon, 9 Oct 2000, Baruch Even wrote: > Hi, > > While setting up my new computer I've upgraded the compiler from the > distributions egcs 1.1.2 to AthlonGCC 2.95.3, the AthlonGCC is a patch > over the PGCC 2.95.3 which is a patch against GCC 2.95.2. The PGCC is a > pentium optimized version of GCC and AthlonGCC is an Athlon optimized > version. > > I'm having troubles to compile LyX with the AthlonGCC, this troubles are > avoided if I use the plain EGCS from the distribution. The first place it > falls on is my own translator.h but I'm unable to understand the reason > for the failure. > let me guess - parse error where it says Map::const_iterator ? Try it without -pedantic, it should work fine. I have some interesting experience with CVS gcc, which I shall post about soon. > I wanted to know if users of GCC 2.95.2 (the base for the AthlonGCC) have > any such troubles compiling LyX? I'm using the --enable-assertions > --enable-warnings configure options. > I have yet to be able to compile with 2.95.2 - internal compiler error at a specific point (forget which). Hence my attempt to use CVS gcc john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: compiling 1.1.5fix1 on irix 6.5
> "Eli" == Eli Tziperman <[EMAIL PROTECTED]> writes: Eli> It did indeed help. Thanks. The compilation did get stuck at Eli> another step later... see below. Eli Eli> ld32: WARNING 84 : Eli> /usr/local/lib/libiberty.a is not used for resolving any symbol. Eli> ld32: FATAL 12 : Expecting n32 objects: /usr/lib/libX11.so is Eli> o32. collect2: ld returned 4 exit status AFAIK, this is a problem with the different kind of libraries under irix (old/new style, 32/64bits). There is probably some flag you have to pass to ld (in LDFLAGS) like "-n32" to work around this. I'm sorry this is not very clear, but I do not know much about Irix. JMarc
[PATCH] 2.97 gcc
I see someone added cases in lyxinclude for 2.97 (latest CVS gcc). Well it won't compile without disabling -pedantic either, because of this error : In file included from insetgraphicsParams.C:20: ../../src/support/translator.h:93: parse error before ';' token In file included from insetgraphicsParams.C:20: ../../src/support/translator.h:120: parse error before ';' token ../../src/support/translator.h: In member function `const T2 &Translator::find(const T1 &) const [with T1 = InsetGraphicsParams::Resize, T2 = string]': insetgraphicsParams.C:207: instantiated from here ../../src/support/translator.h:98: `it' undeclared (first use this function) ../../src/support/translator.h:98: (Each undeclared identifier is reported only once for each function it appears in.) In file included from insetgraphicsParams.C:20: ../../src/support/translator.h:93: parse error before ';' token In file included from insetgraphicsParams.C:20: ../../src/support/translator.h:120: parse error before ';' token ../../src/support/translator.h: In member function `const T2 &Translator::find(const T1 &) const [with T1 = InsetGraphicsParams::Resize, T2 = string]': insetgraphicsParams.C:207: instantiated from here ../../src/support/translator.h:98: `it' undeclared (first use this function) ../../src/support/translator.h:98: (Each undeclared identifier is reported only once for each function it appears in.) Also, I made -fhonor-std optional - it is not necessarily turned on (certainly doesn't seem to be in codesourcery RPMs) which breaks the compile. Also I get an infinite compile time in buffer.C, it never seems to get anywhere. Can anyone reproduce this before I report to gcc-bugs ? thanks john ? gcc297.diff Index: ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v retrieving revision 1.585 diff -u -r1.585 ChangeLog --- ChangeLog 2000/10/06 06:13:46 1.585 +++ ChangeLog 2000/10/09 12:50:21 @@ -1,3 +1,7 @@ +2000-10-09 John Levon <[EMAIL PROTECTED]> + + * make -fhonor-std optional for gcc 2.97 + 2000-10-06 Allan Rae <[EMAIL PROTECTED]> * po/Makefile.in.in (POTFILES.in, POTFILES): Fixed Index: config/lyxinclude.m4 === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/lyxinclude.m4,v retrieving revision 1.22 diff -u -r1.22 lyxinclude.m4 --- config/lyxinclude.m42000/10/02 00:55:00 1.22 +++ config/lyxinclude.m42000/10/09 12:50:21 @@ -157,9 +157,19 @@ lyx_flags="$lyx_flags warnings" AC_DEFINE(WITH_WARNINGS, 1, [Define this if you want to see the warning directives put here and - there by the developpers to get attention]) + there by the developers to get attention]) fi +AC_ARG_ENABLE(honor-std, + [ --enable-honor-std tell the compiler to use strict namespace for std], + enable_honor_std=$enableval, enable_honor_std=yes) + +if test x$enable_honor_std = xyes ; then + ac_honor_std="-fhonor-std" +else + ac_honor_std="" +fi + # optimize less for development versions if test $lyx_devel_version = yes -o $lyx_prerelease = yes ; then lyx_opt="-O" @@ -186,8 +196,8 @@ case $gxx_version in 2.95.1) CXXFLAGS="-g $lyx_opt -fpermissive -fno-rtti -fno-exceptions";; 2.95.*) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";; - 2.96*) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";; - 2.97*) CXXFLAGS="-g $lyx_opt -fhonor-std -fvtable-thunks -ffunction-sections -fdata-sections";; + 2.96*) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";; + 2.97*) CXXFLAGS="-g $lyx_opt $ac_honor_std -fvtable-thunks +-ffunction-sections -fdata-sections";; *2.91.*) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";; *) CXXFLAGS="-g $lyx_opt -fno-rtti -fno-exceptions";; esac @@ -205,6 +215,7 @@ case $gxx_version in 2.95.*) ;; 2.96*) ;; + 2.97*) ;; *2.91*) ;; *) CXXFLAGS="$CXXFLAGS -pedantic";; esac
qtarch 1.4-5
is available now from http://sourceforge.net/projects/qtarch Anyone editing KDE dialogs please update, thanks. john
Re: First attempt at using SAX for XML output.
Juergen Vigna <[EMAIL PROTECTED]> writes: | Lars what do you think? Now or after 1.1.6? (I guess after we really | should concentrate on removing the bugs we have and not continuing on | introducing new stuff otherwise we won't get 1.1.6 out this year! | (this applies also to Dekels last patch IMO or is it a bug-fix?) I really think we should stop adding features now. Now we should concentrace on fixing features that were present in 1.1.5 and on fixing the new features/code. For stuff that is not official yet, furter development will be allowed: insetgrapics NEW_INSETS etc., but we should very soon stop working on this too and concentrate on fixing any/all outstanding bugs. Lgb
Re: Compiling LyX using AthlonGCC
John Levon <[EMAIL PROTECTED]> writes: | > I wanted to know if users of GCC 2.95.2 (the base for the AthlonGCC) have | > any such troubles compiling LyX? I'm using the --enable-assertions | > --enable-warnings configure options. | > | | I have yet to be able to compile with 2.95.2 - internal compiler error at | a specific point (forget which). Hence my attempt to use CVS gcc I have _no_ problems with gcc 2.95.2 gcc-c++-2.95.2-3mdk gcc-chill-2.95.2-3mdk gcc-colorgcc-2.95.2-3mdk gcc-2.95.2-3mdk gcc-cpp-2.95.2-3mdk gcc-g77-2.95.2-3mdk gcc-java-2.95.2-3mdk gcc-libgcj-2.95.2-3mdk gcc-objc-2.95.2-3mdk ibstdc++-2.95.2-3mdk libstdc++-compat-2.95.2-3mdk libstdc++-devel-2.95.2-3mdk glibc-devel-2.1.3-15 glibc-2.1.3-15 Lgb
Re: Compiling LyX using AthlonGCC
On 9 Oct 2000, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | > I wanted to know if users of GCC 2.95.2 (the base for the AthlonGCC) have > | > any such troubles compiling LyX? I'm using the --enable-assertions > | > --enable-warnings configure options. > | > > | > | I have yet to be able to compile with 2.95.2 - internal compiler error at > | a specific point (forget which). Hence my attempt to use CVS gcc > > I have _no_ problems with gcc 2.95.2 > > gcc-c++-2.95.2-3mdk Yikes ! I knew other people could use 2.95.2 fine, I was hoping it was a mdk thing, but apparently not. I don't get random errors so I don't think it is my hardware. This gets more and more mysterious :/ I think somehow my installation must be totally broken, but I'm baffled as to how ... john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: [PATCH] 2.97 gcc
John Levon <[EMAIL PROTECTED]> writes: | I see someone added cases in lyxinclude for 2.97 (latest CVS gcc). Well | it won't compile without disabling -pedantic either, because of this error | : We absolutely do not want -pedantic, that was just a forgotten case by me. | Also, I made -fhonor-std optional - it is not necessarily turned on | (certainly doesn't seem to be in codesourcery RPMs) which breaks the | compile. If you compile 2.97 without --enable-libstdcxx-v3 I don't want any reports from you. :-) Just leave the -fhonor-std there. | Also I get an infinite compile time in buffer.C, it never seems to get | anywhere. Can anyone reproduce this before I report to gcc-bugs ? It only takes a _long_ time. This is how I configure 2.97: ../configure --enable-libstdcxx-v3 --enable-languages=c++ \ --enable-shared --enable-cshadow-headers Lgb
Re: Compiling LyX using AthlonGCC
On 09-Oct-2000 Lars Gullik Bjønnes wrote: > > I have _no_ problems with gcc 2.95.2 > I'm actually compiling with gcc-2.96 (from a RedHat 7.0 installation). The only problem I had was the LString.h error message as I think some stl include-file includes before LString.h can be included and it seems that the string implementation is to buggy for LyX so that LyX decides to not use it, so I've to configure with --without-included-string. After that all compiles (with a warning from sstream about compairing int with uint), but then I get an error linking in debug.C where the Debug::ANY is not rightly connected and it gives a undefined error. Well I'll continue to try as I would upgrade to RedHat 7.0 but do it only when I can compile LyX with it ;) Jürgen BTW: Could someone tell me what: RTFM means? (for translation) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ All power corrupts, but we need electricity.
Re: [PATCH] 2.97 gcc
On 9 Oct 2000, Lars Gullik Bjønnes wrote: > We absolutely do not want -pedantic, that was just a forgotten case by > me. > ok. just out of interest why is this ? I'm not enough of a C++ boffin to see what's so wrong with pedantic ;) > > If you compile 2.97 without --enable-libstdcxx-v3 I don't want any > reports from you. :-) I'm glad to hear you are so forward looking :) > Just leave the -fhonor-std there. > ok. This will have to stay a local patch then as it seems to need recompiling qt + kde libs (not an option for me). > | Also I get an infinite compile time in buffer.C, it never seems to get > | anywhere. Can anyone reproduce this before I report to gcc-bugs ? > > It only takes a _long_ time. > thanks. After two hours I assumed it had got stuck. I will have to drop back to 2.91.66 (I hope support for this will stay for some time, because as soon as it goes, I can't compile lyx any more !) > This is how I configure 2.97: > > ../configure --enable-libstdcxx-v3 --enable-languages=c++ \ > --enable-shared --enable-cshadow-headers > yes I compiled up a recent snapshot similarly (except without cshadow-headers, is that default, or was that wrong ...) thanks john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: Compiling LyX using AthlonGCC
> BTW: Could someone tell me what: RTFM means? (for translation) ;-) Read The F...ing Manual :-( Insert your favourite F-word here! A
Re: New Menu::expand method in menu backend
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> After reading the ui file, we have a representation of the menu Dekel> by a rooted tree, whose nodes are instances of the Menu class Dekel> (if I read the code correctly, the edges of the tree are stored Dekel> using the submenu_ strings, and not with pointers). The expand Dekel> function (it can be implemented as a method, but lets assume it Dekel> is a function) receives some node in this tree (the root in the Dekel> case of gnome/kde, or a child of the root in the case of Dekel> xforms) and does the following: It traverses the node and its Dekel> descendents, and creates a copy of the scanned subtree, but in Dekel> the copy tree, the "special" items are expanded. When expanding Dekel> the TOC, new nodes may be added to the copy tree. The copy tree Dekel> is then passed to the frontend code, so the frontend code just Dekel> need to traverse the tree it receives, and process it. To put it another way, I thought I could just add a Menu* member in menuitem and that Menu::expand would just populate that for items of type Submenu for Toc and Ref. I have a few questions, though: - if there is a need for an "update" menu entry for gnome, expand() should be aware of that somehow. Another solution would be that expand() leaves the entries it has expanded in place, and that the frontend would be free to either ignore them or take special action. - for the refs menu, it seems to me that the special entry should just provide a list of references (as submenus), not the whole refs menu with four times the same information. - why not modify the refs menu to something similar to (o) Insert Reference ( ) Insert page reference ( ) Insert pretty ref ( ) Goto ref [...] - label1...label10 >> label11...label21 >> It seems to me that this would be less confusing than having five submenus with the same contents (and you have one less click when using often the same function). With this view of things, only the part under the separator would be a special entry. The rest could be handled via normal stuff. Dekel, comments? JMarc
Re: Compiling LyX using AthlonGCC
On Mon, 9 Oct 2000, Juergen Vigna wrote: > > On 09-Oct-2000 Lars Gullik Bjønnes wrote: > > > > I have _no_ problems with gcc 2.95.2 > > > > I'm actually compiling with gcc-2.96 (from a RedHat 7.0 installation). > The only problem I had was the LString.h error message as I think some > stl include-file includes before LString.h can be included and > it seems that the string implementation is to buggy for LyX so that LyX > decides to not use it, so I've to configure with --without-included-string. > I got this as a result of the -fhonor-std flag - it means that the simple string test fails with "string undeclared", so it thinks the actual implementation is buggy. Remove -fhonor-std and it will go away (at least it did for me). Latest CVS I noticed doesn't set honor-std for 2.96 anyway ... One of these days I will get a working stable gcc release and then I can forget about this terrible nightmare I am in thanks john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: Compiling LyX using AthlonGCC
On 09-Oct-2000 John Levon wrote: > > I got this as a result of the -fhonor-std flag - it means that the simple > string test fails with "string undeclared", so it thinks the actual > implementation is buggy. Remove -fhonor-std and it will go away (at least > it did for me). Latest CVS I noticed doesn't set honor-std for 2.96 anyway > ... I don't think that that would work! But with the option --without-included-string I'm now able to compile and link lyx. I had to change the code in debug.h and insert ANY inside the enum ANY= 0x and comment out the code: #if 0 /// static const type ANY = type(INFO | INIT | KEY | GUI | PARSER | LYXRC | KBMAP | LATEX | MATHED | FONT | TCLASS | LYXVC | LYXSERVER | ROFF | ACTION | LYXLEX | DEPEND | INSETS); #endif Lars could you comment on this please. 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 happened last night can happen again.
Re: [PATCH] 2.97 gcc
John Levon <[EMAIL PROTECTED]> writes: | On 9 Oct 2000, Lars Gullik Bjønnes wrote: | | > We absolutely do not want -pedantic, that was just a forgotten case by | > me. | > | | ok. just out of interest why is this ? I'm not enough of a C++ boffin to | see what's so wrong with pedantic ;) | | > | > If you compile 2.97 without --enable-libstdcxx-v3 I don't want any | > reports from you. :-) | | I'm glad to hear you are so forward looking :) gcc 3 will certainly use libstdc++-v3 so why not use that for testing. | | > Just leave the -fhonor-std there. | > | | ok. This will have to stay a local patch then as it seems to need | recompiling qt + kde libs (not an option for me). | | > | Also I get an infinite compile time in buffer.C, it never seems to get | > | anywhere. Can anyone reproduce this before I report to gcc-bugs ? | > | > It only takes a _long_ time. | > | | thanks. After two hours I assumed it had got stuck. I will have to drop | back to 2.91.66 (I hope support for this will stay for some time, because | as soon as it goes, I can't compile lyx any more !) My trick is to ave a small Build script that build those files (that just take too long) without optimization and without debug: #!/bin/bash make -C src/insets CXXFLAGS="-g -fdefault-inline -fhonor-std -fvtable-thunks -ffunction-sections -fdata-sections -W -Wall -Wconversion -Winline" figinset.lo make -C src CXXFLAGS="-g -fdefault-inline -fhonor-std -fvtable-thunks -ffunction-sections -fdata-sections -W -Wall -Wconversion -Winline" buffer.o lyxfunc.o lyxrc.o make (tweek to fit) | > This is how I configure 2.97: | > | > ../configure --enable-libstdcxx-v3 --enable-languages=c++ \ | > --enable-shared --enable-cshadow-headers | > | | yes I compiled up a recent snapshot similarly (except without | cshadow-headers, is that default, or was that wrong ...) I don't think cshadow-headers is default yet, they are currently in a flux. Lgb
Re: Compiling LyX using AthlonGCC
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 09-Oct-2000 John Levon wrote: | > | > I got this as a result of the -fhonor-std flag - it means that the simple | > string test fails with "string undeclared", so it thinks the actual | > implementation is buggy. Remove -fhonor-std and it will go away (at least | > it did for me). Latest CVS I noticed doesn't set honor-std for 2.96 anyway | > ... | | I don't think that that would work! | | But with the option --without-included-string I'm now able to compile and | link lyx. I had to change the code in debug.h and insert ANY inside the | enum | | ANY= 0x You are allowed to post some compiler messages... Seems to me to be a compiler bug. And we don't want ANY defined like that... | and comment out the code: | #if 0 | /// | static const type ANY = type(INFO | INIT | KEY | GUI | | PARSER | LYXRC | KBMAP | LATEX | | MATHED | FONT | TCLASS | LYXVC | | LYXSERVER | ROFF | ACTION | LYXLEX | | DEPEND | INSETS); | #endif | | Lars could you comment on this please. compiler messages please. Lgb
Re: [PATCH] 2.97 gcc
On 9 Oct 2000, Lars Gullik Bjønnes wrote: > gcc 3 will certainly use libstdc++-v3 so why not use that for testing. > yep, makes sense as long as testers are aware that codesourcery RPMs and the like won't work ... I'm aware now so ... :) > > My trick is to ave a small Build script that build those files (that > just take too long) without optimization and without debug: > tried that, didn't seem to help much (though -O certainly makes a big speed difference for me). I will play around some more, and try to get 2.95.2 working anyway by compiling from source. > > I don't think cshadow-headers is default yet, they are currently in a > flux. thanks for the pointer john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: Compiling LyX using AthlonGCC
On Mon, 9 Oct 2000, John Levon wrote: > On Mon, 9 Oct 2000, Baruch Even wrote: > > > Hi, > > > > While setting up my new computer I've upgraded the compiler from the > > distributions egcs 1.1.2 to AthlonGCC 2.95.3, the AthlonGCC is a patch > > over the PGCC 2.95.3 which is a patch against GCC 2.95.2. The PGCC is a > > pentium optimized version of GCC and AthlonGCC is an Athlon optimized > > version. > > > > I'm having troubles to compile LyX with the AthlonGCC, this troubles are > > avoided if I use the plain EGCS from the distribution. The first place it > > falls on is my own translator.h but I'm unable to understand the reason > > for the failure. > > > > let me guess - parse error where it says Map::const_iterator ? > Try it without -pedantic, it should work fine. I have some interesting > experience with CVS gcc, which I shall post about soon. Right on the point, I'll try it without the -pedantic, though I don't remember if it was there. > > I wanted to know if users of GCC 2.95.2 (the base for the AthlonGCC) have > > any such troubles compiling LyX? I'm using the --enable-assertions > > --enable-warnings configure options. > > I have yet to be able to compile with 2.95.2 - internal compiler error at > a specific point (forget which). Hence my attempt to use CVS gcc Here the plain gcc 2.95.2 just had troubles compiling or linking, I dont remember exactly, I returned to egcs 1.1.2. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Compiling LyX using AthlonGCC
On 9 Oct 2000, Jean-Marc Lasgouttes wrote: > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > Baruch> I wanted to know if users of GCC 2.95.2 (the base for the > Baruch> AthlonGCC) have any such troubles compiling LyX? I'm using the > Baruch> --enable-assertions --enable-warnings configure options. > > I've got trouble compiling with 2.95.2 on my alpha station, if this > means something. I've tried with 2.95.2 (unpatched) on my machine and had troubles too. I'm also having troubles with egcs 1.1.2 for what it matters (It cant find GroupCache::find on linking, I'm forced to make the function un-inlined). -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Compiling LyX using AthlonGCC
On Mon, 9 Oct 2000, Baruch Even wrote: > I've tried with 2.95.2 (unpatched) on my machine and had troubles too. I'm > also having troubles with egcs 1.1.2 for what it matters (It cant find > GroupCache::find on linking, I'm forced to make the function un-inlined). > Same problem for me, I need http://www.movement.uklinux.net/patches/lyx/filedlg.C.diff all very odd john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro
Re: languages and encodings
On Mon, Oct 09, 2000 at 09:58:27AM +0300, Andrew Zabolotny wrote: > On Sat, 7 Oct 2000 17:46:13 +0200, Dekel Tsur wrote: > > >Actually we (I) plan to remove the encoding selection from the document > >dialog. There will be only one available encoding: Unicode. > Um... does TeX eat unicode files? I bet no. Or you are going to use \GlyphName > for every letter? This would expand LaTeX files immensely... Especially for the > "export to LaTeX" mode I would like to be able to get "normal" files, in the > encoding of my choice. Maybe GNU's iconv tables could be used for that? I think > me and many other users (at least that uses Cyrillic) will appreciate the > ability to export to "native" LaTeX code. I think that the Omega tex engine supports unicode file. As for standard tex, the file generated by LyX will use 8bit encoding, but it will be possible to change the encoding between paragraphs. > The problem is, there aren't many Unicode fonts available. In fact, I know only > of one (which comes with XFree 4.0). I don't believe this will change soon. > Besides, there are lots of excellent PostScript and TrueType fonts already, will > they work (are you going to use XFree4's ability to recode fonts on-the-fly into > Unicode?) There are many free unicode TTF fonts (although they do not include all glyphs) See http://www.ccss.de/slovo/unifonts.htm Support for unicode fonts exists in XFree 3.3.x > P.S. I have a problem building latest LyX on a RH6.2 system: the libxforms > library uses some "xstat" function that is not available in glibc: what can I > do? It is possible that the XForms library you have is compiled for glibc 2.0, while your glibc is 2.1, so you will need to install the correct version of XForms. > P.P.S. Maybe there is some list on the internationalization of LyX where > somebody would be interested in opinions of someone who uses Cyrillic natively? > Too often packages are "internationalized" and then it turns that it is unusable > for people that speaks one or other language. I would like to participate in > this process :-) Just send your complaints to [EMAIL PROTECTED]
Re: First attempt at using SAX for XML output.
On Mon, Oct 09, 2000 at 09:50:16AM +0200, Juergen Vigna wrote: > Lars what do you think? Now or after 1.1.6? (I guess after we really > should concentrate on removing the bugs we have and not continuing on > introducing new stuff otherwise we won't get 1.1.6 out this year! > (this applies also to Dekels last patch IMO or is it a bug-fix?) My patch adds a new feature (the languages file), but also contains several bug fixes, so it should go in. Here is an updated version of the patch (I've also moved the encodings definition to a text file). patch.gz
InsetGraphics (and related) patch
Hello, Attached is a patch for the InsetGraphics and related stuff, this patch touches mostly on InsetGraphics and adding some stuff for GUII, it does not touch anything outside that EXCEPT a small change to the Painter class to add a method that draws images that come from LyXImage, this is an addition to the method that draws Pixmaps and is intended to replace it, but not now, for now it is only to be used by InsetGraphics. The changes in this patch include: Adding a GUII image class called LyXImage, so that it will hold the images to be drawn in a GUII and System Independent way. Initial support for Image conversion so as to easily produce PS or PDF documents from any image format (that is supported by an external converter on the users machine). Very initial support. De-inlining two methosd in filedlg.C that caused compilation problems on egcs 1.1.2 Changed the xforms FormGraphics to use the ButtonController. Various fixes to clean up after the changes between august and now. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael patch.diff.gz
Patch: lyxrc.example
Small changes to lyxrc.example patch.gz
Re: First attempt at using SAX for XML output.
"Lars Gullik Bjønnes" wrote:
>
> Gaillard Pierre-Olivier <[EMAIL PROTECTED]> writes:
>
> | XMLAttributes is a subclass of map that defines a method
> | "set(string name, int value)".
>
> By adding a [] operator you can at least make things a bit nicer.
>
I tried this (see lower) but since it is a conversion problem is seems
I should redefine "=" operator
or define a converter from int to string.
> | What do you think, may I write new Lyx 'Write' methods in the same
> | style ? In languages like Python the
> | code is even nicer, but maybe Lars would know how to make this code
> | nicer in C++.
>
> How is it done in Python?
>
In Python dictionnaries (maps) are native, so you can write something
like :
xmlOut.startElement("LyxTabular", {"version" : "1.0", "option" :
"xml"})
Also you don't need to manage your memory and you can put any type of
data
in your dictionnary. So that ints work as well as strings without any
effort.
> | void LyXTabular::Write(Buffer const * buf, ostream & os) const
> | {
> | // header line
> | XMLSAXPrettifier xmlOut(os);
> | XMLAttributes attributes;
>
> | attributes.clear();
>
> This line should not be needed.
Indeed, I felt it was unpleasant. I will use {} blocks to make each
'attributes' instance local.
Then there will be no need for clear().
>
> | //starting "LyXTabular"
> | attributes["version"] = "1";
>
> Why do you not use this style all the time?
Because I tried to redefine the [] operator but then I realized that it
would not work and then I decided
that method 'set' was OK. I believe I need a subclass of string (e.g.
ValueString) that provides a constructor :
ValueString(int i).
But I am not used to C++ so I did not do that. If you think I should I
can do it on wednesday evening.
> Or is set a template?
> What is XMLAttributes really?
>
Well just a map with an additional 'set' method that
uses strstream to build a string from the int value it was passed. You
can check this in the files I sent to you and Juergen ).
As far as release-time is concerned, I need this XML file-format at
work (I need to emulate some Interleaf features soon, so I need to be
able to manage LyX files in Python scripts) but I am afraid that 1.1.6
would not be ready in-time anyway (that is even if XML file-format did
not introduce any delay... which is questionable), so that I will have
to make the scripts for the current LyX format. Then when the XML format
is available I can upgrade my scripts easily and make them robust.
Thanks for your help, I expect to write other XML write methods on
wednesday but if you have comments I will
rewrite the things until we get something clean.
Pierre-Olivier
Bug report: File closing causes crash
Following is a report on a bug that was already reported here, namely when closing an open file LyX will crash. The reason is that when the Buffer is d-tor'ed it runs a signal updateBufferDependent (this is done in BufferView::Pimpl), this signal in turn runs a method updateAllVisibleBufferRelatedDialogs, in it there is a reference to the now d-tor'ing buffer, specifically the line says: if (current_view->buffer()->isReadonly()) Obviously at this stage a reference to the buffer is a bad idea. I haven't followed and understood the surrounding logic, so I cant offer a fix for this, but hopefully someone more knowledgeable in the code could fix it now that the reason is found. Here is the complete backtrace: #0 0x402194e1 in __kill () from /lib/libc.so.6 #1 0x400b01eb in raise (sig=6) at signals.c:64 #2 0x4021a868 in abort () at ../sysdeps/generic/abort.c:88 #3 0x816b838 in lyx::abort () at abort.C:9 #4 0x809c7df in error_handler (err_sig=11) at ../src/lyx_main.C:821 #5 0x40219408 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #6 0x8098856 in updateAllVisibleBufferRelatedDialogs () at lyx_gui_misc.C:154 #7 0x8182001 in SigC::FuncSlot0_::callback (data=0x826d0dc) at ../../../sigc++/func_slot.h:52 #8 0x8174ca9 in SigC::Callback0::call (this=0x826d0dc) at ../../../sigc++/slot.h:260 #9 0x8174d7c in SigC::Signal0 >::emit ( this=0x8269d5c) at ../../../sigc++/basic_signal.h:194 #10 0x8176581 in SigC::Signal0 >::operator() ( this=0x8269d5c) at ../../sigc++/basic_signal.h:172 #11 0x80578cf in BufferView::Pimpl::buffer (this=0x82679b0, b=0x0) at BufferView_pimpl.C:147 #12 0x8053b30 in BufferView::buffer (this=0x82678f8, b=0x0) at BufferView.C:79 #13 0x806f6f0 in Buffer::~Buffer (this=0x829fff0, __in_chrg=3) at buffer.C:148 #14 0x807d91e in BufferStorage::release (this=0x821c444, buf=0x829fff0) at bufferlist.C:60 #15 0x807e179 in BufferList::close (this=0x821c440, buf=0x829fff0) at bufferlist.C:218 #16 0x80b8a57 in LyXFunc::CloseBuffer (this=0x82692e0) at lyxfunc.C:3455 #17 0x80a64ca in LyXFunc::Dispatch (this=0x82692e0, ac=12, do_not_use_this_arg=@0xb954) at lyxfunc.C:895 #18 0x81658c7 in Menubar::Pimpl::MenuCallback (ob=0x8260cd0, button=1) at Menubar_pimpl.C:655 #19 0x8165728 in C_Menubar_Pimpl_MenuCallback (ob=0x8260cd0, button=1) at Menubar_pimpl.C:611 #20 0x400368bf in fl_object_qread () from /usr/X11R6/lib/libforms.so.0.88 #21 0x40044b8e in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.88 #22 0x8145455 in GUIRunTime::runTime () at GUIRunTime.C:79 #23 0x80985a5 in LyXGUI::runTime (this=0x82311a8) at lyx_gui.C:396 #24 0x8099a11 in LyX::LyX (this=0xba8c, argc=0xbab0, argv=0xbaf4) at ../src/lyx_main.C:166 #25 0x80c291c in main (argc=2, argv=0xbaf4) at ../src/main.C:40 -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Compiling LyX using AthlonGCC
On Mon, 9 Oct 2000, Baruch Even wrote: > On 9 Oct 2000, Jean-Marc Lasgouttes wrote: > > > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > > > Baruch> I wanted to know if users of GCC 2.95.2 (the base for the > > Baruch> AthlonGCC) have any such troubles compiling LyX? I'm using the > > Baruch> --enable-assertions --enable-warnings configure options. > > > > I've got trouble compiling with 2.95.2 on my alpha station, if this > > means something. > > I've tried with 2.95.2 (unpatched) on my machine and had troubles too. I'm > also having troubles with egcs 1.1.2 for what it matters (It cant find > GroupCache::find on linking, I'm forced to make the function un-inlined). I guess I should report my experiences too just so we have a complete mixed bag of results ;-) Mdk-7.0 + bug fixes == success with gcc-2.95.2 as shipped SuSE-6.3 + bug fixes + my own gcc-2.95.2 + my own egcs-1.1.2 == success RedHat-6.0 + bug fixes + the same two compilers above == success Mdk-6.1 + bug fixes + the same two compilers above == success The two compilers I built as RPMs using -O3 + a bunch of other optimisation flags and run fine on three different distros -- all on the same harddisk on the same machine. The only patch applied to clean distributions of the respective compilers is modification of a set of flags in some Makefiles to get everything optimised instead of just most of it. If you like I can send you my spec file and patch so you can build your own super-optimised rpm. But then you might still have problems. Allan. (ARRae)
Re: Compiling LyX using AthlonGCC
On Tue, 10 Oct 2000, Allan Rae wrote: > On Mon, 9 Oct 2000, Baruch Even wrote: > > > On 9 Oct 2000, Jean-Marc Lasgouttes wrote: > > > > > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > > > > > Baruch> I wanted to know if users of GCC 2.95.2 (the base for the > > > Baruch> AthlonGCC) have any such troubles compiling LyX? I'm using the > > > Baruch> --enable-assertions --enable-warnings configure options. > > > > > > I've got trouble compiling with 2.95.2 on my alpha station, if this > > > means something. > > > > I've tried with 2.95.2 (unpatched) on my machine and had troubles too. I'm > > also having troubles with egcs 1.1.2 for what it matters (It cant find > > GroupCache::find on linking, I'm forced to make the function un-inlined). > > I guess I should report my experiences too just so we have a complete > mixed bag of results ;-) > > Mdk-7.0 + bug fixes == success with gcc-2.95.2 as shipped > SuSE-6.3 + bug fixes + my own gcc-2.95.2 + my own egcs-1.1.2 == success > RedHat-6.0 + bug fixes + the same two compilers above == success > Mdk-6.1 + bug fixes + the same two compilers above == success > > The two compilers I built as RPMs using -O3 + a bunch of other > optimisation flags and run fine on three different distros -- all on the > same harddisk on the same machine. The only patch applied to clean > distributions of the respective compilers is modification of a set of > flags in some Makefiles to get everything optimised instead of just most > of it. > > If you like I can send you my spec file and patch so you can build your > own super-optimised rpm. But then you might still have problems. I assume that you use gcc 2.95.2 and LyX compiles fine. If so I would like to see the Redhat patches and configuration. One thing that I couldn't figure out is that together with the compiler it compiled and installed the libstdc++-3 or something to this effect, I've had quite a bit of problems just getting everything compiled and running with this library. The general setting I've used locally is that everything from the distribution (or RPMs) is installed at /usr/ and stuff I compile is in /usr/local/ so there was also a mix with the directories used and the version running, I believe that I covered it all when I tested LyX with it, specifically I used the path such that the compiler was run from /usr/local/bin to get the new version, the directories where the new libraries went too I added to /etc/ld.so.conf so that the shared libraries will be loaded. My problem with gcc 2.95.2 was at the end its inability to compile LyX due to compilation errors (the running errors were actually with the Athlon patches - it compiled fine but wouldn't run). -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://www.redrival.com/jindor/(My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Patch: lyxrc.example
On Mon, 9 Oct 2000, Dekel Tsur wrote: > Small changes to lyxrc.example I'll apply this. Allan. (ARRae)
Re: [PATCH]: Inset::Clone & xforms dialogs to update or hide
On Mon, 9 Oct 2000, Angus Leeming wrote: > Attached are two patches. Both are physically large but very simple. > > patch_insets > == Haven't looked at this one. > patch_xforms > == > the updateBufferDependent signal is now connected to > FormBase::updateOrHide(). If the daughter class should ALWAYS be updated when > the buffer changes, this is flagged by an enum passed to the FormBase c-tor. > If it should hide when the buffer changes, then the enum reflects this. I'd still prefer to see you override connect() in appropriate classes rather than turn FormBase into a swiss-army knife. Perhaps we need a FormInsetBase since it's basically insets that will get caught out on a buffer change -- that is, put updateOrHide() in FormInsetBase. Although in this case overriding connect() should be sufficient. FormCommand::connect() can be set to connect hide()/apply() to FormCommand::updateOrHide() and FormToc::connect() can override that to call FormBase::connect(). That is, put the buffer check in a more appropriate point in the hierarchy. It doesn't count for many of the dialogs and I don't like the idea of storing of Buffer * anyway. I'll have check what I did in the lyx repository but I'm sure most of the stuff was working okay there without any update problems. I also found myself confused by the patch thinking that FormPreferences would be hidden when the user switches buffers even though it's buffer independent. That was because of the presense of the HIDE in the call of the FormBase constructor. We should probably shuffle the order of the parameters and add a default value for BufferDependency. Remember that insets aren't the only things with dialogs so you shouldn't be pushing everything inset-related into FormBase because it just doesn't make sense for other dialogs. If you find yourself writing the word inset ina comment in FormBase then that piece of code probably doesn't belong in FormBase. > I consider both patches to be bug fixes, so would like them applied before > 1.1.6. I'll apply this anyway since it also contains the FormParagraph conversion and should fix the buffer-close segfault. Allan. (ARRae)
Re: Compiling LyX using AthlonGCC
On Mon, 9 Oct 2000, John Levon wrote: > On Mon, 9 Oct 2000, Baruch Even wrote: > > > I've tried with 2.95.2 (unpatched) on my machine and had troubles too. I'm > > also having troubles with egcs 1.1.2 for what it matters (It cant find > > GroupCache::find on linking, I'm forced to make the function un-inlined). > > > > Same problem for me, I need > http://www.movement.uklinux.net/patches/lyx/filedlg.C.diff > > all very odd > > john > > -- > "Take the ideas you find useful. Try not to get hung up on the labels." > - Jonathan S. Shapiro > > Dear Baruch, Are you compiling with -g and without -O ? I compiled this way and had the exact same problem, which I think is due to this combination of options stopping g++ from expanding functions inline, but in this case from also compiling the function out-of-line for some unknown reason. Therefore an alternative solution to the problem is compiling filedlg.C with -O (i.e. take the specific g++ line from the make and redo it with an additional -O). Then linking should work out fine. HTH, Lior.
Re: Bug report: File closing causes crash
On Tue, 10 Oct 2000, Baruch Even wrote:
> Following is a report on a bug that was already reported here, namely when
> closing an open file LyX will crash.
Fixed.
updateBufferDependent was being called when there were no buffers left.
This is just plain wrong.
Angus is there any reason why the original call to updateBD had to be
taken from the "if (buffer_) {" compound statement and shifted to the end
of the function?
I see from your comments that you want bv_->text updated but that was
already done in the compound statement. Is there some other reason?
Allan.
Re: FormPreferences crash resolved?
On Sun, 8 Oct 2000, Allan Rae wrote:
> On Fri, 6 Oct 2000, Angus Leeming wrote:
>
> > Defining the following function in FormPreferences resolves the
> >
> > BadDrawable (invalid Pixmap or Window parameter)
[...]
> > void FormPreferences::hide()
> > {
> > if (form() && form()->visible) {
> > fl_hide_form( outputs_tab_->form );
> > fl_hide_form( look_n_feel_tab_->form );
> > fl_hide_form( inputs_tab_->form );
>
> I suspect just these three should be sufficient.
> Or just hiding the currently visible nested tabbed dialog below may also
> do the trick.
Fixed. Just needed to hide the current active outer tabfolder before
hiding the dialog. May also work by hiding the active inner folder but
that'd take an extra couple of lines of code and I'm too lazy to type them
in to see if they would work ;-)
> > Incidentally, I get another crash when "Save"ing my changes to this popup
> > that is "resolved" by commenting out the call
> >
> > // lv_->getLyXFunc()->Dispatch(LFUN_SCREEN_FONT_UPDATE);
> >
> > in FormPreferences::apply()
I don't see anything like that here.
Allan. (ARRae)
