CML2 1.0.0 release announcement
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 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 rewrite from Python to C.
Michael
Michael Elizabeth Chastain <[email protected]>:
Quoted 1 line
I like mconfig, but I like CML2 better.
Reminder for the rest of you: Michael *wrote* mconfig.
Quoted 8 lines
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 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 rewrite from Python to C.
The *language compiler's* runtime got cut in half when I hand-rolled a parser for it. 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.
Signature · 4 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> 'Faith' means not _wanting_ to know what is true. -- Nietzsche, Der Antichrist
Quoted 5 lines
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 rewrite from Python to C.
CML2 seems to have two other problems in my mind. Inability to parse the existing config files. Also the draw ordering in the menu based config doesnt appear right. Menuconfig has a rather undocumented but very important property of doing roughly the right thing with screenreaders. Something to bear in mind when fixing the menu redrawing stuff.
Alan
Alan Cox <[email protected]>:
Quoted 2 lines
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 was not worth pursuing.
The other was the procedural vs. declarative problem. I spent about a month after the kbuild team originally encouraged me to tackle the problem working on a design which I later labeled Thesis. This was an attempt to build a cleaned-up CML1, basically the existing language without the syntactic warts. I got as far as spinning up an incomplete implementation that could check toy configurations.
But the design basically didn't work. The problem is that a procedural language imposes a kind of time order that makes it very difficult to (a) do backtracking and (b) prove the correctness of your result. Perhaps a clearer way to put it is that configuration (like, say, screen widget layout) is fundamentally a constraint problem rather than a control problem.
A constraint problem needs a declarative rather than imperative language, and it needs a baby reasoning engine to generate a constraint-satisfying solution (Tk approaches screen-widget layout this way; that's thye source of its power). Neither of my strawman designs had significant advantage over CML1 until I bit the bullet and wrote a theorem prover to reason about timeless constraints.
Quoted 5 lines
Also the draw ordering in the menu based
config doesnt appear right. Menuconfig has a rather undocumented but very important property of doing roughly the right thing with screenreaders. Something to bear in mind when fixing the menu redrawing stuff.
Yes, I have plans for this.
Signature · 7 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Militias, when properly formed, are in fact the people themselves and
include all men capable of bearing arms. [...] To preserve liberty it is
essential that the whole body of the people always possess arms and be
taught alike, especially when young, how to use them.
-- Senator Richard Henry Lee, 1788, on "militia" in the 2nd AmendmentQuoted 3 lines · 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 the prototype and rewriting it in C. Not only would this improve speed (algorithmic improvements would also be welcome...), but it would remove the pythonic obstacle to its adoption as a standard. Many, including me, oppose writing the standard configurator in Python. I don't have Python installed and I'm not going to install yet another scripting language just because ESR likes it. Yes, we know about freeze support, but aren't convinced that it will do well at this. It seems that a native C configurator will be both faster and more portable (accross distributions and mindsets) than something requiring a recent version of SuperEasyInterpretedProgrammingLanguage 2.0.
I know that you're reluctant to make the port, but you don't need to be too shy to ask for help. Few people on this list are afraid of C. If you're too lazy to implement CML2 in a standard, popular, robust language, heck, tell us, and we may be able to help you out.
Sorry for the anti-Python flamage. I'm sure that it has its uses. I, however, don't view it as appropriate for configuration of an integral component of a GNU/Linux system. I want to make the view clear to aid Linus with his descision and to encourage a C port of CML2, which languages aside looks like a good format and concept BTW.
Aaron Lehmann <[email protected]>:
Quoted 2 lines
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 compiler up to about 0.72 level that might make a decent starting point.
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 :-).
No joke -- *you* try writing a theorem-prover in a language with only fixed-extent data types. Go on. Try it. I think you will (as Mark Twain put it about the consequences of teasing a cat) acquire a valuable education, the facts of which will never grow dim or doubtful.
I'm pretty sure that tuning the Python implementation (coming up with faster algorithms, perhaps by reorganizing the data structures to do more precomputation) will be a more effective use of my time.
Signature · 6 lines
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"One of the ordinary modes, by which tyrants accomplish their purposes
without resistance, is, by disarming the people, and making it an
offense to keep arms."
-- Constitutional scholar and Supreme Court Justice Joseph Story, 1840Quoted 4 lines · 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 :-).
'Average' Linux machine is irrelevant. I still have a Sparc IPX I occasionally use. I know people using still using 486's as they can't afford anything better. Hell, even some of my P5 class machines are starting to show their age, but they're still in daily use. To say "Screw them, upgrade" is not an option IMO.
Quoted 3 lines
I'm pretty sure that tuning the Python implementation (coming up with faster algorithms, perhaps by reorganizing the data structures to do more precomputation) will be a more effective use of my time.
Well if you can make this run faster, this would kill my main complaint with CML2. I'll try out an updated version sometime.
regards,
Davej.
Quoted 11 lines · Dave Jones
Quoted 4 lines · 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 :-).
'Average' Linux machine is irrelevant. I still have a Sparc IPX I occasionally use. I know people using still using 486's as they can't afford anything better. Hell, even some of my P5 class machines are starting to show their age, but they're still in daily use. To say "Screw them, upgrade" is not an option IMO.
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 years or so. I build new kernels using a dual 733 PIII. Just for "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but I have much better things to do with my time.
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 is indeed infrequent.
Keep in mind that making a kernel on a current machine has gone from a couple of hours (1992) to two minutes (2001). 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.
If you haven't seen my posts here before, I just joined this list last night.
Steven
Quoted 4 lines · Steven Cole
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 acceptable when you're building a lot of kernels each day.
The beginning of this thread showed a 15 second stall on an Athlon 800, vs a 1 second startup for the old system. The point now is that Eric _is_ working on improving the performance. (Which was probably in another post you missed).
Quoted 1 line
If you haven't seen my posts here before, I just joined this list last night.
Find a list archive, read the beginning of the thread.
regards,
Dave.
Steven Cole <[email protected]> said:
[...]
Quoted 4 lines
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 is indeed infrequent.
Please stop a moment and _think_.
There are people out there that have got a P/90 or less, or just a Sun IPX, no network access (or slow phone lines at high prices). That _you_ have a dual P3/733 doesn't help them one bit, now does it.
Signature · 4 lines
Dr. Horst H. von Brand mailto:[email protected] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Quoted 9 lines · Horst von Brand
Steven Cole <[email protected]> said:
[...]
Quoted 4 lines
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 is indeed infrequent.
Quoted 5 lines
Please stop a moment and _think_.
There are people out there that have got a P/90 or less, or just a Sun IPX, no network access (or slow phone lines at high prices). That _you_ have a dual P3/733 doesn't help them one bit, now does it.
Actually, I did think, and then thought a little more. Here is a snippet of what I posted earlier:
Quoted 7 lines
Upon further reflection, the added several second stall will probably be a thorn in many people's sides, as it comes while the user is impatiently waiting for it to launch. I don't use StarOffice because it takes 12-15 seconds to start up and that just seems too long.
So any efforts to reduce the stall will probably have a leveraged effect which is much greater than might otherwise seem at first glance.
Sorry, I guess its all too easy to get spoiled quickly with new hardware. And I'm one of those with slow phone lines.
Steven
Hi,
Quoted 7 lines · Steven Cole
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 years or so. I build new kernels using a dual 733 PIII. Just for "fun", I built a kernel using a uniprocessor 266 PII a few months ago, but I have much better things to do with my time.
I have an AMD K6/2-400. But I do know _many_ people who do own slower Hardware, and run Linux on it. They do not want and cannot afford to buy the newest shiny box. And, they have better things to do with their time as well. Please note, I live in a country where people are not _poor_. Just think of others some time, not only of yourself.
So long,
Jochen Striepe.
Signature · 2 lines
"He was so narrow minded he could see through a keyhole with both eyes ..."