On Sat, Mar 04, 2000 at 10:02:50PM +0100, Lars Gullik Bj&resh;nnes 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.
"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 tha
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 == "\
[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 De
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> inefficien
> 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 d
> "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 Lyx
On Tue, Feb 29, 2000 at 12:58:20AM +0100, Lars Gullik Bj&resh;nnes 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
> "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 s
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 y
On Mon, Feb 28, 2000 at 02:21:12PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bj&resh;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 asse
> "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
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 show
> "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 co
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
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 pa
> 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
> 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]
> 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 pars
André argues that we should not use XTL because we can do things with
a string. He thinks that the added complexity of another library is
not worth the hassle -- after all a text format is well-known, and
if it is well encapsulated, it's no problem.
Surprise!
This is exactly what XTL is: A wel
> 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 e
[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 automat
> 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 versio
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 currentl
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 form
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
> 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(?)
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
29 matches
Mail list logo
