RE: xforms older than 0.88
On 21-Dec-1999 Lars Gullik Bjønnes wrote: > > Unless I hear _very_ strong objections I will remove all support for > XForms versions older thatn 0.88 after 1.1.4 is released. No objections at all :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienstr. 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug If you think the problem is bad now, just wait until we've solved it. -- Arthur Kasspe -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: xforms older than 0.88
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 21-Dec-1999 Lars Gullik Bjønnes wrote: >> Unless I hear _very_ strong objections I will remove all support >> for XForms versions older thatn 0.88 after 1.1.4 is released. Juergen> No objections at all :) Neither from me. JMarc PS: welcome back indeed, Juergen.
Re: namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Does namespace support work on all the compilers that the 1.1.x Lars> series currently compiles on? gcc 2.8.1: fantomas: g++ -Wall -ansi -pedantic nsp.C nsp.C:1: sorry, not implemented: namespace cxx 6.1: OK. Lars> IMO if this works we should begin using a LyX namespace right Lars> away. We have already had the sqrt clash. I'd rather avoid it for now :) JMarc
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> In gcc 2.7.x there is no , but a instead. Lars> It is far from beeing conforming to standard C++, but it also Lars> has a lot of similarities so it might be usable. but I must Lars> admit that there is no priority of mine to support gcc 2.7.x. What I think we could (try to) do is have gcc 2.7.x + STLport work. The advantage would be (1) a reasonable STL and (2) this is much easier to install than a new compiler (just untar it). Unfortunately, I do not have access to a gcc 2.7.x compiler here, so I do not know what is needed. JMarc
Re: namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Does namespace support work on all the compilers that the 1.1.x | Lars> series currently compiles on? | | gcc 2.8.1: | | fantomas: g++ -Wall -ansi -pedantic nsp.C | nsp.C:1: sorry, not implemented: namespace I just hate gcc 2.8.x :-) | cxx 6.1: OK. | | Lars> IMO if this works we should begin using a LyX namespace right | Lars> away. We have already had the sqrt clash. | | I'd rather avoid it for now :) The pity, is that now we use structs to hack around not using namespaces... Lgb
Re: namespaces
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | cxx 6.1: OK. | | Lars> IMO if this works we should begin using Lars> a LyX namespace right | Lars> away. We have already had the sqrt Lars> clash. | | I'd rather avoid it for now :) Lars> The pity, is that now we use structs to hack around not using Lars> namespaces... Yes, but in the case of sqrt, naming a pixmap like that is stupid, anyway... I do not really see the advantage of defining LyX::sqrt instead of LyX_sqrt (or better sqrt_xpm). JMarc
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> In gcc 2.7.x there is no , but a instead. | Lars> It is far from beeing conforming to standard C++, but it also | Lars> has a lot of similarities so it might be usable. but I must | Lars> admit that there is no priority of mine to support gcc 2.7.x. | | What I think we could (try to) do is have gcc 2.7.x + STLport work. | The advantage would be (1) a reasonable STL and (2) this is much | easier to install than a new compiler (just untar it). A resonable NON-conforming stl. 2.7.x miss much of the template support to have a good stl. I bet STLport have to be configured as well... In these package days it is easier to install a package than to untar a file. | Unfortunately, I do not have access to a gcc 2.7.x compiler here, so I | do not know what is needed. Making LyX work with gcc 2.7.x has absolutely no priority with me... (hmm it seems that I already said this...) Lgb
Re: namespaces
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> | cxx 6.1: OK. | | Lars> IMO if this works we should begin using | Lars> a LyX namespace right | Lars> away. We have already had the sqrt | Lars> clash. | | I'd rather avoid it for now :) | | Lars> The pity, is that now we use structs to hack around not using | Lars> namespaces... | | Yes, but in the case of sqrt, naming a pixmap like that is stupid, | anyway... I do not really see the advantage of defining LyX::sqrt | instead of LyX_sqrt (or better sqrt_xpm). I agree on this specific case. LyX::TextClassList LyX::Layout LyX::Textclass would be nice... as would Debug:: Lgb
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
On 21-Dec-1999 Jean-Marc Lasgouttes wrote: > > What I think we could (try to) do is have gcc 2.7.x + STLport work. > The advantage would be (1) a reasonable STL and (2) this is much > easier to install than a new compiler (just untar it). > > Unfortunately, I do not have access to a gcc 2.7.x compiler here, so I > do not know what is needed. I did try STLPort with gcc 2.7.2.3 and was not able to compile the example programs supplied :( [errors in the include files] !!! Greets Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienstr. 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Bedfellows make strange politicians. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> A resonable NON-conforming stl. 2.7.x miss much of the template Lars> support to have a good stl. Lars> I bet STLport have to be configured as well... No, it automatically recognizes the compiler version. There are of course a few bugs to overcome, but this may be doable. Lars> In these package days it is easier to install a package than to Lars> untar a file. Sure, on linux. In a place like mine where every program is potentially used by 150 people, they are a bit reluctant to update crucial programs too often. And if you are working on a linux PC at home, upgrading gcc via rpm often means upgrading you distribution anyway, so it can take a lot of time. Lars> Making LyX work with gcc 2.7.x has absolutely no priority with Lars> me... (hmm it seems that I already said this...) But what about 2.6.x? This would be a real challenge, so I'm sure you would find it interesting ;) JMarc
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | No, it automatically recognizes the compiler version. There are of | course a few bugs to overcome, but this may be doable. ok...so you never really know what you get from STLport. | Lars> In these package days it is easier to install a package than to | Lars> untar a file. | | Sure, on linux. In a place like mine where every program is | potentially used by 150 people, they are a bit reluctant to update | crucial programs too often. It _is_ possible to have several versions of gcc installed at the same time... | And if you are working on a linux PC at | home, upgrading gcc via rpm often means upgrading you distribution | anyway, so it can take a lot of time. Some times. If you don't want to upgrade the distribution you have the option of rebuilding from src.rpm. (what I did with mandrakes gcc-2.95.2 to have on RH 6.1) | Lars> Making LyX work with gcc 2.7.x has absolutely no priority with | Lars> me... (hmm it seems that I already said this...) | | But what about 2.6.x? This would be a real challenge, so I'm sure you | would find it interesting ;) 2.6.x? Are you stupid!! Writing C++ without a C++ compiler... nice. (my christmas weekend begins today) Lgb
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> 2.6.x? Are you stupid!! Writing C++ without a C++ compiler... Lars> nice. (my christmas weekend begins today) I think lyx 0.10 or 0.12 used to compile on gcc 2.6.x. Have a nice xmas. JMarc
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I think lyx 0.10 or 0.12 used to compile on gcc 2.6.x. You are probably right... I am not sure about the difference between 2.6.x and 2.7.x when it comes to C++. | Have a nice xmas. Same to you. (and all the rest of you listening in) I hope a lot of Lyxxers will realize that a patch would be a nice christmas gift :-) Lgb
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I Lars> think lyx 0.10 or 0.12 used to compile on gcc 2.6.x. Lars> You are probably right... I am not sure about the difference Lars> between 2.6.x and 2.7.x when it comes to C++. It seems to me that, compared to 2.6.x, gcc 2.7.x is a real C++ compiler :) Lars> I hope a lot of Lyxxers will realize that a patch would be a Lars> nice christmas gift :-) You already have the hebrew support to play with, remember (or shall I commit it?). And it might be argued that hebrew support is a very nonconventional (although symbolic) christmas gift, indeed. JMarc
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I | Lars> think lyx 0.10 or 0.12 used to compile on gcc 2.6.x. | | Lars> You are probably right... I am not sure about the difference | Lars> between 2.6.x and 2.7.x when it comes to C++. | | It seems to me that, compared to 2.6.x, gcc 2.7.x is a real C++ | compiler :) | | Lars> I hope a lot of Lyxxers will realize that a patch would be a | Lars> nice christmas gift :-) | | You already have the hebrew support to play with, remember (or shall I | commit it?). And it might be argued that hebrew support is a very | nonconventional (although symbolic) christmas gift, indeed. If we can get 1.1.4 out the door before 24th then I want the hebrew patch applied as a christmas gift. So what is missing before we can release 1.1.4? 1.1.4pre1 seemed to be pretty ok, and fixed the most serious problems with 1.1.3. I see iso8859-x (x!=1) as a problem but it is easy to fix the cmap files. And I noticed that printing have some problems...or is it not reading the docs...I did not have the PRINTER env set and added "hp2000" as printer in the popup, and nothing happened. then I set PRINTER=hp2000 and everything worked fine. Lgb
Re: Strange "feature"
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> The escaping was not just bad, it was plain wrong. run lyx with
Lars> -dbg key,keymap and you can see yourself. Why demand escaping
Lars> when it is not needed.
The escaping was right with LyXLex, AFAIK.
Lars> | - the concerns I have with the non robustness of your
Lars> regexp-based | parser remain. I understand that regexps are fun,
Lars> but...
Lars> if the line match it match, else it does not match. As for
Lars> robustness, it does not crash.
Sure, if I add a space at the beginning of the line for some reason,
it does not get parsed. On the orhet hand, I can add any junk at the
end of the line, and it will be ignored. Talk about robustness... I
know the regexp can be made better,
Lars> | - the other cdef files have not been modified, and thus the
Lars> problem | remain for them
Lars> Note that the actual contents of the .cdef files have not been
Lars> used until I made my changes yesterday.
Yes, but they were used before you ditched lyxlex, I believe.
Lars> | - the current syntax does not make sense, since we have
Lars> non-escaped " | characters inside "" groups.
Lars> So? that matches ' "[^ ]" '
And maybe is it just that I do not know regexp well enough, but how
are you sure that the match for a string like "\"{e}" will not be just
"\"? Are _all_ regexp implementations required to do this?
Lars> | - If you do not like those escape in the old files, we can in
Lars> fact | just forget about the quotes and it should remove the
Lars> need for | quoting (does it? if not this is a bug in lyxlex).
Lars> Yes that was one of my comments, why use two other chars as
Lars> delimiters.
What I definitely do not like about your solution is that cdef file do
not have a syntax anymore (unless you count `anything that matches my
regexp' as a syntax). In fact, the only way to document the syntax is
probably to give the regexp...
Lars> | Why not just revert to the old parser?
Lars> Wrong use of lyxlex. To use lyxlex as a glorified tokenizer is
Lars> not right.
Why? A tokenizer is just what is needed here. If you want nice tokens,
just modify the syntax to be
Chardef 192 "\\`{A}"
and you have nice tokens to play with...
JMarc
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
Jean-Marc Lasgouttes wrote: > Michael> In insets/figinset.C, change include statement in line 35: > > Michael>#include "signal.h" > > Michael> (seems like csignal does not declare kill but signal.h does) > > I find this one annoying... Are you sure kill is not in the std:: > namespace? Yes, I checked all header files available in the Sun CC distribution. 'kill' is not included in 'csignal'! I discussed this problem with one of my students and he was also wondering whether kill is included in the C/C++ standard library at all. 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 == S/MIME Cryptographic Signature
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> If we can get 1.1.4 out the door before 24th then I want the Lars> hebrew patch applied as a christmas gift. Right. Lars> So what is missing before we can release 1.1.4? 1.1.4pre1 seemed Lars> to be pretty ok, and fixed the most serious problems with 1.1.3. Lars> I see iso8859-x (x!=1) as a problem but it is easy to fix the Lars> cmap files. Pending problems I have in my e-mail folder: - putenv() under solaris 7 (I know, I just have to do it...) - configure's --program-suffix option does not work. - an obscure bug report about citations and spaces that I have to understand first - LyX should not crash when reading tables with an older format - an obscure bug with math-nonumber not working on solaris 7 (but this one is for 1.0.4) Of these, only putenv() and the citation problem (which was not in 1.1.2, it appears) might be important. Lars> And I noticed that printing have some problems...or is it not Lars> reading the docs...I did not have the PRINTER env set and added Lars> "hp2000" as printer in the popup, and nothing happened. then I Lars> set PRINTER=hp2000 and everything worked fine. I have also a bug report about printing not working anymore (from Ben Cazzolato), but since I cannot reproduce it (maybe I did not try hard enough), I did not do anything about it. JMarc
Re: Strange "feature"
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> The escaping was not just bad, it was plain wrong. run lyx with
| Lars> -dbg key,keymap and you can see yourself. Why demand escaping
| Lars> when it is not needed.
|
| The escaping was right with LyXLex, AFAIK.
With lyxlex it didn't matter since the result was not used anyway.
| Sure, if I add a space at the beginning of the line for some reason,
| it does not get parsed. On the orhet hand, I can add any junk at the
| end of the line, and it will be ignored. Talk about robustness... I
| know the regexp can be made better,
Sure it can.
"^[ \t]*([12][0-9][0-9])[ \t]+\"([^ ]+)\"[ \t]+.*"
|
| Lars> | - the other cdef files have not been modified, and thus the
| Lars> problem | remain for them
|
| Lars> Note that the actual contents of the .cdef files have not been
| Lars> used until I made my changes yesterday.
|
| Yes, but they were used before you ditched lyxlex, I believe.
No they were not. At least not in 1.0.4, just look at
CharacterSet::encodeString in chset.C
it returns true if we have a str matching one of the strings in the
cmap, the number is never used.
| And maybe is it just that I do not know regexp well enough, but how
| are you sure that the match for a string like "\"{e}" will not be just
| "\"? Are _all_ regexp implementations required to do this?
Yes, a regex will alway try to match as much as possible.
|
| Lars> | - If you do not like those escape in the old files, we can in
| Lars> fact | just forget about the quotes and it should remove the
| Lars> need for | quoting (does it? if not this is a bug in lyxlex).
|
| Lars> Yes that was one of my comments, why use two other chars as
| Lars> delimiters.
|
| What I definitely do not like about your solution is that cdef file do
| not have a syntax anymore (unless you count `anything that matches my
| regexp' as a syntax). In fact, the only way to document the syntax is
| probably to give the regexp...
Syntax:
nnn ""
I agree that "" looks a bit weird when you allow " inside to.
\def{}{nnn}
could be an alternative
| Lars> Wrong use of lyxlex. To use lyxlex as a glorified tokenizer is
| Lars> not right.
|
| Why? A tokenizer is just what is needed here. If you want nice tokens,
| just modify the syntax to be
| Chardef 192 "\\`{A}"
| and you have nice tokens to play with...
How will that be any nicer? Then lyxlex have one item in its keyword
table, and you still have to "manually" parse the rest of the line.
I really think that to avoid the escaping is nice.
Lgb
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
Michael Schmitt <[EMAIL PROTECTED]> writes: | This is a cryptographically signed message in MIME format. | | --msF4DCE27E66BA8D451B651741 | Content-Type: text/plain; charset=us-ascii | Content-Transfer-Encoding: 7bit | | Jean-Marc Lasgouttes wrote: | | > Michael> In insets/figinset.C, change include statement in line 35: | > | > Michael>#include "signal.h" | > | > Michael> (seems like csignal does not declare kill but signal.h does) | > | > I find this one annoying... Are you sure kill is not in the std:: | > namespace? | | Yes, I checked all header files available in the Sun CC distribution. | 'kill' is not included in 'csignal'! I discussed this problem with one | of my students and he was also wondering whether kill is included in the | C/C++ standard library at all. No it isn't so it should actually not be in signal.h either. But POSIX (and others) decided in their wisdom that since C has these nice header why not just add a few of our functions in there. So I am not sure how nice it is of the implementation to almost require the use of signal.h when csignal is wanted. Perhaps we should just add a extern int kill(pid_t pid, int sig); at the top when kill is not in Lgb
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> So what is missing before we can release 1.1.4? 1.1.4pre1 seemed
| Lars> to be pretty ok, and fixed the most serious problems with 1.1.3.
| Lars> I see iso8859-x (x!=1) as a problem but it is easy to fix the
| Lars> cmap files.
|
| Pending problems I have in my e-mail folder:
|
| - putenv() under solaris 7 (I know, I just have to do it...)
Some check for putenv taking char* as parameter?
#define PUTENV_USES_CHAR_PTR
#ifdef PUTENV_USES_CHAR_PTR
putenv(const_cast(...));
#else
putenv(...);
#endif
| - LyX should not crash when reading tables with an older format
Agree.
Jürgen, what is the difference between version 4 and 5 of the table
code?
| Of these, only putenv() and the citation problem (which was not in
| 1.1.2, it appears) might be important.
I see one small problem...perhaps.
void InsetBibKey::Write(ostream & os)
{
string s;
if (!options.empty()) {
s += '[';
s += options + ']';
}
s += '{';
s += contents + '}';
os << "\\bibitem " << s << "\n";
^^
coudl that spce cause the problem? Probably not nice it is done the
exact same way in 1.0.4.
|
| Lars> And I noticed that printing have some problems...or is it not
| Lars> reading the docs...I did not have the PRINTER env set and added
| Lars> "hp2000" as printer in the popup, and nothing happened. then I
| Lars> set PRINTER=hp2000 and everything worked fine.
|
| I have also a bug report about printing not working anymore (from Ben
| Cazzolato), but since I cannot reproduce it (maybe I did not try hard
| enough), I did not do anything about it.
Something a bit strange...
Lgb
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
On 21-Dec-1999 Jean-Marc Lasgouttes wrote: > > - LyX should not crash when reading tables with an older format > I'll have a look at this as it is something I noted lately :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienstr. 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve. -- J. R. R. Tolkien -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Strange "feature"
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Sure it can. "^[ \t]*([12][0-9][0-9])[ \t]+\"([^ ]+)\"[ \t]+.*"
Wouldn't something like
"^[ \t]*([12][0-9][0-9])[ \t]+\"(.*)\"[ \t]*$"
be better? It avoids junk at the end, does not force a space after the
final ".
Lars> No they were not. At least not in 1.0.4, just look at
Lars> CharacterSet::encodeString in chset.C it returns true if we have
Lars> a str matching one of the strings in the cmap, the number is
Lars> never used.
Yes, I saw that, but I though that it was used elsewhere I did not
see. What is the theory of how this stuff is used, anyway?
Lars> \def{}{nnn}
Lars> could be an alternative
Since nnn almost surely contains braces (\'{e}), this would not be
better. Moreover, this would use a false tex syntax that does not make
sense in TeX. We could want to use the syntax of LaTeX inputenc files,
though, and directly parse that...
Lars> How will that be any nicer? Then lyxlex have one item in its
Lars> keyword table, and you still have to "manually" parse the rest
Lars> of the line.
Except that the 'manually' part does certainly not use more lines of
code than the smart regexp code.
Lars> I really think that to avoid the escaping is nice.
Well, you can have that with LyXLex if you do not quote the second
argument.
stubborn me still trying...
to compile the development branch on my NT box.
I have managed to create the initial configure file on a Linux box and
ftp'ed the whole thing over to the NT box.
automake and autoconf seem to be either broken or I have some problems
that I cant figure out.
Anyway, after getting the xforms library from Stevens ftp site
(www.xforms.com seems to be down right now) I managed to get over the
initial configuration step but when the make step gets to compiling
mathed I get a gazillion error messages,
of which I include the first lines here:
It looks like the X11 header files are not ANSI C++ compliant and
therefore should be included in/with an
extern "C" {} construct. Otoh when I give that a quick shot it doesnt
change anything either.
So what I did then was to look into the Xlib.h file and I found that the
function prototypes have a statement like
#if NeedFunctionPrototypes
bla bla bla
#endif
but this seems not the problem, there are function prototypes that do
not declare a return value and that _is_ a problem for an ANSI C++
compiler.
Is there an easy fix for this ?
Thanks a lot for any kinda hints.
Regards
Roland
pcroland:~/Src/C++/lyx-devel/src/mathed 241 > make
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../../src -I.
./../images -I./../ -I/usr/local/include-I/usr/X11R6.4/include -g
-O -fno
-rtti -Wall -W -Wconversion -DNeedFunctionPrototypes -c formula.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../
-I/usr/local/incl
ude -I/usr/X11R6.4/include -g -O -fno-rtti -Wall -W -Wconversion
-DNeedFunctionP
rototypes -Wp,-MD,.deps/formula.pp -c formula.C -o formula.o
In file included from /usr/local/include/forms.h:988,
from ../../src/lyxfont.h:18,
from ../../src/insets/lyxinset.h:20,
from formula.h:24,
from formula.C:25:
/usr/X11R6.4/include/X11/Xlib.h:2058: ANSI C++ forbids declaration
`XSetTransien
tForHint' with no type
/usr/X11R6.4/include/X11/Xlib.h:2066: ANSI C++ forbids declaration
`XActivateScr
eenSaver' with no type
/usr/X11R6.4/include/X11/Xlib.h:2073: ANSI C++ forbids declaration
`XAddHost' wi
th no type
/usr/X11R6.4/include/X11/Xlib.h:2081: ANSI C++ forbids declaration
`XAddHosts' w
ith no type
/usr/X11R6.4/include/X11/Xlib.h:2088: ANSI C++ forbids declaration
`XAddToExtens
ionList' with no type
/usr/X11R6.4/include/X11/Xlib.h:2095: ANSI C++ forbids declaration
`XAddToSaveSe
t' with no type
/usr/X11R6.4/include/X11/Xlib.h:2149: ANSI C++ forbids declaration
`XAllowEvents
' with no type
/usr/X11R6.4/include/X11/Xlib.h:2155: ANSI C++ forbids declaration
`XAutoRepeatO
ff' with no type
g++: make: *** [formula.lo] Error 1
Re: stubborn me still trying...
On Tue, 21 Dec 1999, Dr. Ing. Roland Krause wrote: > to compile the development branch on my NT box. > > I have managed to create the initial configure file on a Linux box and > ftp'ed the whole thing over to the NT box. > automake and autoconf seem to be either broken or I have some problems > that I cant figure out. Did you or could you send a copy of config.log when configuring on NT? Remember to "make distclean ; ./autogen.sh" first. If there are any errors or warnings during this stage we'll also need those. [...] > there are function prototypes that do > not declare a return value and that _is_ a problem for an ANSI C++ > compiler. > > Is there an easy fix for this ? Try adding "-fpermissive" to the compiler flags: CXXFLAGS This should tell it to accept no return types without an error although you might get warnings. I can't remember what compiler version you had but this looks a lot like 2.95 or maybe 2.95.1. Is there a newer release of gcc for the cygwin environment? a snapshot perhaps instead of an actual rease might have 2.95.2 as it's compiler and this would help a little but the compiler flag should be sufficient. Allan. (ARRae)
Re: lyx-1.1.2, problems under SuSe 5.3 (libc5)
On 21 Dec 1999, Lars Gullik Bjønnes wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | I think lyx 0.10 or 0.12 used to compile on gcc 2.6.x. > > You are probably right... I am not sure about the difference between > 2.6.x and 2.7.x when it comes to C++. Actually I'm sure I had 1.0 compiling with gcc-2.6.3 but then I changed my installation and haven't reinstalled it. As for 2.7.2.x it's a lot more capable and STLport-3.0.1 worked quite well with it for most of the time with the old development branch. I'm quite disappointed with the recent releases of STLport they seem to be full of problems -- at when using gcc-2.95.2 anyway. I'll reinstall 2.7.2.3 and try that with STLport-3.0.1. Juergen, what version of STLport did you try with 2.7.2? BTW, welcome back and thanks for fixing the table crash so quickly. There are a couple other weird table bugs you might like to fix if you need something to do over the Christmas period ;-) > | Have a nice xmas. > > Same to you. (and all the rest of you listening in) Merry Christmas everybody! I'm sure many of you will be having a white Christmas, it looks like I'll be having a wet Christmas. Extra incentive to play on the computer. I've just bought the computer a Christmas present actually, two new heatsinks to help it go extra fast or at least stay a little cooler when it's +33C ambient. > I hope a lot of Lyxxers will realize that a patch would be a nice > christmas gift :-) You never know what might turn up after the last week or so with Hebrew, Chinese/Korean/Japanese support, and Andre' working overtime on his buffer patches. Mike's busy rewriting docs and I've received plenty of incentive to fix the IEEEtran docs and support. Allan. (ARRae)
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
On Sat, 18 Dec 1999, Michael Schmitt wrote: > PS: Is it true that you provide your own string class? Which C++ > compiler supports "pair" and algorithms but does not provide "string"? I > think you should take the string class for granted. Not all string classes are created equal. Take SGI's STL string for example. It's implemented in such a way that there is a 3-5 fold increase in size in an unstripped executable with debugging enabled and a 2-3 fold increase in size in a stripped -O2 no-debugging executable! Even with 128MB of RAM and dual 400MHz processors it takes twice as long to compile with SGI's string and _no_ exceptions as it does to compile lyx with the lyx supplied string _and_ exceptions! (12minutes vs 6minutes) The only difference being which string implementation is used. When exceptions are used when compiling with SGI's string LyXAction.C takes about 180MB!! to compile so swaps terribly and compile time is over 30minutes -- when I used to do this on my old P100 I'd let it compile overnight since it took so long. FYI the executable sizes with lyx's string: 1.3 - 10MB with SGI's string: 2.4 - 50MB There isn't any particularly noticeable difference in performance between the two although I haven't run any benchmarks -- like load times etc. Okay, so this is just an arguement based on the painful compile times experienced with just one string implementation. However at least with our own string implementation we can add a few extra asserts if we wish to enforce stricter requirements and thus better checking than is required by the standard. Anyway, I've been wanting to share these numbers for a while since we also had discussions about the use of exceptions by default. Allan. (ARRae)
I'd like to help
Hello, My name is Matt. I'm out of Florida, USA. I would like to tackle a couple of things that it seems need to be done. 1: First, it seems that in the export section, the Postscript@ stuff needs to be implemented more directly(as opposed to through the printing material). 2: After that is accomplished, it occurs to me that by implementing ps2pdf we could very rapidly implement conversion to pdf! A very useful export format for me and hopefully others. I am a LOUSY c++ programmer and will probably work on this forever. But I am willing to work on it! Any suggestions would be helpful. Knowing you guys you have already implemented this and I'm too late. Thanks for your time. Matt
Re: I'd like to help
On Tue, 21 Dec 1999, matt wrote: > Hello, Hello! > My name is Matt. I'm out of Florida, USA. I would like to tackle a > couple of things that it seems need to be done. > 1: First, it seems that in the export section, the Postscript@ stuff > needs to be implemented more directly(as opposed to through the printing > material). This has been a pretty low priority for us since I think we're all happy to live with it. However, it could certainly be cleaned up and should be a fairly simple task for you as a first step into the LyX world. Don't be afraid to ask questions -- no matter how silly they are. If they're really dumb like some of mine have been everyone politely ignores them (unless it's a Friday) and you get to figure it out for yourself. > 2: After that is accomplished, it occurs to me that by implementing > ps2pdf we could very rapidly implement conversion to pdf! A very useful > export format for me and hopefully others. We've had a discussion about this about a month ago and it seems like a much better idea to use pdflatex and there are also have a few other concerns related to pdf generation -- like which fonts are used -- so it was decided that a pdf mode would be a better idea. I can also add that from my experience pstopdf does a better job that pdf2ps so a pdf mode is the way to go offering ps output as an export option instead of the other way around. Please take a look at the archives before diving into this one. Also I know Lars has some good ideas for this and I was also going to take a look at setting some groundwork for this since I too need pdf output occasionally. > I am a LOUSY c++ programmer and will probably work on this forever. But > I am willing to work on it! If you're willing to accept instruction and constructive criticism you'll find your C++ skills improving as a result of sending in patches. I certainly know my skills have improved over the last three years and I'm still learning. It would also be wise to stick to little projects initially. I can recommend fixing annoying bugs and seg-faults/aborts as a very good way of getting to know the LyX code. Although you'll probably quickly realise that some of the code that's already there isn't "guru" quality so you'd be welcome to offer patches cleaning things up or at least questioning why things are implemented in a particular way. > Any suggestions would be helpful. Knowing you guys you have already > implemented this and I'm too late. Not implemented yet but certainly discussed. One of the things we probably should attempt to do is gather up the discussions into a project document so anyone who wants to tackle it can have a headstart and see what everyone has already decided is A Good Thing. There are a number of these sorts of projects -- discussed but not documented and not underway yet. Oh and I mustn't forget to mention that you should read the coding rules documentation in development/Code_rules/. Can you use cvs to get updates and to generate patches? If you don't have the ability to run cvs then you will be at a distinct disadvantage. Although in such a case a patch against the latest prerelease would have to suffice and one of the developers would have to take care of merging your code. This isn't too much a problem though just inconvenient. > Thanks for your time. Thanks for _your_ time! Did you see the Christmas present discussion from yesterday/earlier today? Allan. (ARRae)
