Re: GUI independence and XTL
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: Dekel However, the real problem lies on parsing .lyx files at Dekel Buffer::readLyXformat2 which is done using if-else statements Dekel (... else if (token == "\\emph") ... ) This is very Dekel inefficient! Yes, this code should use LyxLex correctly. Actually, this is not a real problem at all. The bottleneck at load time is the rendering of the figures and of the document, not the parsing of the LyX document. You can assert this for yourself by loading the user guide. As soon as the program says "Formatting" or "Loading font", the raw loading part is over. You have to be fast to see it, though. It depends of the document. If you have a very large file, with lots of insets, and a weak CPU, you will notice the time for parsing the document. So: There is no reason to change this. So much else to do. If you want, I can do the changes (and also do the changes I suggested for layout.C)
Re: GUI independence and XTL
[Rewrite the loading parsing logic] If you want, I can do the changes (and also do the changes I suggested for layout.C) When you volunteer, obviously it's a good idea to make the change. You won't find me arguing against that ;-) I'm sure the patch would be welcomed. Maybe it's time for Dekel to get cvs write access? Greets, Asger
Re: GUI independence and XTL
Dekel Tsur [EMAIL PROTECTED] writes: | On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: | Dekel However, the real problem lies on parsing .lyx files at | Dekel Buffer::readLyXformat2 which is done using if-else statements | Dekel (... else if (token == "\\emph") ... ) This is very | Dekel inefficient! | | Yes, this code should use LyxLex correctly. | | Actually, this is not a real problem at all. | The bottleneck at load time is the rendering of the figures and | of the document, not the parsing of the LyX document. | | You can assert this for yourself by loading the user guide. | As soon as the program says "Formatting" or "Loading font", | the raw loading part is over. You have to be fast to see it, | though. | | It depends of the document. If you have a very large file, with lots of | insets, and a weak CPU, you will notice the time for parsing the document. | | | So: There is no reason to change this. So much else to do. | | | If you want, I can do the changes (and also do the changes I suggested | for layout.C) Nooo! :-) I absolutely disagree with you ad. the parsing of layout files. Lgb
Re: GUI independence and XTL
"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes: | [Rewrite the loading parsing logic] | If you want, I can do the changes (and also do the changes I suggested | for layout.C) | | When you volunteer, obviously it's a good idea to make the change. | You won't find me arguing against that ;-) | | I'm sure the patch would be welcomed. | | Maybe it's time for Dekel to get cvs write access? We should not ahve too many people with cvs access, anyway this has to wait a bit since we might have some lyx.org changes soon. Lgb
Re: GUI independence and XTL
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bjnnes wrote: Dekel Tsur [EMAIL PROTECTED] writes: | | If you want, I can do the changes (and also do the changes I suggested | for layout.C) Nooo! :-) I absolutely disagree with you ad. the parsing of layout files. Plaese explain why you don't agree with me (give your comment to my mail " The code in layout.C ")
Re: GUI independence and XTL
On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: > > Dekel> However, the real problem lies on parsing .lyx files at > > Dekel> Buffer::readLyXformat2 which is done using if-else statements > > Dekel> (... else if (token == "\\emph") ... ) This is very > > Dekel> inefficient! > > > > Yes, this code should use LyxLex correctly. > > Actually, this is not a real problem at all. > The bottleneck at load time is the rendering of the figures and > of the document, not the parsing of the LyX document. > > You can assert this for yourself by loading the user guide. > As soon as the program says "Formatting" or "Loading font", > the raw loading part is over. You have to be fast to see it, > though. It depends of the document. If you have a very large file, with lots of insets, and a weak CPU, you will notice the time for parsing the document. > > So: There is no reason to change this. So much else to do. > If you want, I can do the changes (and also do the changes I suggested for layout.C)
Re: GUI independence and XTL
[Rewrite the loading parsing logic] > If you want, I can do the changes (and also do the changes I suggested > for layout.C) When you volunteer, obviously it's a good idea to make the change. You won't find me arguing against that ;-) I'm sure the patch would be welcomed. Maybe it's time for Dekel to get cvs write access? Greets, Asger
Re: GUI independence and XTL
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Thu, Mar 02, 2000 at 12:09:18PM +0100, Asger K. Alstrup Nielsen wrote: | > > Dekel> However, the real problem lies on parsing .lyx files at | > > Dekel> Buffer::readLyXformat2 which is done using if-else statements | > > Dekel> (... else if (token == "\\emph") ... ) This is very | > > Dekel> inefficient! | > > | > > Yes, this code should use LyxLex correctly. | > | > Actually, this is not a real problem at all. | > The bottleneck at load time is the rendering of the figures and | > of the document, not the parsing of the LyX document. | > | > You can assert this for yourself by loading the user guide. | > As soon as the program says "Formatting" or "Loading font", | > the raw loading part is over. You have to be fast to see it, | > though. | | It depends of the document. If you have a very large file, with lots of | insets, and a weak CPU, you will notice the time for parsing the document. | | > | > So: There is no reason to change this. So much else to do. | > | | If you want, I can do the changes (and also do the changes I suggested | for layout.C) Nooo! :-) I absolutely disagree with you ad. the parsing of layout files. Lgb
Re: GUI independence and XTL
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: | [Rewrite the loading parsing logic] | > If you want, I can do the changes (and also do the changes I suggested | > for layout.C) | | When you volunteer, obviously it's a good idea to make the change. | You won't find me arguing against that ;-) | | I'm sure the patch would be welcomed. | | Maybe it's time for Dekel to get cvs write access? We should not ahve too many people with cvs access, anyway this has to wait a bit since we might have some lyx.org changes soon. Lgb
Re: GUI independence and XTL
On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bjnnes wrote: > Dekel Tsur <[EMAIL PROTECTED]> writes: > | > | If you want, I can do the changes (and also do the changes I suggested > | for layout.C) > > Nooo! :-) > > I absolutely disagree with you ad. the parsing of layout files. > Plaese explain why you don't agree with me (give your comment to my mail " The code in layout.C ")
Re: GUI independence and XTL
Dekel However, the real problem lies on parsing .lyx files at Dekel Buffer::readLyXformat2 which is done using if-else statements Dekel (... else if (token == "\\emph") ... ) This is very Dekel inefficient! Yes, this code should use LyxLex correctly. Actually, this is not a real problem at all. The bottleneck at load time is the rendering of the figures and of the document, not the parsing of the LyX document. You can assert this for yourself by loading the user guide. As soon as the program says "Formatting" or "Loading font", the raw loading part is over. You have to be fast to see it, though. So: There is no reason to change this. So much else to do. Greets, Asger
Re: GUI independence and XTL
> Dekel> However, the real problem lies on parsing .lyx files at > Dekel> Buffer::readLyXformat2 which is done using if-else statements > Dekel> (... else if (token == "\\emph") ... ) This is very > Dekel> inefficient! > > Yes, this code should use LyxLex correctly. Actually, this is not a real problem at all. The bottleneck at load time is the rendering of the figures and of the document, not the parsing of the LyX document. You can assert this for yourself by loading the user guide. As soon as the program says "Formatting" or "Loading font", the raw loading part is over. You have to be fast to see it, though. So: There is no reason to change this. So much else to do. Greets, Asger
Re: GUI independence and XTL
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Perhaps because the standard C++ library dioes not have hashed | Lars containers? (that is an sgi extension (among others)) | | Lars As for faster search times, these tables are som small that I | Lars don't think it would have made a difference anyway. | | And the table would have to be constructed at initialisation, whereas | it is static now. I have changed some of that in layout.C now. Since we usually parse layout files pretty seldom I have changed the lyxlex tables to be dynamic. I have also changed to of the code that annoyed Dekel the most. and thus now some of the code has run-time checking instead of compile time... Lgb
Re: GUI independence and XTL
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Lars> Perhaps because the standard C++ library dioes not have hashed | Lars> containers? (that is an sgi extension (among others)) | | Lars> As for faster search times, these tables are som small that I | Lars> don't think it would have made a difference anyway. | | And the table would have to be constructed at initialisation, whereas | it is static now. I have changed some of that in layout.C now. Since we usually parse layout files pretty seldom I have changed the lyxlex tables to be dynamic. I have also changed to of the code that annoyed Dekel the most. and thus now some of the code has run-time checking instead of compile time... Lgb
Re: GUI independence and XTL
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Dekel Tsur [EMAIL PROTECTED] writes: | On Mon, Feb 28, 2000 Lars at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | Lars "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Lars Or we can just sort it... this will slow things down a Lars tiny bit, | Lars but you will never be able you measure that. Lars (manually) | | With an assertion, we are always sure that Lars manual sorting will be | done. This is linear time, and only Lars for debug builds. | | JMarc | | Why not use hashing? You Lars also get faster search time. | In any case, why isn't the STL Lars being used? (map/hash_map containers) Lars Perhaps because the standard C++ library dioes not have hashed Lars containers? (that is an sgi extension (among others)) Lars As for faster search times, these tables are som small that I Lars don't think it would have made a difference anyway. And the table would have to be constructed at initialisation, whereas it is static now. JMarc
Re: GUI independence and XTL
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bjnnes wrote: | Lars Or we can just sort it... this will slow things down a tiny bit, | Lars but you will never be able you measure that. (manually) | | With an assertion, we are always sure that manual sorting will be | done. This is linear time, and only for debug builds. | Why not use hashing? You also get faster search time. | In any case, why isn't the STL being used? (map/hash_map containers) Perhaps because the standard C++ library dioes not have hashed containers? (that is an sgi extension (among others)) You can still use map containers which automatically sort the tokens (with a small(?) penalty for initialization) But maybe it not worth it to mess up a code that works... As for faster search times, these tables are som small that I don't think it would have made a difference anyway. The table of lyxrc tokens contains ~100 entries which is not that small, but you are correct: the difference should be small (at least for parsing the lyxrc/layout files). However, the real problem lies on parsing .lyx files at Buffer::readLyXformat2 which is done using if-else statements (... else if (token == "\\emph") ... ) This is very inefficient!
Re: GUI independence and XTL
"Dekel" == Dekel Tsur [EMAIL PROTECTED] writes: Dekel However, the real problem lies on parsing .lyx files at Dekel Buffer::readLyXformat2 which is done using if-else statements Dekel (... else if (token == "\\emph") ... ) This is very Dekel inefficient! Yes, this code should use LyxLex correctly. JMarc
Re: GUI independence and XTL
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Dekel Tsur <[EMAIL PROTECTED]> writes: | On Mon, Feb 28, 2000 Lars> at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | > > Lars> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | > | > Lars> Lars> Or we can just sort it... this will slow things down a Lars> tiny bit, | > Lars> but you will never be able you measure that. Lars> (manually) | > | > With an assertion, we are always sure that Lars> manual sorting will be | > done. This is linear time, and only Lars> for debug builds. | > | > JMarc | | Why not use hashing? You Lars> also get faster search time. | In any case, why isn't the STL Lars> being used? (map/hash_map containers) Lars> Perhaps because the standard C++ library dioes not have hashed Lars> containers? (that is an sgi extension (among others)) Lars> As for faster search times, these tables are som small that I Lars> don't think it would have made a difference anyway. And the table would have to be constructed at initialisation, whereas it is static now. JMarc
Re: GUI independence and XTL
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bjnnes wrote: > | > Lars> Or we can just sort it... this will slow things down a tiny bit, > | > Lars> but you will never be able you measure that. (manually) > | > > | > With an assertion, we are always sure that manual sorting will be > | > done. This is linear time, and only for debug builds. > | Why not use hashing? You also get faster search time. > | In any case, why isn't the STL being used? (map/hash_map containers) > > Perhaps because the standard C++ library dioes not have hashed > containers? > (that is an sgi extension (among others)) You can still use map containers which automatically sort the tokens (with a small(?) penalty for initialization) But maybe it not worth it to mess up a code that works... > > As for faster search times, these tables are som small that I don't > think it would have made a difference anyway. > The table of lyxrc tokens contains ~100 entries which is not that small, but you are correct: the difference should be small (at least for parsing the lyxrc/layout files). However, the real problem lies on parsing .lyx files at Buffer::readLyXformat2 which is done using if-else statements (... else if (token == "\\emph") ... ) This is very inefficient!
Re: GUI independence and XTL
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> However, the real problem lies on parsing .lyx files at Dekel> Buffer::readLyXformat2 which is done using if-else statements Dekel> (... else if (token == "\\emph") ... ) This is very Dekel> inefficient! Yes, this code should use LyxLex correctly. JMarc
Re: GUI independence and XTL
Andre Poenitz [EMAIL PROTECTED] writes: | is at easy if it can possibly get. But maybe you are right and XTL is | | Read: | | ..is as easy as it ... | | I think I'll have another beer to get sober... Not, in Norway yet are you? Lgb
Re: GUI independence and XTL
"Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: Asger The LyXLex creature requires a list of keywords to function. Asger This is a simple list of tokens, but it only works if it is Asger sorted. Real life has shown that this is hard. Last time, it Asger was Juergen who couldn't remember the alphabet. Earlier, I have Asger made the same mistake, and I would wonder if not Lgb and Asger everybody else that has touched it has too sometime. It would be easy for LyXLex to test the proper sorting of lists when ENABLE_ASSERTIONS is set. I'll do it if I find time. JMarc
Re: GUI independence and XTL
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "Asger" == Asger K Alstrup Nielsen [EMAIL PROTECTED] writes: | | Asger The LyXLex creature requires a list of keywords to function. | Asger This is a simple list of tokens, but it only works if it is | Asger sorted. Real life has shown that this is hard. Last time, it | Asger was Juergen who couldn't remember the alphabet. Earlier, I have | Asger made the same mistake, and I would wonder if not Lgb and | Asger everybody else that has touched it has too sometime. | | It would be easy for LyXLex to test the proper sorting of lists when | ENABLE_ASSERTIONS is set. I'll do it if I find time. Or we can just sort it... this will slow things down a tiny bit, but you will never be able you measure that. (manually) Lgb
Re: GUI independence and XTL
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Or we can just sort it... this will slow things down a tiny bit, Lars but you will never be able you measure that. (manually) With an assertion, we are always sure that manual sorting will be done. This is linear time, and only for debug builds. JMarc
Re: GUI independence and XTL
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: "Lars" == Lars Gullik Bjnnes [EMAIL PROTECTED] writes: Lars Or we can just sort it... this will slow things down a tiny bit, Lars but you will never be able you measure that. (manually) With an assertion, we are always sure that manual sorting will be done. This is linear time, and only for debug builds. JMarc Why not use hashing? You also get faster search time. In any case, why isn't the STL being used? (map/hash_map containers)
Re: GUI independence and XTL
Dekel Tsur [EMAIL PROTECTED] writes: | On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | | Lars Or we can just sort it... this will slow things down a tiny bit, | Lars but you will never be able you measure that. (manually) | | With an assertion, we are always sure that manual sorting will be | done. This is linear time, and only for debug builds. | | JMarc | | Why not use hashing? You also get faster search time. | In any case, why isn't the STL being used? (map/hash_map containers) Perhaps because the standard C++ library dioes not have hashed containers? (that is an sgi extension (among others)) As for faster search times, these tables are som small that I don't think it would have made a difference anyway. Lgb
Re: GUI independence and XTL
Andre Poenitz <[EMAIL PROTECTED]> writes: | > is at easy if it can possibly get. But maybe you are right and XTL is | | Read: | | ..is as easy as it ... | | I think I'll have another beer to get sober... Not, in Norway yet are you? Lgb
Re: GUI independence and XTL
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: Asger> The LyXLex creature requires a list of keywords to function. Asger> This is a simple list of tokens, but it only works if it is Asger> sorted. Real life has shown that this is hard. Last time, it Asger> was Juergen who couldn't remember the alphabet. Earlier, I have Asger> made the same mistake, and I would wonder if not Lgb and Asger> everybody else that has touched it has too sometime. It would be easy for LyXLex to test the proper sorting of lists when ENABLE_ASSERTIONS is set. I'll do it if I find time. JMarc
Re: GUI independence and XTL
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes: | | Asger> The LyXLex creature requires a list of keywords to function. | Asger> This is a simple list of tokens, but it only works if it is | Asger> sorted. Real life has shown that this is hard. Last time, it | Asger> was Juergen who couldn't remember the alphabet. Earlier, I have | Asger> made the same mistake, and I would wonder if not Lgb and | Asger> everybody else that has touched it has too sometime. | | It would be easy for LyXLex to test the proper sorting of lists when | ENABLE_ASSERTIONS is set. I'll do it if I find time. Or we can just sort it... this will slow things down a tiny bit, but you will never be able you measure that. (manually) Lgb
Re: GUI independence and XTL
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Or we can just sort it... this will slow things down a tiny bit, Lars> but you will never be able you measure that. (manually) With an assertion, we are always sure that manual sorting will be done. This is linear time, and only for debug builds. JMarc
Re: GUI independence and XTL
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: > > "Lars" == Lars Gullik Bjnnes <[EMAIL PROTECTED]> writes: > > Lars> Or we can just sort it... this will slow things down a tiny bit, > Lars> but you will never be able you measure that. (manually) > > With an assertion, we are always sure that manual sorting will be > done. This is linear time, and only for debug builds. > > JMarc Why not use hashing? You also get faster search time. In any case, why isn't the STL being used? (map/hash_map containers)
Re: GUI independence and XTL
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote: | > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | > | > Lars> Or we can just sort it... this will slow things down a tiny bit, | > Lars> but you will never be able you measure that. (manually) | > | > With an assertion, we are always sure that manual sorting will be | > done. This is linear time, and only for debug builds. | > | > JMarc | | Why not use hashing? You also get faster search time. | In any case, why isn't the STL being used? (map/hash_map containers) Perhaps because the standard C++ library dioes not have hashed containers? (that is an sgi extension (among others)) As for faster search times, these tables are som small that I don't think it would have made a difference anyway. Lgb
Re: GUI independence and XTL
On Fri, 25 Feb 2000, Andre Poenitz wrote: We have considered extending the string interface with various ways of encoding the information, but that would require slow and error-prone parsing of strings. I don't agree. Sorry... (Erm... well, it's friday, isn't it) String parsing is not error prone once you got it nicely encapsulated. And that's really not too difficult. String parsing is slow. But that does not matter in our context. We want a "real time _user_ interface", i.e. on one end of the interface sits a human. And this human is the weak link performance-wise. Recall that Asger has already memntioned the text export and that XTL supports several other formats for externalization (CORBA stuff and XDR). If you really, really wanted to you could write support for another format that could be XML-like. This would be a string input and output that could then be used to support all the external scripting languages or other client programs you could imagine. The XTL library solves this problem for us in a clean, efficient, elegant, and extensible way. This introduces another bit of software that deals with binary data. And text data and any other format you care to define. It even promises the perspective of easier interoperability with external stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on steroids. So can a string interface. UNIX external stuff tends to be plain ASCII. It's easy to debug, it's easy to control with standard tools. And with an XTL-based string format we don't have to write or maintain new parser databases for each new object/structure we want to communicate. In fact XTL makes it very easy for us to use the exact same code to communicate in different formats (be it a string, raw binary, or CORBA GIOP IIXYZ whatever the acronym is). [... strings + streams sample code...] I don't think, this will be possible. You're right ;-) Allan. (ARRae)
Re: GUI independence and XTL
On Fri, 25 Feb 2000, Andre Poenitz wrote: > > We have considered extending the string interface > > with various ways of encoding the information, but that would require > > slow and error-prone parsing of strings. > > I don't agree. Sorry... (Erm... well, it's friday, isn't it) > > String parsing is not error prone once you got it nicely encapsulated. > And that's really not too difficult. > > String parsing is slow. But that does not matter in our context. We want > a "real time _user_ interface", i.e. on one end of the interface sits a > human. And this human is the weak link performance-wise. Recall that Asger has already memntioned the text export and that XTL supports several other formats for externalization (CORBA stuff and XDR). If you really, really wanted to you could write support for another format that could be XML-like. This would be a string input and output that could then be used to support all the external scripting languages or other client programs you could imagine. > > The XTL library solves this problem for us in a clean, efficient, elegant, > > and extensible way. > > This introduces another bit of software that deals with binary data. And text data and any other format you care to define. > > It even promises the perspective of easier interoperability with external > > stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on > > steroids. > > So can a string interface. UNIX external stuff tends to be plain ASCII. > It's easy to debug, it's easy to control with standard tools. And with an XTL-based string format we don't have to write or maintain new parser databases for each new object/structure we want to communicate. In fact XTL makes it very easy for us to use the exact same code to communicate in different formats (be it a string, raw binary, or CORBA GIOP IIXYZ whatever the acronym is). [... strings + streams sample code...] > I don't think, this will be possible. You're right ;-) Allan. (ARRae)
Re: GUI independence and XTL
You argue that debugging is important. Three words: Debugging is boring.
I know. But sometimes necessary. Not that I try to code poorly just to
have the fun of debugging ;-|
If we use XTL, there will be less debugging than if we have to write
our own parser. Just take a look at any parser we have in LyX. Every
one of them is problematic, and has causes bugs.
True. But a lot of trouble can be saved by using things like yacc...
If for nothing else,
them simply because it actual is hard to keep a list sorted!
I don't understand you here. Which list do you mean?
Now, maybe you can find a better encapsulation than what we currently
have. Good for you, but I already found the best encapsulation. It's
called XTL.
Ok, I promise have a closer look at XTL. You seem rather convinced and
I've seen a few good ideas from you already ;-)
Tons of interfaces?
All dialogs require an interface to the kernel to get the information
that should go in the dialog.
Some dialogs just construct some sort of command that is send down to
the kernel. Those should of course use the interface... But since XTL
seems to be able to handle that, too, the problem is reduced to the question
which solution is easier. Until now I thought a string (or stream) interface
is at easy if it can possibly get. But maybe you are right and XTL is
truly easier.
It is more difficult than using XTL.
It is less secure than XTL.
It is less sexy than XTL.
:-)
Have a look at XTL. Let me wing you an example. I can make it more
complex if you want to, but maybe you would not understand what we
are talking about:
struct Foo {
vectorint data1;
listpairint, char data2;
string data3;
templateX
void simple(X x) {
X.simple(data1).simple(data2).simple(data3);
}
};
There you have all your externalization code, both for input and output.
You can't beat that, now can you?
No. If it is realy *that* easy it looks like a viable solution.
If you think so, you must be drunk. Come to Norway and I'll buy you a beer.
You mean drinking Norwegian beer makes me less drunk? I knew that this
stuff was expensive, but I did not know that they don't even have
alcohol in it. Poor Lars ;-)
Regards,
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
is at easy if it can possibly get. But maybe you are right and XTL is Read: ..is as easy as it ... I think I'll have another beer to get sober... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
True. But a lot of trouble can be saved by using things like yacc... Yacc is complex and error-prone. It adds comparably much complexity to things. Also, Yacc by itself does not cut it. You have to bring in the smaller cousin Lex, or Bison if you are so inclined. However, that complicates everything. Just think of the Makefile hell you are suddenly into. Who would voluntarily bring in the weird Lex and Yacc pair to solve a problem which is solved much better with simpler tools? Always, if you are as maschochistic as to insist that your computer science teaching should be used in real life, and that Lex and Yacc are indeed useful in real life, I would recommend you to have a look at PCCTS, or the newer incarnation called ANTLR. This is a lexer and parser hybrid, with the added benefit of a tree construction feature on top. It uses a kind of predicates to get a fresh approach to parsing. See http://www.antlr.org. However, for the task at hand, we should avoid the whole parsing business. If for nothing else, them simply because it actual is hard to keep a list sorted! I don't understand you here. Which list do you mean? The LyXLex creature requires a list of keywords to function. This is a simple list of tokens, but it only works if it is sorted. Real life has shown that this is hard. Last time, it was Juergen who couldn't remember the alphabet. Earlier, I have made the same mistake, and I would wonder if not Lgb and everybody else that has touched it has too sometime. [Simple winged example of XTL power] No. If it is realy *that* easy it looks like a viable solution. Thank you. Now, go back and drink some more beer. If you think so, you must be drunk. Come to Norway and I'll buy you a beer. You mean drinking Norwegian beer makes me less drunk? No. My line of reasoning was this: 1) André was against XTL. 2) André either did not know what XTL was, or he must be drunk to think this. 3) Asger explains what XTL can do, and now the only excuse for André to resist reason would involve alcohol. 4) Asger buys beer for André, and then Asger is right no matter what. Maybe I should get a beer as well. Cheers, Asger P.S. *Are* you coming to Norway?
Re: GUI independence and XTL
> You argue that debugging is important. Three words: Debugging is boring.
I know. But sometimes necessary. Not that I try to code poorly just to
have the fun of debugging ;-|
> If we use XTL, there will be less debugging than if we have to write
> our own parser. Just take a look at any parser we have in LyX. Every
> one of them is problematic, and has causes bugs.
True. But a lot of trouble can be saved by using things like yacc...
> If for nothing else,
> them simply because it actual is hard to keep a list sorted!
I don't understand you here. Which list do you mean?
> Now, maybe you can find a better encapsulation than what we currently
> have. Good for you, but I already found the best encapsulation. It's
> called XTL.
Ok, I promise have a closer look at XTL. You seem rather convinced and
I've seen a few good ideas from you already ;-)
> > Tons of interfaces?
>
> All dialogs require an interface to the kernel to get the information
> that should go in the dialog.
Some dialogs just construct some sort of command that is send down to
the kernel. Those should of course use the interface... But since XTL
seems to be able to handle that, too, the problem is reduced to the question
which solution is easier. Until now I thought a string (or stream) interface
is at easy if it can possibly get. But maybe you are right and XTL is
truly easier.
> It is more difficult than using XTL.
> It is less secure than XTL.
> It is less sexy than XTL.
:-)
> Have a look at XTL. Let me wing you an example. I can make it more
> complex if you want to, but maybe you would not understand what we
> are talking about:
>
> struct Foo {
> vector data1;
> list > data2;
> string data3;
> template
> void simple(X x) {
> X.simple(data1).simple(data2).simple(data3);
> }
> };
>
> There you have all your externalization code, both for input and output.
> You can't beat that, now can you?
No. If it is realy *that* easy it looks like a viable solution.
> If you think so, you must be drunk. Come to Norway and I'll buy you a beer.
You mean drinking Norwegian beer makes me less drunk? I knew that this
stuff was expensive, but I did not know that they don't even have
alcohol in it. Poor Lars ;-)
Regards,
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
> is at easy if it can possibly get. But maybe you are right and XTL is Read: ..is as easy as it ... I think I'll have another beer to get sober... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
> True. But a lot of trouble can be saved by using things like yacc... Yacc is complex and error-prone. It adds comparably much complexity to things. Also, Yacc by itself does not cut it. You have to bring in the smaller cousin Lex, or Bison if you are so inclined. However, that complicates everything. Just think of the Makefile hell you are suddenly into. Who would voluntarily bring in the weird Lex and Yacc pair to solve a problem which is solved much better with simpler tools? Always, if you are as maschochistic as to insist that your computer science teaching should be used in real life, and that Lex and Yacc are indeed useful in real life, I would recommend you to have a look at PCCTS, or the newer incarnation called ANTLR. This is a lexer and parser hybrid, with the added benefit of a tree construction feature on top. It uses a kind of predicates to get a fresh approach to parsing. See http://www.antlr.org. However, for the task at hand, we should avoid the whole parsing business. > > If for nothing else, > > them simply because it actual is hard to keep a list sorted! > > I don't understand you here. Which list do you mean? The LyXLex creature requires a list of keywords to function. This is a simple list of tokens, but it only works if it is sorted. Real life has shown that this is hard. Last time, it was Juergen who couldn't remember the alphabet. Earlier, I have made the same mistake, and I would wonder if not Lgb and everybody else that has touched it has too sometime. [Simple winged example of XTL power] > No. If it is realy *that* easy it looks like a viable solution. Thank you. Now, go back and drink some more beer. > > If you think so, you must be drunk. Come to Norway and I'll buy you a beer. > > You mean drinking Norwegian beer makes me less drunk? No. My line of reasoning was this: 1) André was against XTL. 2) André either did not know what XTL was, or he must be drunk to think this. 3) Asger explains what XTL can do, and now the only excuse for André to resist reason would involve alcohol. 4) Asger buys beer for André, and then Asger is right no matter what. Maybe I should get a beer as well. Cheers, Asger P.S. *Are* you coming to Norway?
Re: GUI independence and XTL
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote: The best format is the raw format, since it's minimalistic and the fastest. We don't need interoperability with external sources, so the raw format is the best solution. That was what I thought the plain text was. The version I currently have only exports to raw but doesn't import. Oh, no. The class is called "raw_format" and it's a binary only format. It does both import and export. This is different from the text_format, which only does export at this point. The raw_format is defined in objio.h. Greets, Asger
Re: GUI independence and XTL
[XTL] I did that too and I admit I dont get what this is suposed to do for LyX? Do you intend to have a new file format? Btw XDR is a platform independent format for binary representation. I use XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with some automatized traversal, but what would that be needed for? Am I clueless or missing imagination here? The problem XTL can solve is primarily the communication between the LyX kernel in the form of the current LyXFunc and the front-ends. This interface either has the form of a simple string interface now, much like the minibuffer, or is non-existant. The string interface is too simple for the kind of information that should be passed around. We have considered extending the string interface with various ways of encoding the information, but that would require slow and error-prone parsing of strings. The XTL library solves this problem for us in a clean, efficient, elegant, and extensible way. It even promises the perspective of easier interoperability with external stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on steroids. In other words: XTL can provide the medium of communication between the LyX kernel and the rest of the world. Technically, we could use XTL to get a new file format, but that's not relevant at this point in time. For starters, we would probably only export the needed stuff for the dialogs via XTL, and over time, more and more of the kernel can be exported this way. Anyway, that's how I thought the XTL could help LyX. Obviously, we can live without XTL, but it makes life easier, because we don't have to provide tons of interfaces into the kernel. Instead, we just have to provide XTL memory pools for certain features that contain potentially lots of parameters. The neat part about XTL is obviously that you only have to implement one method for each structure to get both read and write functionality. Greets, Asger
Re: GUI independence and XTL
The string interface is too simple for the kind of information that should
be passed around.
What kind of information can not be passed around as strings?
We have considered extending the string interface
with various ways of encoding the information, but that would require
slow and error-prone parsing of strings.
I don't agree. Sorry... (Erm... well, it's friday, isn't it)
String parsing is not error prone once you got it nicely encapsulated.
And that's really not too difficult.
String parsing is slow. But that does not matter in our context. We want
a "real time _user_ interface", i.e. on one end of the interface sits a
human. And this human is the weak link performance-wise.
As long as you do not pass lots and lots of internal calls through this
interface that's just fine. And LyX does not do that currently. Even if
LyX becomes more modular and some internal calls could be made through
this interface, this won't become overwhelming. After all, it's modular
then...
The XTL library solves this problem for us in a clean, efficient, elegant,
and extensible way.
This introduces another bit of software that deals with binary data.
It even promises the perspective of easier interoperability with external
stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on
steroids.
So can a string interface. UNIX external stuff tends to be plain ASCII.
It's easy to debug, it's easy to control with standard tools.
can live without XTL, but it makes life easier, because we don't have
to provide tons of interfaces into the kernel.
Tons of interfaces?
Instead, we just have to provide XTL memory pools for certain features
that contain potentially lots of parameters.
If we really need that we should have a stream interface.
Send a command/parameter stream in and wait until something comes out
the result stream or on the error stream.
Conversion of strings and stream is niot difficult, too...
The neat part about XTL is obviously that you only have to implement
one method for each structure to get both read and write functionality.
Do you think this will be much easier than:
function(istream inputstream, ostream outputstream, ostream err.. )
{
int par1, par2;
inputstream par1 par2;
if (!inputstream) {
errorstream "funny parameters";
return;
}
outputstream "some rtesult";
}
I don't think, this will be possible.
Regards,
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
> On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote: > > The best format is the raw format, since it's minimalistic and the > > fastest. We don't need interoperability with external sources, so > > the raw format is the best solution. > > That was what I thought the plain text was. The version I currently have > only exports to raw but doesn't import. Oh, no. The class is called "raw_format" and it's a binary only format. It does both import and export. This is different from the text_format, which only does export at this point. The raw_format is defined in objio.h. Greets, Asger
Re: GUI independence and XTL
[XTL] > I did that too and I admit I dont get what this is suposed to do for LyX? Do > you intend to have a new file format? > Btw XDR is a platform independent format for binary representation. I use > XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with > some automatized traversal, but what would that be needed for? > > Am I clueless or missing imagination here? The problem XTL can solve is primarily the communication between the LyX kernel in the form of the current LyXFunc and the front-ends. This interface either has the form of a simple string interface now, much like the minibuffer, or is non-existant. The string interface is too simple for the kind of information that should be passed around. We have considered extending the string interface with various ways of encoding the information, but that would require slow and error-prone parsing of strings. The XTL library solves this problem for us in a clean, efficient, elegant, and extensible way. It even promises the perspective of easier interoperability with external stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on steroids. In other words: XTL can provide the medium of communication between the LyX kernel and the rest of the world. Technically, we could use XTL to get a new file format, but that's not relevant at this point in time. For starters, we would probably only export the needed stuff for the dialogs via XTL, and over time, more and more of the kernel can be exported this way. Anyway, that's how I thought the XTL could help LyX. Obviously, we can live without XTL, but it makes life easier, because we don't have to provide tons of interfaces into the kernel. Instead, we just have to provide XTL memory pools for certain features that contain potentially lots of parameters. The neat part about XTL is obviously that you only have to implement one method for each structure to get both read and write functionality. Greets, Asger
Re: GUI independence and XTL
> The string interface is too simple for the kind of information that should
> be passed around.
What kind of information can not be passed around as strings?
> We have considered extending the string interface
> with various ways of encoding the information, but that would require
> slow and error-prone parsing of strings.
I don't agree. Sorry... (Erm... well, it's friday, isn't it)
String parsing is not error prone once you got it nicely encapsulated.
And that's really not too difficult.
String parsing is slow. But that does not matter in our context. We want
a "real time _user_ interface", i.e. on one end of the interface sits a
human. And this human is the weak link performance-wise.
As long as you do not pass lots and lots of internal calls through this
interface that's just fine. And LyX does not do that currently. Even if
LyX becomes more modular and some internal calls could be made through
this interface, this won't become overwhelming. After all, it's modular
then...
> The XTL library solves this problem for us in a clean, efficient, elegant,
> and extensible way.
This introduces another bit of software that deals with binary data.
> It even promises the perspective of easier interoperability with external
> stuff, as Allan mentions. I.e. over time XTL can provide a LyXServer on
> steroids.
So can a string interface. UNIX external stuff tends to be plain ASCII.
It's easy to debug, it's easy to control with standard tools.
> can live without XTL, but it makes life easier, because we don't have
> to provide tons of interfaces into the kernel.
Tons of interfaces?
> Instead, we just have to provide XTL memory pools for certain features
> that contain potentially lots of parameters.
If we really need that we should have a stream interface.
Send a command/parameter stream in and wait until something comes out
the result stream or on the error stream.
Conversion of strings and stream is niot difficult, too...
> The neat part about XTL is obviously that you only have to implement
> one method for each structure to get both read and write functionality.
Do you think this will be much easier than:
function(istream & inputstream, ostream & outputstream, ostream & err.. )
{
int par1, par2;
inputstream >> par1 >> par2;
if (!inputstream) {
errorstream << "funny parameters";
return;
}
outputstream << "some rtesult";
}
I don't think, this will be possible.
Regards,
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: GUI independence and XTL
I am intending to make XTL a part of the rae branch sometime this week as I want to try it out communication with LyXFunc. I'll have to get the latest release to see what's new. The version I have exports to plain text but doesn't import from it. It seems very fast for CORBA and XDF(?) formats. The best format is the raw format, since it's minimalistic and the fastest. We don't need interoperability with external sources, so the raw format is the best solution. Fortunately, this decision is so easy to change later, given the XTL setup. From what I saw in the code it doesn't need anything more advanced than libsigc++ but then libsigc++ requires an up-to-date compiler. Actually, it does rely more heavily on some modern C++ constructs, so it is more demanding than sigc++. Greets, Asger
Re: GUI independence and XTL
Hi, On Tue, 22 Feb 2000, Allan Rae wrote: On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote: I've looked at the code and read the manual for it a couple of times on the bus. So I agree it's exactly what we need. I did that too and I admit I dont get what this is suposed to do for LyX? Do you intend to have a new file format? Btw XDR is a platform independent format for binary representation. I use XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with some automatized traversal, but what would that be needed for? Am I clueless or missing imagination here? Roland -- Roland Krause Visiting Research Associate - Center for Computational Mechanics Washington University, Saint Louis
Re: GUI independence and XTL
On Wed, 23 Feb 2000, Roland Krause wrote: I did that too and I admit I dont get what this is suposed to do for LyX? Do you intend to have a new file format? No. A better way to shift data between the various components of LyX (internal or external). Btw XDR is a platform independent format for binary representation. I use XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with some automatized traversal, so far so good. but what would that be needed for? Am I clueless or missing imagination here? You almost answered your own question in the previous paragraph. Externalization. Whether its external to LyX or external to the core. As you will have noticed in the XTL documentation the optimized code for any of the fancier formats is no worse than about half the speed of a memcpy but it can be used to communicate to external clients -- a Python script or a CORBA-enabled bibliography database for example -- at almost no extra cost. Allan. (ARRae)
Re: GUI independence and XTL
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote: The best format is the raw format, since it's minimalistic and the fastest. We don't need interoperability with external sources, so the raw format is the best solution. That was what I thought the plain text was. The version I currently have only exports to raw but doesn't import. Allan. (ARRae)
Re: GUI independence and XTL
> I am intending to make XTL a part of the rae branch sometime this week as > I want to try it out communication with LyXFunc. I'll have to get the > latest release to see what's new. The version I have exports to plain > text but doesn't import from it. It seems very fast for CORBA and XDF(?) > formats. The best format is the raw format, since it's minimalistic and the fastest. We don't need interoperability with external sources, so the raw format is the best solution. Fortunately, this decision is so easy to change later, given the XTL setup. > From what I saw in the code it doesn't need anything more advanced than > libsigc++ but then libsigc++ requires an up-to-date compiler. Actually, it does rely more heavily on some modern C++ constructs, so it is more demanding than sigc++. Greets, Asger
Re: GUI independence and XTL
Hi, On Tue, 22 Feb 2000, Allan Rae wrote: > On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote: > > I've looked at the code and read the manual for it a couple of times on > the bus. So I agree it's exactly what we need. I did that too and I admit I dont get what this is suposed to do for LyX? Do you intend to have a new file format? Btw XDR is a platform independent format for binary representation. I use XDR a lot for numerical stuff. This XLT thing looks like XDR for structures with some automatized traversal, but what would that be needed for? Am I clueless or missing imagination here? Roland -- Roland Krause Visiting Research Associate - Center for Computational Mechanics Washington University, Saint Louis
Re: GUI independence and XTL
On Wed, 23 Feb 2000, Roland Krause wrote: > I did that too and I admit I dont get what this is suposed to do for LyX? Do > you intend to have a new file format? No. A better way to shift data between the various components of LyX (internal or external). > Btw XDR is a platform independent format for binary representation. I > use XDR a lot for numerical stuff. This XLT thing looks like XDR for > structures with some automatized traversal, so far so good. > but what would that be needed for? > Am I clueless or missing imagination here? You almost answered your own question in the previous paragraph. Externalization. Whether its external to LyX or external to the core. As you will have noticed in the XTL documentation the optimized code for any of the fancier formats is no worse than about half the speed of a memcpy but it can be used to communicate to external clients -- a Python script or a CORBA-enabled bibliography database for example -- at almost no extra cost. Allan. (ARRae)
Re: GUI independence and XTL
On Wed, 23 Feb 2000, Asger K. Alstrup Nielsen wrote: > The best format is the raw format, since it's minimalistic and the > fastest. We don't need interoperability with external sources, so > the raw format is the best solution. That was what I thought the plain text was. The version I currently have only exports to raw but doesn't import. Allan. (ARRae)
Re: GUI independence and XTL
On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote: Hi! Hello Asger! I've used it for a few things and can only say that it rocks your socks off. I think this is exactly what we need for the communication layer in the GUI indep-work. It's clean, fast, and very elegant if you ask me. I've looked at the code and read the manual for it a couple of times on the bus. So I agree it's exactly what we need. Regarding how to realize this goal: I'm wondering if we should try a small experiment after 1.1.5 is out: Include the latest XTL in the building step, and then apply the usual routine to work out what needs to be done to make the thing build on the various platforms. I am intending to make XTL a part of the rae branch sometime this week as I want to try it out communication with LyXFunc. I'll have to get the latest release to see what's new. The version I have exports to plain text but doesn't import from it. It seems very fast for CORBA and XDF(?) formats. The thing is that XTL requires a fairly advanced C++ compiler to work completely. (However, we can use a less ambitious subset of the system with older compilers, and that is still a nice solution. I know, because I had to do that in order to make it work with Visual C++.) From what I saw in the code it doesn't need anything more advanced than libsigc++ but then libsigc++ requires an up-to-date compiler. Allan. (ARRae)
Re: GUI independence and XTL
On Tue, 22 Feb 2000, Asger K. Alstrup Nielsen wrote: > Hi! Hello Asger! > I've used it for a few things and can only say that it rocks your > socks off. I think this is exactly what we need for the communication > layer in the GUI indep-work. It's clean, fast, and very elegant > if you ask me. I've looked at the code and read the manual for it a couple of times on the bus. So I agree it's exactly what we need. > Regarding how to realize this goal: I'm wondering if we should try a > small experiment after 1.1.5 is out: Include the latest XTL in the > building step, and then apply the usual routine to work out what > needs to be done to make the thing build on the various platforms. I am intending to make XTL a part of the rae branch sometime this week as I want to try it out communication with LyXFunc. I'll have to get the latest release to see what's new. The version I have exports to plain text but doesn't import from it. It seems very fast for CORBA and XDF(?) formats. > The thing is that XTL requires a fairly advanced C++ compiler to work > completely. (However, we can use a less ambitious subset of the system > with older compilers, and that is still a nice solution. I know, because > I had to do that in order to make it work with Visual C++.) >From what I saw in the code it doesn't need anything more advanced than libsigc++ but then libsigc++ requires an up-to-date compiler. Allan. (ARRae)
