Re: Bug in "include file" dialog
On Wed, 30 May 2001, John Levon wrote: > On Wed, 30 May 2001, Allan Rae wrote: > > > On Tue, 29 May 2001, John Levon wrote: > > > > > Everything else should be left for a while (say a couple of weeks) then added > > > to the bugtracker (For permanent record) and possibly a mail to the list as well > > > (I'm not sure all developers read the buglist stuff) > > > > I only have two arms, two legs, two eyes and one heartbeat. There aren't > > enough hours in the day to visit yet another something to keep track of > > bugs. Then again one day I might have the time... but not anytime soon. > > > > It's hard enough keeping up with the email. > > > > Allan. (ARRae) > > Allan, I didn't mean to criticise anyone. I was just pointing out that > the tracker isn't watched by everyone ;) Seems I left out a few ;-) or :-) and maybe a :P Allan. (ARRae)
Re: CVS build error
Juergen Vigna wrote: > > On 30-May-2001 Kayvan A. Sylvan wrote: > > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../src >-I./../ > > -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O2 -m486 > > -fno-strength-reduce -c math_macro.C > > gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost >-isystem > > /usr/X11R6/include -O2 -m486 -fno-strength-reduce -c math_macro.C -o math_macro.o > > In file included from ../../src/lyxfont.h:21, > > from ../../src/mathed/support.h:6, > > from array.h:22, > > from math_parinset.h:5, > > from math_macro.h:28, > > from math_macro.C:24: > > Already commited a fix just update! It did not fix the problem with gcc-3.0-20010528 Garst Making all in mathed make[3]: Entering directory `/usr/local/garst/lyx-devel/src/mathed' /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -c array.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -Wp,-MD,.deps/array.pp -c array.C -o array.o In file included from ../../src/debug.h:22, from array.C:8: ../../src/support/lstrings.h: In function `int compare(const char*, const char*)': ../../src/support/lstrings.h:37: `strcmp' undeclared (first use this function) ../../src/support/lstrings.h:37: (Each undeclared identifier is reported only once for each function it appears in.) ../../src/support/lstrings.h: In function `int compare(const char*, const char*, unsigned int)': ../../src/support/lstrings.h:44: `strncmp' undeclared (first use this function) array.C: In member function `void MathedArray::move(int, int)': array.C:230: `memmove' undeclared (first use this function) make[3]: *** [array.lo] Error 1 make[3]: Leaving directory `/usr/local/garst/lyx-devel/src/mathed' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/garst/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/usr/local/garst/lyx-devel/src' make: *** [all-recursive] Error 1
Re: Attempting (and failing) to compile natbib branch
On Wed, 30 May 2001, Kayvan A. Sylvan wrote: > On Thu, May 31, 2001 at 02:43:02AM +0200, Lars Gullik Bjønnes wrote: > > | > > | because downloading it via a 56k connection isn't an option :) > > > > To paraphrase Mr. Tannenbaum: > > > > "Never underestimate the bandwith of a bag full of floppydisks" > > (or alternatively, harddisks or CD's) > > There's always www.cheapbytes.com none of which I have spare pounds for (well linuxemporium.co.uk). I'll upgrade in July, grant cheque time, OK ? ;) john -- "IBM's decision to choose the Intel 80x86 processor over the Motorola 680x0 probably set the personal computer industry back 10 years." - Brian Marsden
Re: Attempting (and failing) to compile natbib branch
On Thu, May 31, 2001 at 02:43:02AM +0200, Lars Gullik Bjønnes wrote: > | > | because downloading it via a 56k connection isn't an option :) > > To paraphrase Mr. Tannenbaum: > > "Never underestimate the bandwith of a bag full of floppydisks" > (or alternatively, harddisks or CD's) There's always www.cheapbytes.com
Re: Attempting (and failing) to compile natbib branch
John Levon <[EMAIL PROTECTED]> writes: | On 31 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: | | > John Levon <[EMAIL PROTECTED]> writes: | > | > | I believe so yes. I encountered the problem with the latest 7.0 | > | rpm (-69) and confirmed it fixed in rawhide. Upgrading to 7.1 is certainly | > | a solution, but bear in mind it costs money to do so (and I can't afford | > | a spare 5 pounds after a quite expensive weekend in hamburg ;)) | > | > Upgrade costs money? how? | | because downloading it via a 56k connection isn't an option :) To paraphrase Mr. Tannenbaum: "Never underestimate the bandwith of a bag full of floppydisks" (or alternatively, harddisks or CD's) -- Lgb
lyxbugs.sf.net: admin
After jmarc's suggestion, I've removed all non-tracker perms for everyone except me, jmarc and larsbj. If anyone has access problems, just page me thanks john -- "Hey, we could invent a programming paradigm where the program is expressed as a series of statements to be executed in a fixed order." - Khendon
Re: Attempting (and failing) to compile natbib branch
On 31 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | I believe so yes. I encountered the problem with the latest 7.0 > | rpm (-69) and confirmed it fixed in rawhide. Upgrading to 7.1 is certainly > | a solution, but bear in mind it costs money to do so (and I can't afford > | a spare 5 pounds after a quite expensive weekend in hamburg ;)) > > Upgrade costs money? how? because downloading it via a 56k connection isn't an option :) but this is quite offtopic john -- "Hey, we could invent a programming paradigm where the program is expressed as a series of statements to be executed in a fixed order." - Khendon
Re: Attempting (and failing) to compile natbib branch
John Levon <[EMAIL PROTECTED]> writes: | I believe so yes. I encountered the problem with the latest 7.0 | rpm (-69) and confirmed it fixed in rawhide. Upgrading to 7.1 is certainly | a solution, but bear in mind it costs money to do so (and I can't afford | a spare 5 pounds after a quite expensive weekend in hamburg ;)) Upgrade costs money? how? | the bug is hidden currently anyway, but we should make sure to be suspicious | of crashes with 2.96-compiled versions ... mmm... sure. -- Lgb
Re: Attempting (and failing) to compile natbib branch
On 31 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | you /clearly/ ignored my mail indicating the broken behaviour in the > | particular part of tabular.C then. > > No, I saw that. But I didn't see a testcase that exibited this error. OK. I spent some time trying to derive a testcase, but gave up when I found the versions above are OK with it. > [larsbj@trylle build]$ g++ -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81) > > Is this the only 2.96 version that compiles lyx correctly? I believe so yes. I encountered the problem with the latest 7.0 rpm (-69) and confirmed it fixed in rawhide. Upgrading to 7.1 is certainly a solution, but bear in mind it costs money to do so (and I can't afford a spare 5 pounds after a quite expensive weekend in hamburg ;)) the bug is hidden currently anyway, but we should make sure to be suspicious of crashes with 2.96-compiled versions ... john -- "Hey, we could invent a programming paradigm where the program is expressed as a series of statements to be executed in a fixed order." - Khendon
Re: Attempting (and failing) to compile natbib branch
John Levon <[EMAIL PROTECTED]> writes: | you /clearly/ ignored my mail indicating the broken behaviour in the | particular part of tabular.C then. No, I saw that. But I didn't see a testcase that exibited this error. But sure something was wrong with gcc. | Never mind, a stupid flamewar | about unofficial releases will get no-one nowhere. I've made my point, | it certainly won't be me dealing with the problems we could well get | from it. [larsbj@trylle build]$ g++ -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81) Is this the only 2.96 version that compiles lyx correctly? -- Lgb
Re: Attempting (and failing) to compile natbib branch
On 30 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > I remember... the excat reason was never really discovered. Since we > failed to come up with a small test case (LyX failes is not one...), > we can't really know what was wrong. My guess is till that we do > something wrong in LyX that triggers a bug in Gcc 2.96. you /clearly/ ignored my mail indicating the broken behaviour in the particular part of tabular.C then. Never mind, a stupid flamewar about unofficial releases will get no-one nowhere. I've made my point, it certainly won't be me dealing with the problems we could well get from it. john -- "I personally think Windows NT will be the mainstream operating system within a few years." "My belief: Linux will never go mainstream." "I've always said that Linux could become a serious challenger to Microsoft's Windows NT." - Jesse Burst
Re: Attempting (and failing) to compile natbib branch
On Wed, 30 May 2001, Angus Leeming wrote: > On Tuesday 29 May 2001 23:36, [EMAIL PROTECTED] wrote: > > In spite of my whining, I thought I'd sneak in an attempt to compile > > Angus' natbib branch, since he went to the effort to merge it with the > > latest main CVS branch. I cruise along okay until I get smacked with the > > following: > > the branch doesn't yet compile, although I can now get a lot further than > you. Be patient; this stuff hasn't been touched since mid February. It's > taken me 24 commits to get as far as I have! Oops. I interpreted "configurable" to mean "compilable". My mistake. I thought that if I'd go to the effort to compile a CVS version, I might as well grab your pretty, if incomplete, natbib version. I'll be patient ... Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: patching problem ...
Dear Mr. Lasgouttes, thank you for bringing my thoughts about patches back into the right order ;-) I already thought that the patch problems would not cause real ones because the files not patchable were in the CVS tree. Anyway. As you thought, I used a fix1-patched 1.6.0 to apply the fix2. Thanks for the clarification. However, I am still not entirely satisfied with the possibility to declare an global change to the fonts. I do not think that the suggested way is intuitive. Would it be really so complicated to allow the user a decision about the fonts to be used and apply that to i. e. $HOME/.lyx/templates/defaults.lyx? I know that defining another textclass would be a solution for the problem, but this would require a lot of knowledge from the user. Is this argumentation so far from common sense? Do all of you guys live satisfied with roman fonts? I am sure you don't. But maybe you can make me understand what concept can be found behind. Thanks for your time, take care Dieter Jurzitza On 29-May-01 Jean-Marc Lasgouttes wrote: >> "Dieter" == Ing Dieter Jurzitza <[EMAIL PROTECTED]> writes: --- E-Mail: Dr. Ing. Dieter Jurzitza <[EMAIL PROTECTED]> Date: 30-May-01 Time: 20:39:35 | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / <°°__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) ---
A change to the ButtonController. Was: Re: [BUG] citation dialog
On Wednesday 30 May 2001 14:33, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> does the attached patch do what you want? If so, can I leave > Angus> this for you to apply to head and to 1.1.6? > > Close, but not perfect. If I am in a section (where Left and Block are > allowed (for an unknown reason BTW)) and select 'left', then the > center and right choices are available again. I change the title of this mail as the proposed patch changes the ButtonController and I think that Allan should be made aware of it! The problem lies (as ever) with the button controller. Specifically, the state of all widgets in the list of read_only widgets is refreshed every time we input anything. Clearly, they should be refreshed only when the read-only status of the document changes. The patch attached implements this. This may cure a lot of our problems with the ButtonController; let's hope so. This is the clean solution IMO. I think that you should test it out and, if it does as you originally desired, then it should be applied to both head and 1.1.6. Angus patch.diff.gz
Re: An ascii-only compare_no_case?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> (as an interim solution we could even have an Lars> hardcoded converter A-Z->a-z but flag the error for the user to Lars> see.) That's fine with me. If we do that, I am OK with making lyxlex case-sensitive. JMarc
string <-> lyxstring
2001-05-30 Juergen Vigna <[EMAIL PROTECTED]> * boost/config.hpp: change include of to "LString.h". I am afraid we will see more and more of these changes to be able to still use lyxstring. Hopefully there will not be enought of them to hamper updating of the external libs... -- Lgb
Re: An ascii-only compare_no_case?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> And this is exactly why I don't like it. we would have to muck | Lars> around with locale and we shouldn't really have to do that. IMHO | Lars> we should switch to beeing case sensitive. | | If we do it by hand (comparing with A-Z like in the old days) we | completely bypass the locales. as we will be by beeing case sensitive... and then we can drop the conversion also... speedier and cleaner... we just have to make LyX output good diagnostics so that it is easy to fix all problems. (as an interim solution we could even have an hardcoded converter A-Z->a-z but flag the error for the user to see.) | If we switch to be case sensitive, we will gratuitously break | compatibiliy with classes and any lyxlex-using files people may have | developped, and for little reason, IMO. I disagree. We should have done this a long time ago. And we should not be too afraid of doing changes that might impact users. -- Lgb
Re: An ascii-only compare_no_case?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> And this is exactly why I don't like it. we would have to muck Lars> around with locale and we shouldn't really have to do that. IMHO Lars> we should switch to beeing case sensitive. If we do it by hand (comparing with A-Z like in the old days) we completely bypass the locales. If we switch to be case sensitive, we will gratuitously break compatibiliy with classes and any lyxlex-using files people may have developped, and for little reason, IMO. JMarc
Re: An ascii-only compare_no_case?
> IMHO we should switch to beeing case sensitive. Sounds sensible. I always wonder why people like case insensitive languages... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: Attempting (and failing) to compile natbib branch
John Levon <[EMAIL PROTECTED]> writes: | On 30 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: | | > | | > | Are you serious? GCC-2.96 is unofficial crap! | > | > And I still do not agree... Gcc 2.96 are working close to flawlessly | > for me. And a lot better than 2.95.2... | | err, bull. Hmm... are you sitting in my chair? | Or perhaps you don't remember a few weeks back when lyx | was crashing for you on table inserts etc. ? That was a problem with | 2.96, present in neither 2.95 or 3.0-snapshot (or 2.96-82 but that's irrelevant). I remember... the excat reason was never really discovered. Since we failed to come up with a small test case (LyX failes is not one...), we can't really know what was wrong. My guess is till that we do something wrong in LyX that triggers a bug in Gcc 2.96. | > But of course I run Gcc 2.96 will all RH patches applied. | | you mean -69 ? It is buggy. Check out the resolution rawhide bugs in | bugzilla.redhat.com ! no. -- Lgb
Re: An ascii-only compare_no_case?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> One other solution would be to just define all our config files | Lars> a case sensitive. Would be a bit work to change and verify | Lars> though... | | Why not define a compare_no_case_ascii? It would do exactly what we | want, and in an explicit way. And this is exactly why I don't like it. we would have to muck around with locale and we shouldn't really have to do that. IMHO we should switch to beeing case sensitive. | Or turn compare_no_case into a template | function which accepts an optional tolower alternative (I'm sure you | will find this solution much sexyer :) no, not really. -- Lgb
Re: FormParagraph question
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 30-May-2001 Angus Leeming wrote: | | > Are the "Minipage" and "Floatflt" check buttons in FormParagraph->Extra | > mutually exclusive? If so, I'll create a "Type" choice that will have the the formParagaph->extra should be removed compleetely. | The only thing we should use in this box (and Lars surely doesn't agree | with me) is the indented paragraph stuff, as that is the only thing which | actually is no "real" hack and is used only for each single paragraph so | that it does not compromise pagebreaks and other stuff. All the other stuff | should go! has nothing to du in any "extra" section. | I think it is quite interesting to be able to give the paragraph a horizontal | offset too (the vertical offset is already in the main paragraph layout!) and | this is used a lot (at least by people I know off). what we want it the possiblity to tune paragraph styles. we should not much around hardcoding changes. If I want a "standard" paragraph with indented right margin, then I should create a "standard intented" style. but we need someone to write support for this ... -- Lgb
Re: Attempting (and failing) to compile natbib branch
On 30 May 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > | > | Are you serious? GCC-2.96 is unofficial crap! > > And I still do not agree... Gcc 2.96 are working close to flawlessly > for me. And a lot better than 2.95.2... err, bull. Or perhaps you don't remember a few weeks back when lyx was crashing for you on table inserts etc. ? That was a problem with 2.96, present in neither 2.95 or 3.0-snapshot (or 2.96-82 but that's irrelevant). > But of course I run Gcc 2.96 will all RH patches applied. you mean -69 ? It is buggy. Check out the resolution rawhide bugs in bugzilla.redhat.com ! john -- "I personally think Windows NT will be the mainstream operating system within a few years." "My belief: Linux will never go mainstream." "I've always said that Linux could become a serious challenger to Microsoft's Windows NT." - Jesse Burst
Re: Attempting (and failing) to compile natbib branch
On Sat, 3 Jan 1998, Duncan Simpson wrote: > > > > Are you serious? GCC-2.96 is unofficial crap! > > > > ... and the current version number the mainline gcc sources claim to be is > 3,1. I use 3.1 regularly and have the CVS version of gcc 2.95.x for cases when > gcc 3.x dumps core. gcc 2.96 sounds like a way of having mainline gcc with > some fixed bugs unfixxed in your version, and reportedly binary compatibility > problems. Stuff compiled with a mixture of gcc 3.x and gcc 2.95.x seems to > work fine for me... 3.1 != 3.0. You should be testing with the 3.0 branch. If that ICEs, it is imperative you report the bug (after checking for dupes of course), especially if it's a 2.95 regression. 2.96-82 and higher have behaved OK for me, but there is no (simple) way to detect the patch revision, so we must tar all 2.96's with the same brush because ... > I guess an update will appear fairly soon anyway as an official release of gcc > 3.0 is reportedly scheduled for the near future. Hopefully RH et al will put > out a gcc update shortly after that release appears. ... RH's unofficial solution to RH7.0 gcc problems is to use the supplied egcs 1.1.2 :( john -- "I personally think Windows NT will be the mainstream operating system within a few years." "My belief: Linux will never go mainstream." "I've always said that Linux could become a serious challenger to Microsoft's Windows NT." - Jesse Burst
Re: Attempting (and failing) to compile natbib branch
On Wed, 30 May 2001, Allan Rae wrote: > On Wed, 30 May 2001, Allan Rae wrote: > > > On Wed, 30 May 2001, John Levon wrote: > > > I'm not sure if that file will include additional patches from vendor. > > > If not, they're using a totally broken optimiser. I never got a response > > > on whether we should disable optimisation on gcc 2.96 or not ?? > > Actually we could perhaps provide a warning message like: > > Are you serious? GCC-2.96 is unofficial crap! > > Allan. (ARRae) > Dunno about you, but I tend to not watch ./configure output unless something goes wrong. And silent mis-compilation is a pain to debug ... john -- "I personally think Windows NT will be the mainstream operating system within a few years." "My belief: Linux will never go mainstream." "I've always said that Linux could become a serious challenger to Microsoft's Windows NT." - Jesse Burst
Re: FormParagraph question
On 30-May-2001 Angus Leeming wrote: > I'm not very familiar with Minipages, but this would require the use of a > minipage? (Not that I have a problem with that, just enquiring?) No, this just put's some extra stuff before the paragraph try it and have a look at the LaTeX output. > 3 tabbed folders > Folder 1. General: > stuff about this paragraph What is "Type" and "Indentation"? I assume that "Horizontal Alignment" changed to this from the checkboxes > Folder 2: Surrounds: > spaces, lines, pagebreaks above & below "Spaces" should remain "Vertical Spaces" IMO > Folder 3. Minipage > Can we get rid of this entirely? Is it not covered by the InsetMinipage? Yes we should get rid of this completely! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Education is the process of casting false pearls before real swine. -- Irwin Edman
Re: Bug in "include file" dialog
On Wed, 30 May 2001, Allan Rae wrote: > On Tue, 29 May 2001, John Levon wrote: > > > Everything else should be left for a while (say a couple of weeks) then added > > to the bugtracker (For permanent record) and possibly a mail to the list as well > > (I'm not sure all developers read the buglist stuff) > > I only have two arms, two legs, two eyes and one heartbeat. There aren't > enough hours in the day to visit yet another something to keep track of > bugs. Then again one day I might have the time... but not anytime soon. > > It's hard enough keeping up with the email. > > Allan. (ARRae) Allan, I didn't mean to criticise anyone. I was just pointing out that the tracker isn't watched by everyone ;) thanks john -- "I personally think Windows NT will be the mainstream operating system within a few years." "My belief: Linux will never go mainstream." "I've always said that Linux could become a serious challenger to Microsoft's Windows NT." - Jesse Burst
Re: CVS build error
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> Already commited a fix just update! Indeed. And it is better than what I was trying to do... JMarc
RE: CVS build error
On 30-May-2001 Kayvan A. Sylvan wrote: > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ > -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O2 -m486 > -fno-strength-reduce -c math_macro.C > gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost >-isystem > /usr/X11R6/include -O2 -m486 -fno-strength-reduce -c math_macro.C -o math_macro.o > In file included from ../../src/lyxfont.h:21, > from ../../src/mathed/support.h:6, > from array.h:22, > from math_parinset.h:5, > from math_macro.h:28, > from math_macro.C:24: Already commited a fix just update! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Expansion means complexity; and complexity decay.
Re: CVS build error
"Kayvan A. Sylvan" wrote: > > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ >-I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O2 -m486 >-fno-strength-reduce -c math_macro.C > gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost >-isystem /usr/X11R6/include -O2 -m486 -fno-strength-reduce -c math_macro.C -o >math_macro.o > In file included from ../../src/lyxfont.h:21, > from ../../src/mathed/support.h:6, > from array.h:22, > from math_parinset.h:5, > from math_macro.h:28, > from math_macro.C:24: > ../../src/LString.h:20: #error The header has been included before LString.h > make[4]: *** [math_macro.lo] Error 1 > make[4]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs/src/mathed' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs/src' > make[2]: *** [all-recursive-am] Error 2 > make[2]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs' > Bad exit status from /var/tmp/rpm-tmp.91231 (%build) > make: *** [rpmdist] Error 1 > > BUILD FAILED: lyx rpm With gcc-3.0 20010528 I get the failure found in the attached make.log cvs update 11AM US EST Making all in mathed make[3]: Entering directory `/usr/local/garst/lyx-devel/src/mathed' /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -c array.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -Wp,-MD,.deps/array.pp -c array.C -o array.o In file included from ../../src/debug.h:22, from array.C:8: ../../src/support/lstrings.h: In function `int compare(const char*, const char*)': ../../src/support/lstrings.h:37: `strcmp' undeclared (first use this function) ../../src/support/lstrings.h:37: (Each undeclared identifier is reported only once for each function it appears in.) ../../src/support/lstrings.h: In function `int compare(const char*, const char*, unsigned int)': ../../src/support/lstrings.h:44: `strncmp' undeclared (first use this function) array.C: In member function `void MathedArray::move(int, int)': array.C:230: `memmove' undeclared (first use this function) make[3]: *** [array.lo] Error 1 make[3]: Leaving directory `/usr/local/garst/lyx-devel/src/mathed' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/garst/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/usr/local/garst/lyx-devel/src' make: *** [all-recursive] Error 1
Re: www.lyx.org
On Wed, May 30, 2001 at 10:30:56PM +1200, Michael Koziarski wrote: > > Some browsers choke on XHTML, though. AOL's browser, old versions > > of Netscape, and IE4. > > Kayvan, > > Is this documented anywhere? I'd be interested to know what causes > the failure. There is some mention in the CGI.pm perl module about this (the -no_xhtml flag came about because of it). Just create an XHTML page and try to view it with IE4 and you will see. The browser will just show you the source and not try to render it. I don't know what causes it other than that the browser is stupid! ;-) ---Kayvan
Re: CVS build error
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: I am in the process of fixing this. JMarc
CVS build error
/bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O2 -m486 -fno-strength-reduce -c math_macro.C gcc -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O2 -m486 -fno-strength-reduce -c math_macro.C -o math_macro.o In file included from ../../src/lyxfont.h:21, from ../../src/mathed/support.h:6, from array.h:22, from math_parinset.h:5, from math_macro.h:28, from math_macro.C:24: ../../src/LString.h:20: #error The header has been included before LString.h make[4]: *** [math_macro.lo] Error 1 make[4]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs/src/mathed' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs/src' make[2]: *** [all-recursive-am] Error 2 make[2]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/rpm/BUILD/lyx-1.2.0cvs' Bad exit status from /var/tmp/rpm-tmp.91231 (%build) make: *** [rpmdist] Error 1 BUILD FAILED: lyx rpm -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: FormParagraph question
On Wednesday 30 May 2001 15:26, Juergen Vigna wrote: > On 30-May-2001 Angus Leeming wrote: > > > Are the "Minipage" and "Floatflt" check buttons in FormParagraph->Extra > > mutually exclusive? If so, I'll create a "Type" choice that will have the > > The only thing we should use in this box (and Lars surely doesn't agree > with me) is the indented paragraph stuff, as that is the only thing which > actually is no "real" hack and is used only for each single paragraph so > that it does not compromise pagebreaks and other stuff. All the other stuff > should go! > > I think it is quite interesting to be able to give the paragraph > a horizontal offset too (the vertical offset is already in the > main paragraph layout!) and this is used a lot (at least by people > I know off). I'm not very familiar with Minipages, but this would require the use of a minipage? (Not that I have a problem with that, just enquiring?) Here's a suggested new Paragraph dialog. It doesn't address the points you raise and it is a first attempt only. Care to comment? Where would you put the additional items? 3 tabbed folders Folder 1. General: stuff about this paragraph Folder 2: Surrounds: spaces, lines, pagebreaks above & below Folder 3. Minipage Can we get rid of this entirely? Is it not covered by the InsetMinipage? Note that all the inputs have an associated choice for the correct units. The inputs would acept integers only. Angus form_paragraph.fd.gz
RE: FormParagraph question
On 30-May-2001 Angus Leeming wrote: > Are the "Minipage" and "Floatflt" check buttons in FormParagraph->Extra > mutually exclusive? If so, I'll create a "Type" choice that will have the The only thing we should use in this box (and Lars surely doesn't agree with me) is the indented paragraph stuff, as that is the only thing which actually is no "real" hack and is used only for each single paragraph so that it does not compromise pagebreaks and other stuff. All the other stuff should go! I think it is quite interesting to be able to give the paragraph a horizontal offset too (the vertical offset is already in the main paragraph layout!) and this is used a lot (at least by people I know off). 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The curse of the Irish is not that they don't know the words to a song -- it's that they know them *__all*. -- Susan Dooley
FormParagraph question
I've been re-designinging the FormParagraph dialog as something quick and easy to do, but I have a question: Are the "Minipage" and "Floatflt" check buttons in FormParagraph->Extra mutually exclusive? If so, I'll create a "Type" choice that will have the entries: Normal | Minipage | Floatflt Another question: when is the "vertical alignment" used? By any paragraph? or is this Minipage-specific? Angus
Re: An ascii-only compare_no_case?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> One other solution would be to just define all our config files Lars> a case sensitive. Would be a bit work to change and verify Lars> though... Why not define a compare_no_case_ascii? It would do exactly what we want, and in an explicit way. Or turn compare_no_case into a template function which accepts an optional tolower alternative (I'm sure you will find this solution much sexyer :) JMarc
Re: Attempting (and failing) to compile natbib branch
On Wed, May 30, 2001 at 11:07:55AM +0200, Lars Gullik Bjønnes wrote: > Juergen Vigna <[EMAIL PROTECTED]> writes: > > | On 30-May-2001 Lars Gullik Bjønnes wrote: > | > | > And I still do not agree... Gcc 2.96 are working close to flawlessly > | > for me. And a lot better than 2.95.2... > | > | I agree with this! I can only agree with this. > | > But of course I_run Gcc 2.96 will all RH patches applied. > | > | Well I use RH 7.1 and there are still no gcc patches for this ;) > | (and I really think people using 7.0 should update to 7.1 it's 1/2 > | an hour, but it's worth that time :) > > Agree I did the same thing. I hate the me too, but "me too". It is the best system I have ever used. BTW, this was discussed in this list several times before. Most of the critics to gcc-2.96 that were posted in this thread have a week basis. Please look to http://www.bero.org/gcc296.html for a rebuttal. > -- > Lgb -- José
Re: An ascii-only compare_no_case?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> what if... we let compare_no_case convert to uppercase
| Lars> intarnally instead of to lowercase? wouldn't that solve the
| Lars> problem?
|
| This will break things because _ will not be sorted correctly in our
| tag tables (which are sorted for lowercase).
|
| Lars> with turkish locale what is toupper('i')?
|
| It is a I with a point on it, I believe.
|
| Anyway, I am surprised that somebody like you who always championned
| clean solutions against hacks would propose such a kludge. I'll do as
| if I did not read the message :)
kludge?
By far the most unintrusive solution if the turhish locale behaved
well towars us...
The problems boils down to charsets and locales...
the solution is to use _no_ locale for most things...
even unicode would not solve this problem...
One other solution would be to just define all our config files a case
sensitive. Would be a bit work to change and verify though...
--
Lgb
Re: An ascii-only compare_no_case?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> what if... we let compare_no_case convert to uppercase
Lars> intarnally instead of to lowercase? wouldn't that solve the
Lars> problem?
This will break things because _ will not be sorted correctly in our
tag tables (which are sorted for lowercase).
Lars> with turkish locale what is toupper('i')?
It is a I with a point on it, I believe.
Anyway, I am surprised that somebody like you who always championned
clean solutions against hacks would propose such a kludge. I'll do as
if I did not read the message :)
JMarc
Re: An ascii-only compare_no_case?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> mmm... we should switch off turkish locale then. afaik LyX only
| Lars> needs locale in GUI, the core should really run with C locale
| Lars> all the time.
|
| Lars> How does gettext react to changes n locacle? Does it care and
| Lars> resets to the new locale?
|
| I think it does. At least it sees changes in LC_MESSAGES:
|
| One things which should come into mind is that no explicit
| dependency to the used domain is given. The current value of the
| domain for the `LC_MESSAGES' locale is used. If this changes between
| two executions of the same `gettext' call in the program, both calls
| reference a different message catalog.
|
| Of course, we are concerned here by the LC_CTYPE locale. We probably
| do not want to reset it to 'C' unconditionally, since it is used for
| case-changing at other places. I do not know however if
| compare_no_case needs the real locale for some calls.
what if...
we let compare_no_case convert to uppercase intarnally instead of to
lowercase? wouldn't that solve the problem?
with turkish locale what is toupper('i')?
--
Lgb
Re: [BUG] citation dialog
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> does the attached patch do what you want? If so, can I leave Angus> this for you to apply to head and to 1.1.6? Close, but not perfect. If I am in a section (where Left and Block are allowed (for an unknown reason BTW)) and select 'left', then the center and right choices are available again. JMarc
Re: An ascii-only compare_no_case?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> mmm... we should switch off turkish locale then. afaik LyX only Lars> needs locale in GUI, the core should really run with C locale Lars> all the time. Lars> How does gettext react to changes n locacle? Does it care and Lars> resets to the new locale? I think it does. At least it sees changes in LC_MESSAGES: One things which should come into mind is that no explicit dependency to the used domain is given. The current value of the domain for the `LC_MESSAGES' locale is used. If this changes between two executions of the same `gettext' call in the program, both calls reference a different message catalog. Of course, we are concerned here by the LC_CTYPE locale. We probably do not want to reset it to 'C' unconditionally, since it is used for case-changing at other places. I do not know however if compare_no_case needs the real locale for some calls. JMarc
Re: Why docs don't get updated very often Re: asciitilde binding
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> the inset you are speaking of have no need f.ex. for the | Lars> multiparagraph support in InsetText. | | Yes, I agree. However, when this wonderful insetmbox exists, it will | be very easy to switch to that :) and since it is not done right from the beginning, it will never be done... -- Lgb
Re: Why docs don't get updated very often Re: asciitilde binding
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> the inset you are speaking of have no need f.ex. for the Lars> multiparagraph support in InsetText. Yes, I agree. However, when this wonderful insetmbox exists, it will be very easy to switch to that :) JMarc
Re: An ascii-only compare_no_case?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I guess this one is for Lars. | | We have a bug, where people running with turkish locales cannot run | LyX because lyxlex gets confused by the fact that 'i' is not the lower | case variant of 'I' (the lowercase is dotlessi). This means many tags | are not recognized. The solution is to use a compare_no_case that only | looks at characters in [A-Za-z]. Before I begin to write ugly code, is | there an 'elegant' way to do this, other that writing a | compare_no_case_ascii that does by hand lowercasing? mmm... we should switch off turkish locale then. afaik LyX only needs locale in GUI, the core should really run with C locale all the time. How does gettext react to changes n locacle? Does it care and resets to the new locale? -- Lgb
Re: Why docs don't get updated very often Re: asciitilde binding
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> No but we should perhaps create one... | | And what would that be exactly? More to the point, what is the problem | with subclassing insettext? Just that you feel it is not right? I do | not see speed or memeory problems happen due to this. And code reuse | would be very high :) yes, but code reuse would bo in wrong direction: complex->simple instead of maing a simpler inset that insetext could build on: simple->complex the inset you are speaking of have no need f.ex. for the multiparagraph support in InsetText. -- Lgb
Re: [BUG] citation dialog
On Friday 25 May 2001 17:06, Jean-Marc Lasgouttes wrote: > Thanks. While we are at it, another wish: in the paragraph layout > form, the align buttons should be disabled depending on the > AlignPossible entry in the Layout. Could you do that? It would give a > much better feedback to users. > Angus> Is this HEAD or BRANCH_1_1_6? Angus > Head is obvously the most important, but &.1.6 would be nice too. > JMarc, starring at the sea with his laptop on his lap, as it should... ;-) Jean-Marc, does the attached patch do what you want? If so, can I leave this for you to apply to head and to 1.1.6? Cheers, Angus patch.diff.gz
An ascii-only compare_no_case?
I guess this one is for Lars. We have a bug, where people running with turkish locales cannot run LyX because lyxlex gets confused by the fact that 'i' is not the lower case variant of 'I' (the lowercase is dotlessi). This means many tags are not recognized. The solution is to use a compare_no_case that only looks at characters in [A-Za-z]. Before I begin to write ugly code, is there an 'elegant' way to do this, other that writing a compare_no_case_ascii that does by hand lowercasing? JMarc
Re: Why docs don't get updated very often Re: asciitilde binding
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> No but we should perhaps create one... And what would that be exactly? More to the point, what is the problem with subclassing insettext? Just that you feel it is not right? I do not see speed or memeory problems happen due to this. And code reuse would be very high :) JMarc
Re: More bugs (fwd)
Michael Schmitt <[EMAIL PROTECTED]> writes: | 2. Insert a figure float into a document, then insert a minipage into the |float. Enter some TeX code in the minipage (use CTRL+Returns). Move the |cursor (leave the minipage, enter it again, etc.) and try to |select/cut/paste some text from time to time. After a few operations you |will notice that the text selection is not correct any longer (the wrong |selection is marked). | | 10. When cutting normal text (no floats, no minipages, just plain text), | the cursor is not moved correctly. Instead it stays at the same position | (on screen). This is, of course, wrong. The cursor should be moved right | in front of the text which has been cut. | | ARGHH. THIS IS CRITICAL -> LyX crashes after a several operations! I just fixed a serious bug in CutSelection so can you please test the selection bugs that you found again? (just let me commit first) | 11. During compilation "gcc -Wall" reports a couple of warnings that | might be fixed. Please list them. -- Lgb
Re: Why docs don't get updated very often Re: asciitilde binding
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> I still think InsetText is too complex for that use. We should | Lars> rather create a InsetMbox variant... | | Do we have an InsetMBox? No but we should perhaps create one... -- Lgb
Re: Why docs don't get updated very often Re: asciitilde binding
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I still think InsetText is too complex for that use. We should Lars> rather create a InsetMbox variant... Do we have an InsetMBox? JMarc
Re: Why docs don't get updated very often Re: asciitilde binding
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Won't InsetText be a bit overkill for this? | | Lars> This is closer to InsetLabel... | | For the case of a key binding, insettext is not needed (and I did not | plan to use it). But if I want to do some formatting, it seems to me | that insttext is the easiest way (do I really want to write/test an | draw() method which adds the underlines at the right place, draws the | nice menu separator and generates latex/smgl? I still think InsetText is too complex for that use. We should rather create a InsetMbox variant... -- Lgb
Re: Why docs don't get updated very often Re: asciitilde binding
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Won't InsetText be a bit overkill for this? Lars> This is closer to InsetLabel... For the case of a key binding, insettext is not needed (and I did not plan to use it). But if I want to do some formatting, it seems to me that insttext is the easiest way (do I really want to write/test an draw() method which adds the underlines at the right place, draws the nice menu separator and generates latex/smgl? JMarc
Re: Why docs don't get updated very often Re: asciitilde binding
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: | | Juergen> Well yes this should be possible, but I still don't get what | Juergen> you really want to do with it! | | The idea would be, in the docs, to do an | M-x menuinset-insert lyx-quit | and have a nice box on the screen showing "_File>_Quit". This way, the | docs (and especially the reference guide) would be much easier to | maintain. Similarly, we could have an InsetBinding which would display | "C-x C-c". Won't InsetText be a bit overkill for this? This is closer to InsetLabel... -- Lgb
Re: Why docs don't get updated very often Re: asciitilde binding
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> Well yes this should be possible, but I still don't get what Juergen> you really want to do with it! The idea would be, in the docs, to do an M-x menuinset-insert lyx-quit and have a nice box on the screen showing "_File>_Quit". This way, the docs (and especially the reference guide) would be much easier to maintain. Similarly, we could have an InsetBinding which would display "C-x C-c". JMarc
Re: Why docs don't get updated very often Re: asciitilde binding
On 30-May-2001 Jean-Marc Lasgouttes wrote: >> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: > > Juergen> I don't get to what exactly you need, but surely one can make > Juergen> a MenuInset based on InsetText and not Editable. > > Doing an inset for key bindings is easy, since it will just contain > plain text. For a menu, it will be more difficult, since I'll have to > play with fonts (underline) and add special chars (menu separators). > So it seems easier to me to build an insettext automatically with the > right content. Then this insettext should not be editable at all (not > even navigation with cursor). I guess this can be obtained by > overloading the Editable() method of InsetText. Do you think this will > be enough. Well yes this should be possible, but I still don't get what you really want to do with it! > Probably an interesting small project for next meeting. Maybe (if it is as you said it should be really small ;) 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's a brave man who, when things are at their darkest, can kick back and party! -- Dennis Quaid, "Inner Space"
Re: Why docs don't get updated very often Re: asciitilde binding
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> I don't get to what exactly you need, but surely one can make Juergen> a MenuInset based on InsetText and not Editable. Doing an inset for key bindings is easy, since it will just contain plain text. For a menu, it will be more difficult, since I'll have to play with fonts (underline) and add special chars (menu separators). So it seems easier to me to build an insettext automatically with the right content. Then this insettext should not be editable at all (not even navigation with cursor). I guess this can be obtained by overloading the Editable() method of InsetText. Do you think this will be enough. Probably an interesting small project for next meeting. JMarc
Re: Why docs don't get updated very often Re: asciitilde binding
On 30-May-2001 Jean-Marc Lasgouttes wrote: > The idea I had for menus was to subclass a non-editable version of > insettext (does this exist) so that a small insettext (with underlines > at the right place and nice menu separators and maybe even the sans > serif font) would be created on the fly. Juergen, would something like > that be doable with the current insettext? ??? I don't get to what exactly you need, but surely one can make a MenuInset based on InsetText and not Editable. 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ In charity there is no excess. -- Francis Bacon
Re: Why docs don't get updated very often Re: asciitilde binding bug
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Sure menus are for _loosers_! The idea I had for menus was to subclass a non-editable version of insettext (does this exist) so that a small insettext (with underlines at the right place and nice menu separators and maybe even the sans serif font) would be created on the fly. Juergen, would something like that be doable with the current insettext? JMarc
natbib branch now working
nuff said... Angus
Re: compose key not working in CVS
Lars Gullik Bjønnes wrote: > > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bjønnes wrote: > | > > | > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > | > > | > | WorkArea: Keysym is `Multi_key' [65312] > | > | Workarea event: KEYBOARD > Compose+c+r = > Compose+c+o = © (copyright) > Compose+o+c = © (copyright) > Compose+O+R = ® (registered) > > There are no c+r combination in my compose file. > > Without further evidence I belive LyX is doing things right now. > > -- > Lgb Doh, sorry. Garst
Re: Why docs don't get updated very often Re: asciitilde binding bug
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Even if this inset would seemingly make things easier I do not | Lars> quite agree with it. IMO the bindings are not athorative, the | Lars> lyxfuns are. So the bindings can be referenced in the main text, | Lars> but the main focus should be on lfuns, the excact up to date | Lars> bindings should go in an appendix. | | Your are not telling us that the menu entries should be in appendix | too, are you? Sure menus are for _loosers_! The only correct way of gettinging something done is to write small scriptes that pipes commands to the lyx-server! | However, I agree about the key bindings in main docs | (especially now that they are visible in menus). However, having the | key bindings and menu entries in reference.lyx would be great, and | some automated scheme is the best way to keep them up to date. yes. -- Lgb
lyx::sum
I have one futher change, that should make things faster.
Using the unformatted input iterators instead of the ones working on
formatted input, this is the test:
#include
#include
int main(int, char *argv[])
{
std::ifstream ifs(file.c_str());
if (!ifs) return 0;
std::istreambuf_iterator beg(ifs);
std::istreambuf_iterator end;
int count = 0;
for (; beg != end; ++beg)
++count;
std::cout << count << std::endl;
}
My testing shows that on a 60Meg file:
isteambuf_iterator: ~5 secs
istream_iterator : ~19 secs
sstream : ~21 secs
in a 300K file:
istreambuf_iterator: ~0.042s
istream_iterator : ~0.100s
sstream: ~0.093s
Unfortunately gcc 2.95.x does not have istreambuf_iterator, so we need
some configure magic to use this. I'll add this.
--
Lgb
Re: Why docs don't get updated very often Re: asciitilde binding bug
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Even if this inset would seemingly make things easier I do not Lars> quite agree with it. IMO the bindings are not athorative, the Lars> lyxfuns are. So the bindings can be referenced in the main text, Lars> but the main focus should be on lfuns, the excact up to date Lars> bindings should go in an appendix. Your are not telling us that the menu entries should be in appendix too, are you? However, I agree about the key bindings in main docs (especially now that they are visible in menus). However, having the key bindings and menu entries in reference.lyx would be great, and some automated scheme is the best way to keep them up to date. JMarc
Some serious bugs
Hi everybody,
enclosed please find a short document that causes me a lot of headaches.
(PS: The table has been imported with reLyX. It is real stuff, not an
esoteric example)
1. Open the file
2. Try to replace " (X) " (X=Number) with "X:"
-> the cells are not displayed correctly
3. Try to remove the complete figure from the document
-> lyx crashes
4. Try to change the language of the cell texts
-> lyx crashes
5. Try to replace all \hspace{...} by protected blanks
-> lyx crashes eventually
6. Try to set the font size to "smaller" for one cell
-> doesn't work
7. Try to change the character layout for all cells
-> doesn't work
8. Move the cursor down the table
-> it will reappear at the beginning of the document
(not after the table)
Any help is greatly appreciated.
Kind regards, Michael
--
==
Michael Schmittphone: +49 451 500 3725
Institute for Telematics secretary: +49 451 500 3721
Medical University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de
==
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 218
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset Float figure
placement htbp
collapsed false
\layout Standard
\begin_inset Tabular
\begin_inset Text
\layout Standard
(1)
\end_inset
\begin_inset Text
\layout Standard
testgen_ptc(
\begin_inset Formula \( i \)
\end_inset
,
\begin_inset Formula \( state_{sim} \)
\end_inset
,
\begin_inset Formula \( state_{test} \)
\end_inset
)
\end_inset
\begin_inset Text
\layout Standard
(2)
\end_inset
\begin_inset Text
\layout Standard
{
\end_inset
\begin_inset Text
\layout Standard
(3)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{3mm}
\latex default
\begin_inset Formula \( E \)
\end_inset
:= next_events(
\begin_inset Formula \( state_{sim} \)
\end_inset
);
\end_inset
\begin_inset Text
\layout Standard
(4)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{3mm}
\latex default
if (
\begin_inset Formula \( \exists e\in E: \)
\end_inset
\begin_inset Formula \( e \)
\end_inset
=
\begin_inset Formula \( pco \)
\end_inset
!
\begin_inset Formula \( sig \)
\end_inset
\begin_inset Formula \( \land \)
\end_inset
\begin_inset Formula \( pco\in PCO_{i} \)
\end_inset
)
\end_inset
\begin_inset Text
\layout Standard
(5)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{3mm}
\latex default
{
\end_inset
\begin_inset Text
\layout Standard
(6)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{6mm}
\latex default
\begin_inset Formula \( nextstate_{test} \)
\end_inset
:= add_trans(
\begin_inset Formula \( state_{test} \)
\end_inset
,
\begin_inset Formula \( e \)
\end_inset
);
\end_inset
\begin_inset Text
\layout Standard
(7)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{6mm}
\latex default
testgen_ptc(
\begin_inset Formula \( i \)
\end_inset
,next_state(
\begin_inset Formula \( state_{sim} \)
\end_inset
,
\begin_inset Formula \( e \)
\end_inset
),
\begin_inset Formula \( nextstate_{test} \)
\end_inset
);
\end_inset
\begin_inset Text
\layout Standard
(8)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{3mm}
\latex default
}
\end_inset
\begin_inset Text
\layout Standard
(9)
\end_inset
\begin_inset Text
\layout Standard
\latex latex
\backslash
hspace*{3mm}
\latex default
else if (
\begin_inset Formula \( \exists e\in E: \)
\end_inset
\begin_inset Formula \( e \)
\end_inset
= enter_sync(
\begin_inset Formula \( id \)
\end_inset
,
\begin_inset Formula \( pco \)
\end_inset
,
\begin_inset Formula \( Cur \)
\end_inset
,
\begin_inset Formula \( All \)
\end_inset
)
\begin_inset Formula \( \lan
Re: Attempting (and failing) to compile natbib branch
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 30-May-2001 Lars Gullik Bjønnes wrote: | | > And I still do not agree... Gcc 2.96 are working close to flawlessly | > for me. And a lot better than 2.95.2... | | I agree with this! | | > But of course I_run Gcc 2.96 will all RH patches applied. | | Well I use RH 7.1 and there are still no gcc patches for this ;) | (and I really think people using 7.0 should update to 7.1 it's 1/2 | an hour, but it's worth that time :) Agree I did the same thing. -- Lgb
Re: Bug in "include file" dialog
On 30-May-2001 Jean-Marc Lasgouttes wrote: > John> Everything else should be left for a while (say a couple of > John> weeks) then added to the bugtracker (For permanent record) and > John> possibly a mail to the list as well (I'm not sure all developers > John> read the buglist stuff) > > Well you can always decide to assign the bug to a given developper, in > order to harass him if you think he is not working enough :) And I won't mind if tabular and insttext bugs are assigned to me (therefore I assigned them the other day) it's easier to me to find out what important things I have to do! (Also you get automatically notified of any changes to this bug-reports if there are some). 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Ada is PL/I trying to be Smalltalk. -- Codoso diBlini
Re: Why docs don't get updated very often Re: asciitilde binding bug
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I also had a few ideas on how to simplify somewhat the documenter's | work, like an inset that displays the keybinding of a given function, | or even the menu entry corresponding to this lyxfunc. I guess this | could help getting the doc up to date (although it will not do | wonders). Even if this inset would seemingly make things easier I do not quite agree with it. IMO the bindings are not athorative, the lyxfuns are. So the bindings can be referenced in the main text, but the main focus should be on lfuns, the excact up to date bindings should go in an appendix. -- Lgb
Re: Bolzano, here I come
On 30-May-2001 Allan Rae wrote: > Assuming you have your phone turned on and within hearing distance. I > seem to recall someone calling your mobile 6 times a day for three days > before arriving at the Bozen train station early one morning and luckily > getting you on the phone (after 3 more attempts and calling every Vigna in > the phone book!) Well give me a break you told me you would warn me by email and I was checking my email on "hourly" (more or less ;) basis, so I thought you liked Paris and Jean-Marc's ospitality (he told me he always has a good bottle of wine at home ;P ) so much you would have liked to stay longer ;) 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ This fortune is inoperative. Please try another.
Re: compose key not working in CVS
On 30-May-2001 Garst R. Reese wrote: > OK, I tried S-O S-R and that got me the registered trade mark symbol. That's what I wanted to write right now. Compose c r does nothing on my Workstation (in any X application) only compose o c does produce ©. 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Each honest calling, each walk of life, has its own elite, its own aristocracy based on excellence of performance. -- James Bryant Conant
Re: Attempting (and failing) to compile natbib branch
On 30-May-2001 Lars Gullik Bjønnes wrote: > And I still do not agree... Gcc 2.96 are working close to flawlessly > for me. And a lot better than 2.95.2... I agree with this! > But of course I_run Gcc 2.96 will all RH patches applied. Well I use RH 7.1 and there are still no gcc patches for this ;) (and I really think people using 7.0 should update to 7.1 it's 1/2 an hour, but it's worth that time :) 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I used to be an agnostic, but now I'm not so sure.
Re: Sourceforge?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> I'm not sure what you mean by security risk ? All is https. The John> only real content are the actual bug reports anyway, and any of John> us should be able to close bugs. Well, just as for cvs, I think it is a good idea to restrict who can do what. It avoids configuration headaches, methinks. JMarc
Re: Please upgrade libtool in lyx
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> I'll do it. | | Then I'll take a look at gettext 0.10.38. Yes, please do. And while you are at it... fix the error in fr.po. Run the validation inside emacs to find the error. -- Lgb
Re: Bug in "include file" dialog
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Everything else should be left for a while (say a couple of John> weeks) then added to the bugtracker (For permanent record) and John> possibly a mail to the list as well (I'm not sure all developers John> read the buglist stuff) Well you can always decide to assign the bug to a given developper, in order to harass him if you think he is not working enough :) JMarc
Re: compose key not working in CVS
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > | > "Garst R. Reese" <[EMAIL PROTECTED]> writes: | > | > | WorkArea: Keysym is `Multi_key' [65312] | > | Workarea event: KEYBOARD | > | WorkArea: Key is `' [0] | > | WorkArea: Keysym is `c' [99] | > | Workarea event: KEYBOARD | > | WorkArea: Key is `' [0] | > | WorkArea: Keysym is `r' [114] | > | Running QuitLyX. | > | > What is Compose+c+r supposed to produce? | > | > -- | > Lgb | OK, I tried S-O S-R and that got me the registered trade mark symbol. | Garst | Compose+c+r = Compose+c+o = © (copyright) Compose+o+c = © (copyright) Compose+O+R = ® (registered) There are no c+r combination in my compose file. Without further evidence I belive LyX is doing things right now. -- Lgb
RE: Why docs don't get updated very often Re: asciitilde binding
On 29-May-2001 [EMAIL PROTECTED] wrote: > Perhaps it's time for an Errata page on the Web. Anyone with Web CVS > access willing to lead the charge? Good we have the doc-team working again ;) IMO we should really try to update the documentation a bit regarding all the new and changed stuff from 1.1.6 and 1.2.0 before releasing a 1.2.0 final version. If this means waiting a bit until you can do the job IMO we should wait! Jürgen P.S.: As always I'm open for any explanation you need about the new code, just please make direkt questions of stuff you don't understand or you're not too familiar with! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ question = ( to ) ? be : ! be; -- Wm. Shakespeare
Re: Pre-release 'offical' debs (was Re: [ANNOUNCE] LyX 1.1.6fix2)
> "Paul" == Paul Seelig <[EMAIL PROTECTED]> writes: Paul> I thought libforms0.89 was deprecated for compilation by the LyX Paul> developers? Well, 0.89.x is not an official release, but since nothing has happened for a long time, it is better to use it... In fact, there are no serious problems in 0.89.6 wrt 0.88.1. So using 0.89.6 is probably the best choice. JMarc
Re: Pre-release 'offical' debs (was Re: [ANNOUNCE] LyX 1.1.6fix2)
> "Chanop" == Chanop Silpa-Anan <[EMAIL PROTECTED]> writes: Chanop> I still get the same problem here, a big delay in calling Chanop> latex with lyx1.1.6 (cvs one) compiled with gcc-2.95_2.95.4-1 Chanop> and libstdc++2.10-glibc2.2_2.95.4-0.010522. I don't know why Chanop> Jules does not have the problem though, may be gcc. I really think the problem is in libstdc++2.10. JMarc
Re: Why docs don't get updated very often Re: asciitilde binding bug
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> This brought up the idea of an Errata section on Mike> the Web. At least we can collect the current inconsistencies and Mike> make them known there, so the Users don't get totally frustrated Mike> with the current situation. Note also that a good place to put documentation errors is the bug system at sourceforge. I think there is a "Documentation" category there, and it is a good way to keep trace of what changes should be done. You could maybe encourage people to post all the inconsistencies they know about there. I also had a few ideas on how to simplify somewhat the documenter's work, like an inset that displays the keybinding of a given function, or even the menu entry corresponding to this lyxfunc. I guess this could help getting the doc up to date (although it will not do wonders). JMarc
Re: current CVS and gcc 3.0 compile problem
John Levon <[EMAIL PROTECTED]> writes: | /usr/gcc3.0/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost |-isystem /usr/X11R6/include -g -O -W -Wall -Wp,-MD,.deps/lyxsum.pp -c lyxsum.C -o | lyxsum.o | /usr/gcc3.0/include/g++-v3/bits/stl_iterator.h: In constructor |`std::istream_iterator<_Tp, _Dist>::istream_iterator() [with _Tp = char, | _Dist = ptrdiff_t]': | lyxsum.C:118: instantiated from here | /usr/gcc3.0/include/g++-v3/bits/stl_iterator.h:857: `cin' undeclared (first use | this function) |/usr/gcc3.0/include/g++-v3/bits/stl_iterator.h:857: (Each undeclared |identifier | is reported only once for each function it appears in.) | make: *** [lyxsum.lo] Error 1 I guess this should be reported as a bug to the g++-v3 people. We should not manually have to include to be able to use with I'll have a look at this. -- Lgb
Re: [PATCH] fix bug 228457
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> They convert hard spaces into hard tabs so everyone can have John> their favoured tabsize. That's OK, then. JMarc
Re: Please upgrade libtool in lyx
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I'll do it. Then I'll take a look at gettext 0.10.38. JMarc
Re: wrong paragraphs when changing textclass in 1.1.6fix1 and cvs
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> i had a look at it and this never happend in 1.1.6fix2 ... Very good. Keep your eyes open in case this happens again... JMarc
Re: Attempting (and failing) to compile natbib branch
Allan Rae <[EMAIL PROTECTED]> writes: | On Wed, 30 May 2001, Allan Rae wrote: | | > On Wed, 30 May 2001, John Levon wrote: | > > I'm not sure if that file will include additional patches from vendor. | > > If not, they're using a totally broken optimiser. I never got a response | > > on whether we should disable optimisation on gcc 2.96 or not ?? | | Actually we could perhaps provide a warning message like: | | Are you serious? GCC-2.96 is unofficial crap! And I still do not agree... Gcc 2.96 are working close to flawlessly for me. And a lot better than 2.95.2... But of course I run Gcc 2.96 will all RH patches applied. -- Lgb
Re: Attempting (and failing) to compile natbib branch
On Tuesday 29 May 2001 23:36, [EMAIL PROTECTED] wrote: > In spite of my whining, I thought I'd sneak in an attempt to compile > Angus' natbib branch, since he went to the effort to merge it with the > latest main CVS branch. I cruise along okay until I get smacked with the > following: Returning to the main thread of this message... (;-) Mike, the branch doesn't yet compile, although I can now get a lot further than you. Be patient; this stuff hasn't been touched since mid February. It's taken me 24 commits to get as far as I have! I'll post a message once it's up again. Angus PS I'm proposing only to get the branch functioning again, not to do any serious work on it. V, v busy at present. A
Re: Pre-release 'offical' debs (was Re: [ANNOUNCE] LyX 1.1.6fix2)
Once upon a time, I heard Chanop Silpa-Anan say > > > It's good that you put together the deb. However, I still experienced the > > > slowness when lyx calls latex from this deb. Do you have this problem on > > > your box with this deb? The only way I can get lyx to run properly (both >1.1.6fix2 and 1.2.0cvs) is to use gcc-3.0. My locally compiled lyx-1.1.6fix2 > > > (with gcc-3.0) works pretty well. You might consider recompile lyx with > > > gcc-3.0 to work around the slownes instead of exporting to latex and > > > compile by hand. > > > > I don't see this problem locally at all. I'm using gcc 2.95.2-14 and > > libstdc++ 2.95.3-6. > > I did compile with gcc 2.95.3 and 2.95.4. May be that is the problem. I'll > check it again with the current upload of gcc 2.95.4. I still get the same problem here, a big delay in calling latex with lyx1.1.6 (cvs one) compiled with gcc-2.95_2.95.4-1 and libstdc++2.10-glibc2.2_2.95.4-0.010522. I don't know why Jules does not have the problem though, may be gcc. Cheers, Chanop -- ## #Chanop Silpa-Anan # #gpg @ http://dynax.anu.edu.au/chanop.asc# ##
