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!
[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 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")
"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
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
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>
[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 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 ==
"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
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.
>
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
> 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
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
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
"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
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
"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
> "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
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
> | >
> "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
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
"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
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
"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
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
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
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
> "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
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
> "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
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
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
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
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
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
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]
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
> 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
> 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]
> 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
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
[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
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
> 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
[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
> 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
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(?)
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?
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
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
> 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(?)
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
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
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
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.
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
56 matches
Mail list logo
