Hi,
On 12 Apr 2001, Steven Cole <[EMAIL PROTECTED]> wrote:
>
> Excuse me, but this seems to be something of a red herring. I've got
> a crowd of Pentium-90 and 100 machines at work, and they get new kernels
> occasionally, but I haven't built a kernel using that class of machine
> in 5
On Thursday 12 April 2001 10:51, Horst von Brand wrote:
> Steven Cole <[EMAIL PROTECTED]> said:
>
> [...]
>
> > It would seem to me that if someone is using an older and slower machine
> > to build a kernel, they are probably doing this somewhat infrequently,
> > and the longer build process, alth
Steven Cole <[EMAIL PROTECTED]> said:
[...]
> It would seem to me that if someone is using an older and slower machine
> to build a kernel, they are probably doing this somewhat infrequently,
> and the longer build process, although more painful for those few users,
> should be endurable if it i
On Thu, 12 Apr 2001, Steven Cole wrote:
> Excuse me, but this seems to be something of a red herring.
> ...
> Adding seconds or tens of seconds at this time on 2001 hardware will
> seem very moot by the time 2.5/2.6 is at the point 2.4.x is now.
Adding tens of seconds per build is not acceptabl
On Thursday 12 April 2001 06:07, Dave Jones wrote:
> On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
> > Unfortunately, I'm fairly sure that finishing gcml would take long
> > enough to render the point moot, because by the time it was done the
> > average Linux machine would have sped up enough for
On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
> Unfortunately, I'm fairly sure that finishing gcml would take long
> enough to render the point moot, because by the time it was done the
> average Linux machine would have sped up enough for the Python
> implementation not to be laggy anymore :-).
Aaron Lehmann <[EMAIL PROTECTED]>:
> Maybe you could kill two birds with one stone by calling 1.0.0 the
> prototype and rewriting it in C.
If I were to become absolutely convinced that I can't get acceptable speed
out of Python, I might do that. There's a gcml project that tracked the CML2
compi
On Wed, Apr 11, 2001 at 05:46:09PM -0400, [EMAIL PROTECTED] wrote:
> The speed problem now is in the configurator itself.
> One of my post-1.0.0 challenges is to profile and tune the configurator
> code to within an inch of its life.
Maybe you could kill two birds with one stone by calling 1.0.0
Alan Cox <[EMAIL PROTECTED]>:
> CML2 seems to have two other problems in my mind. Inability to parse
> the existing config files.
I gave upon that early for two reasons. One was practical; Michael tried this
with mconfig, and (apparently) failed. Or, at least, appeared to have decided
that path
> Eric did some performance analysis. If I recall correctly, all but 1
> or 2 seconds of CML2's runtime is in the parser. He has rewritten the
> parser once. Maybe someone needs to rewrite it again, maybe propagate
> some changes into the language spec to make it easier to parse, maybe
> rewrit
Michael Elizabeth Chastain <[EMAIL PROTECTED]>:
> I like mconfig, but I like CML2 better.
Reminder for the rest of you: Michael *wrote* mconfig.
> My primary reason is that ESR has more time to work on CML2 than I do
> on mconfig. And speed problems are often the easiest problems to solve.
>
>
I like mconfig, but I like CML2 better.
My primary reason is that ESR has more time to work on CML2 than I do
on mconfig. And speed problems are often the easiest problems to solve.
Eric did some performance analysis. If I recall correctly, all but 1
or 2 seconds of CML2's runtime is in the pa
12 matches
Mail list logo
