Re: FILE - ostream
On 19-Dec-1999 Asger K. Alstrup Nielsen wrote: since I live in the south or Norway I drink beer the same was as Asger does. In Denmark, the latest is that they pack the beer in plastic bottles instead of the glass bottles. Do you have that in Norway as well? It tastes the same, but when you cheer and smash the bottles together, the sound is not quite the same: "pluck". Anticlimax. Bahhh what a beer culture, drinking beer from plastic bottles is worse then drinking it from a can :] Also, the effect of drinking too many remains painfully similar, so all in all, they are only an improvement weight-wise. Well I would guess there is not a great enhancement Glass - Plastic speaking of ecology. (It's Monday and I'm a bit concerned about Mother Earth ;) 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 * UNIX is a Trademark of Bell Laboratories. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: FILE -> ostream
On 19-Dec-1999 Asger K. Alstrup Nielsen wrote: >> since I live in the south or Norway I drink beer the same was as Asger >> does. > > In Denmark, the latest is that they pack the beer in plastic bottles > instead of the glass bottles. > Do you have that in Norway as well? It tastes the same, but when you > cheer and smash the bottles together, the sound is not quite the same: > "pluck". Anticlimax. > Bahhh what a beer culture, drinking beer from plastic bottles is worse then drinking it from a can :] > Also, the effect of drinking too many remains painfully similar, so > all in all, they are only an improvement weight-wise. Well I would guess there is not a great enhancement Glass -> Plastic speaking of ecology. (It's Monday and I'm a bit concerned about Mother Earth ;) 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 * UNIX is a Trademark of Bell Laboratories. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: FILE - ostream
On 17 Dec 1999 10:26:31 +0100, Jean-Marc Lasgouttes wrote: "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: Asger But then, even that is hard to find these days. So many other Asger things come first. For instance, I'll going to drik a few Asger beers tomorrow. Do you mean that you need to prepare yourself so long in advance everytime you go drink a few beers? I understand why you are a busy man... JMarc Jean-Marc obviously underestimated the cultural difference :-) Did you really never try to go to drink a beer (öl) in northern Norway? You'd need weeks of complicated preparations. Denmark has already developed a certain degree of indulgency in this respect Arnd
Re: FILE - ostream
"Arnd Hanses" [EMAIL PROTECTED] writes: | Jean-Marc obviously underestimated the cultural difference :-) Did you | really never try to go to drink a beer (öl) in northern Norway? ØL! (öl is swedish) since I live in the south or Norway I drink beer the same was as Asger does. Lgb
Re: FILE -> ostream
On 17 Dec 1999 10:26:31 +0100, Jean-Marc Lasgouttes wrote: >> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: > >Asger> But then, even that is hard to find these days. So many other >Asger> things come first. For instance, I'll going to drik a few >Asger> beers tomorrow. > >Do you mean that you need to prepare yourself so long in advance >everytime you go drink a few beers? I understand why you are a busy >man... > >JMarc Jean-Marc obviously underestimated the cultural difference :-) Did you really never try to go to drink a beer (öl) in northern Norway? You'd need weeks of complicated preparations. Denmark has already developed a certain degree of indulgency in this respect Arnd
Re: FILE -> ostream
"Arnd Hanses" <[EMAIL PROTECTED]> writes: | Jean-Marc obviously underestimated the cultural difference :-) Did you | really never try to go to drink a beer (öl) in northern Norway? ØL! (öl is swedish) since I live in the south or Norway I drink beer the same was as Asger does. Lgb
Re: FILE - ostream
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: Asger The LaTeXWriter was not written. However, it would be an easy Asger task to do it. The AsciiWriter exists in the old development Asger branch, and only needs to be extended with a few routines Asger before a usable LaTeXWriter is ready. Now, if only I had Asger time... OK. I grant you one week. Is that enough? %-] JMarc
Re: FILE -> ostream
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: Asger> The LaTeXWriter was not written. However, it would be an easy Asger> task to do it. The AsciiWriter exists in the old development Asger> branch, and only needs to be extended with a few routines Asger> before a usable LaTeXWriter is ready. Now, if only I had Asger> time... OK. I grant you one week. Is that enough? %-] JMarc
Re: FILE - ostream
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | | Lars Lars I will probably not merge the iostream branch into the | Lars main | Lars branch until 1.1.3 has been released. And I don't | Lars think we | Lars should and more stuff to 1.1.2... | | Lars, | Lars what is the status of known problems in cvs now? | | Lars I don't have any know problems... but I'd like to have some | Lars reports on 1.1.3pre1 before I release 1.1.3. | | You mean the problems with dead keys handling and thorn are fixed? | | JMarc What dead-key problems? The thorn is not fixed. Lgb
Re: FILE - ostream
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars What dead-key problems? Lars The thorn is not fixed. In the message about thorn, you said you were wondering why dead keys were working at all... JMarc
Re: FILE -> ostream
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | | Lars> Lars> I will probably not merge the iostream branch into the | Lars> main | Lars> branch until 1.1.3 has been released. And I don't | Lars> think we | Lars> should and more stuff to 1.1.2... | | Lars, | Lars> what is the status of known problems in cvs now? | | Lars> I don't have any know problems... but I'd like to have some | Lars> reports on 1.1.3pre1 before I release 1.1.3. | | You mean the problems with dead keys handling and thorn are fixed? | | JMarc What dead-key problems? The thorn is not fixed. Lgb
Re: FILE -> ostream
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> What dead-key problems? Lars> The thorn is not fixed. In the message about thorn, you said you were wondering why dead keys were working at all... JMarc
Re: FILE - ostream
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Lars I will probably not merge the iostream branch into the Lars main | Lars branch until 1.1.3 has been released. And I don't Lars think we | Lars should and more stuff to 1.1.2... | | Lars, Lars what is the status of known problems in cvs now? Lars I don't have any know problems... but I'd like to have some Lars reports on 1.1.3pre1 before I release 1.1.3. You mean the problems with dead keys handling and thorn are fixed? JMarc
Re: FILE - ostream
Well, yes it is (was) Friday, but so far no problems. 'Was'? In my part of the world it still is ;-) Anyway. No real problems with 1.1.3 over here either. Maybe the -nw command line switch should be disabled for the time being but I doubt that anybody would try to name his document '-nw'... Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: FILE -> ostream
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Lars> I will probably not merge the iostream branch into the Lars> main | Lars> branch until 1.1.3 has been released. And I don't Lars> think we | Lars> should and more stuff to 1.1.2... | | Lars, Lars> what is the status of known problems in cvs now? Lars> I don't have any know problems... but I'd like to have some Lars> reports on 1.1.3pre1 before I release 1.1.3. You mean the problems with dead keys handling and thorn are fixed? JMarc
Re: FILE -> ostream
> Well, yes it is (was) Friday, but so far no problems. 'Was'? In my part of the world it still is ;-) Anyway. No real problems with 1.1.3 over here either. Maybe the -nw command line switch should be disabled for the time being but I doubt that anybody would try to name his document '-nw'... Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: FILE - ostream
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I can asure you that this in one patch that we absolutely want Lars in. Lars I have only a couple of comments: [...] Another comment: there has been some work from Asger on the old 1.1 branch for making a LaTeXWriter (hmm, I've tried to find it but failed... has it been actually written? %-|). OK, so the idea was to have something like a stream, but which would be able to break lines at a certain length. One could imagine that the symbol `brkspace' is sent to the stream to indicate a place where the line can be broken. Also, when sending an `endl', a latex writer should check that there has not been already a `endl', since \n\n is a paragraph break. And, most importantly, this stream would take care (in some way) of updating texrow for the error handling. Something like that would immensely simplify the code. Of course, since it is basically a stream, this can be done later. However, it is probably something to keep in mind when preparing your patch. JMarc Lars I will probably not merge the iostream branch into the main Lars branch until 1.1.3 has been released. And I don't think we Lars should and more stuff to 1.1.2... Lars, what is the status of known problems in cvs now? JMarc
Re: FILE - ostream
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars I will probably not merge the iostream branch into the main | Lars branch until 1.1.3 has been released. And I don't think we | Lars should and more stuff to 1.1.2... | | Lars, what is the status of known problems in cvs now? I don't have any know problems... but I'd like to have some reports on 1.1.3pre1 before I release 1.1.3. Lgb
Re: FILE - ostream
"Lars Gullik Bjønnes" wrote: Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars I will probably not merge the iostream branch into the main | Lars branch until 1.1.3 has been released. And I don't think we | Lars should and more stuff to 1.1.2... | | Lars, what is the status of known problems in cvs now? I don't have any know problems... but I'd like to have some reports on 1.1.3pre1 before I release 1.1.3. Lgb Well, yes it is (was) Friday, but so far no problems. Garst
Re: FILE -> ostream
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I can asure you that this in one patch that we absolutely want Lars> in. Lars> I have only a couple of comments: [...] Another comment: there has been some work from Asger on the old 1.1 branch for making a LaTeXWriter (hmm, I've tried to find it but failed... has it been actually written? %-|). OK, so the idea was to have something like a stream, but which would be able to break lines at a certain length. One could imagine that the symbol `brkspace' is sent to the stream to indicate a place where the line can be broken. Also, when sending an `endl', a latex writer should check that there has not been already a `endl', since \n\n is a paragraph break. And, most importantly, this stream would take care (in some way) of updating texrow for the error handling. Something like that would immensely simplify the code. Of course, since it is basically a stream, this can be done later. However, it is probably something to keep in mind when preparing your patch. JMarc Lars> I will probably not merge the iostream branch into the main Lars> branch until 1.1.3 has been released. And I don't think we Lars> should and more stuff to 1.1.2... Lars, what is the status of known problems in cvs now? JMarc
Re: FILE -> ostream
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> I will probably not merge the iostream branch into the main | Lars> branch until 1.1.3 has been released. And I don't think we | Lars> should and more stuff to 1.1.2... | | Lars, what is the status of known problems in cvs now? I don't have any know problems... but I'd like to have some reports on 1.1.3pre1 before I release 1.1.3. Lgb
Re: FILE -> ostream
"Lars Gullik Bjønnes" wrote: > > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | Lars> I will probably not merge the iostream branch into the main > | Lars> branch until 1.1.3 has been released. And I don't think we > | Lars> should and more stuff to 1.1.2... > | > | Lars, what is the status of known problems in cvs now? > > I don't have any know problems... but I'd like to have some reports on > 1.1.3pre1 before I release 1.1.3. > > Lgb Well, yes it is (was) Friday, but so far no problems. Garst
Re: FILE - ostream
"Andre' Poenitz" [EMAIL PROTECTED] writes: | I've put a patch under | | http://mathematik.htwm.de/Software/LyX/index.html.en | | that uses ostreams instead of FILEs for output and generally cleans up a | bit (in my eyes). | | It's a bit longish and it is only tested with my own stuff, so I do not | want do throw it an anybody who is reading the list. | | Since I have never used a few of the functions I had to change | I'd like to ask you to apply it and test it with your own docs. | Any comment is welcome. I can asure you that this in one patch that we absolutely want in. I have only a couple of comments: The patch is too big, it's inlcusion into LyX should be broken up. Something like "one FilePtr" at a time. Also I think we should wait with addint const to the write methods. I agree completely that const is correct, but it adds more complexity before we are sure to have it working with iostreams. Ad. strstream. Note that is is depriciated in the C++ standard and if you are not careful you will leak memory: ostrsteam ost; ost "Hello There!"; string st(ost.str()); will leak. ostrstream ost; ost "Hello There!"; char * ctmp = ost.str(); string st(ctmp); delete [] ctmp; will not leak. Later when compilers C++ libraries has matured and begin to support stringstring we will switch into using that. I don't like (too much) code like: cout ...; cout ...; cout ...; but will rather have cout ... ... ...; Also: _never_ use C style casts. Always thing twice before adding a cast (C++ style), is there perhaps some better way to do this. int c; fget(c); cout char(c) " not " (char)c endl; And when writing to the same file ... with no delay ... use as few endl as possible. Flushing the stream is expensive. The patch is very good. Here is what we will do: I want this patch in as soon as possible. I will release a prerelease later today, and then I will setup a new branch based on that prerelease, I will probably call it "iostream". Then use "cvs checkout -r iostream -d iostream lyx-devel" to check it out. If you can redo (apply - fix - diff) the patch for this branch and send it to me I will apply it. I will probably not merge the iostream branch into the main branch until 1.1.3 has been released. And I don't think we should and more stuff to 1.1.2... Lgb
Re: FILE -> ostream
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | I've put a patch under | | http://mathematik.htwm.de/Software/LyX/index.html.en | | that uses ostreams instead of FILEs for output and generally cleans up a | bit (in my eyes). | | It's a bit longish and it is only tested with my own stuff, so I do not | want do throw it an anybody who is reading the list. | | Since I have never used a few of the functions I had to change | I'd like to ask you to apply it and test it with your own docs. | Any comment is welcome. I can asure you that this in one patch that we absolutely want in. I have only a couple of comments: The patch is too big, it's inlcusion into LyX should be broken up. Something like "one FilePtr" at a time. Also I think we should wait with addint const to the write methods. I agree completely that const is correct, but it adds more complexity before we are sure to have it working with iostreams. Ad. strstream. Note that is is depriciated in the C++ standard and if you are not careful you will leak memory: ostrsteam ost; ost << "Hello There!"; string st(ost.str()); will leak. ostrstream ost; ost << "Hello There!"; char * ctmp = ost.str(); string st(ctmp); delete [] ctmp; will not leak. Later when compilers C++ libraries has matured and begin to support stringstring we will switch into using that. I don't like (too much) code like: cout << ...; cout << ...; cout << ...; but will rather have cout << ... << ... << ...; Also: _never_ use C style casts. Always thing twice before adding a cast (C++ style), is there perhaps some better way to do this. int c; fget(c); cout << char(c) << " not " << (char)c << endl; And when writing to the same file ... with no delay ... use as few endl as possible. Flushing the stream is expensive. The patch is very good. Here is what we will do: I want this patch in as soon as possible. I will release a prerelease later today, and then I will setup a new branch based on that prerelease, I will probably call it "iostream". Then use "cvs checkout -r iostream -d iostream lyx-devel" to check it out. If you can redo (apply - fix - diff) the patch for this branch and send it to me I will apply it. I will probably not merge the iostream branch into the main branch until 1.1.3 has been released. And I don't think we should and more stuff to 1.1.2... Lgb
FILE - ostream
I've put a patch under http://mathematik.htwm.de/Software/LyX/index.html.en that uses ostreams instead of FILEs for output and generally cleans up a bit (in my eyes). It's a bit longish and it is only tested with my own stuff, so I do not want do throw it an anybody who is reading the list. Since I have never used a few of the functions I had to change I'd like to ask you to apply it and test it with your own docs. Any comment is welcome. Regards, Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: FILE - ostream
I've put a patch under http://mathematik.htwm.de/Software/LyX/index.html.en that uses ostreams instead of FILEs for output and generally cleans up a bit (in my eyes). I recommended all developers to check this stuff out. It's good work. It's a bit longish and it is only tested with my own stuff, so I do not want do throw it an anybody who is reading the list. Good move. Since I have never used a few of the functions I had to change I'd like to ask you to apply it and test it with your own docs. Any comment is welcome. I didn't try it, but read most of it, fast. It's impressing work you have done there. Congratulations. I recommend that Lgb includes this as the next mayor clean-up item of LyX-devel, after we have had a new release with the latest bug-fixes and clean-ups (when is that coming, Lgb?). Then, we should have a release with the new load/save code, and a relatively long period of testing so that all bugs are ironed out. One important comment before it's ready for inclusion though: The error handling is insufficient. Yes, I realize that the old code didn't exactly do a great job of handling errors, but a rewrite should at least not be worse. I noticed that the code in buffer.C does not do any error checking at all, after we have saved a document. That's no good. Ideally, it should do error handling all the time... What good are the autosave and emergency save routines if LyX can not even detect out-of-space on the disk and won't complain when the user specifically asks for a save? Regarding testing: It's always a good idea to test stuff like this with the documentation that is included with LyX, because those are long and complex documents. Especially the User Guide is a fine stress-test since that uses maybe 90% of all LyX features. So, load the User Guide, and save it as user1.lyx. Then, load user1.lyx and save it as user2.lyx. Now, do a "diff -u user1.lyx user2.lyx" and it should come up empty. If not, you have certainly found a bug. Also, do a diff with the original version of the User guide, and manually inspect all differences. You should know your code, and should be able to decide if things are ok. If the diff is huge, you will probably notice why, and maybe that will motivate you to redo some of the work to get it closer to the original. That is always a good idea, because the LyX format is also used in several external tools. However, disregarding changes that should be ok, this technique can at least point you in the direction of finding bugs. Repeat the exercise with some of the complicated Example documents that relies on special features, such as the tables document, one that uses color, etc. In this way, it should be managable to get pretty good coverage of the new code. Once again, congratulations on the great job! It must have taken quite a while for you to do this, and I'm glad to see that you took our advice: Just grab an area, and then attack it. I would not have recommended that you grabbed this area as the first thing, but I don't complain that you did, knowing that it's a huge task ;-) And hopefully, it has given you more knowledge about how LyX works, and with that, it will be easier for you to begin a new clean-up project. Welcome aboard! Asger
FILE -> ostream
I've put a patch under http://mathematik.htwm.de/Software/LyX/index.html.en that uses ostreams instead of FILEs for output and generally cleans up a bit (in my eyes). It's a bit longish and it is only tested with my own stuff, so I do not want do throw it an anybody who is reading the list. Since I have never used a few of the functions I had to change I'd like to ask you to apply it and test it with your own docs. Any comment is welcome. Regards, Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: FILE -> ostream
> I've put a patch under > > http://mathematik.htwm.de/Software/LyX/index.html.en > > that uses ostreams instead of FILEs for output and generally cleans up a > bit (in my eyes). I recommended all developers to check this stuff out. It's good work. > It's a bit longish and it is only tested with my own stuff, so I do not > want do throw it an anybody who is reading the list. Good move. > Since I have never used a few of the functions I had to change > I'd like to ask you to apply it and test it with your own docs. > Any comment is welcome. I didn't try it, but read most of it, fast. It's impressing work you have done there. Congratulations. I recommend that Lgb includes this as the next mayor clean-up item of LyX-devel, after we have had a new release with the latest bug-fixes and clean-ups (when is that coming, Lgb?). Then, we should have a release with the new load/save code, and a relatively long period of testing so that all bugs are ironed out. One important comment before it's ready for inclusion though: The error handling is insufficient. Yes, I realize that the old code didn't exactly do a great job of handling errors, but a rewrite should at least not be worse. I noticed that the code in buffer.C does not do any error checking at all, after we have saved a document. That's no good. Ideally, it should do error handling all the time... What good are the autosave and emergency save routines if LyX can not even detect out-of-space on the disk and won't complain when the user specifically asks for a save? Regarding testing: It's always a good idea to test stuff like this with the documentation that is included with LyX, because those are long and complex documents. Especially the User Guide is a fine stress-test since that uses maybe 90% of all LyX features. So, load the User Guide, and save it as user1.lyx. Then, load user1.lyx and save it as user2.lyx. Now, do a "diff -u user1.lyx user2.lyx" and it should come up empty. If not, you have certainly found a bug. Also, do a diff with the original version of the User guide, and manually inspect all differences. You should know your code, and should be able to decide if things are ok. If the diff is huge, you will probably notice why, and maybe that will motivate you to redo some of the work to get it closer to the original. That is always a good idea, because the LyX format is also used in several external tools. However, disregarding changes that should be ok, this technique can at least point you in the direction of finding bugs. Repeat the exercise with some of the complicated Example documents that relies on special features, such as the tables document, one that uses color, etc. In this way, it should be managable to get pretty good coverage of the new code. Once again, congratulations on the great job! It must have taken quite a while for you to do this, and I'm glad to see that you took our advice: Just grab an area, and then attack it. I would not have recommended that you grabbed this area as the first thing, but I don't complain that you did, knowing that it's a huge task ;-) And hopefully, it has given you more knowledge about how LyX works, and with that, it will be easier for you to begin a new clean-up project. Welcome aboard! Asger
