Roman Zippel wrote:
>
> The problem here is one should consider, how all these little changes will
> help to solve the big problems. Do they allow to more easily fix the big
> problems or have these changes to be dumped again?
I believe fixing the existing rules within the existing syntax is an exercise
worth doing, and that the results will carry across to whatever extended syntax/
new language/new parsers/whatever will be the long-term solution.
Extending the CML1 syntax now is a fun game but a gamble.
> Most of the suggestions I've seen so far fix problems, which either can be
> either fixed automatically or which don't exists anymore, once we switch
> to a new syntax/parser. That's the reason I ask to understand the whole
> picture, so we can judge whether a change is really necessary or not.
Unlike you, I'm not optimistic that a switch to a new language or even a new
parser for the old language will ever happen.
> I can't give you a mathematical proof, but I tried very hard to keep the
> behaviour the same. Unless I made mistake the rules are almost exactly the
> same. Most of the CML1 rules are usable, there are only very few cases
> which need manual fixing. I can't guarantee that where won't be any
> surprises, but they should be easily fixable in the new system. (Unless
> ESR I don't insist that my rulebase is correct or perfect, so I'm open to
> suggestion/changes. :) )
In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
David Woodhouse gives an idea of what would be necessary to get a new
language+parser accepted. Can you achieve that yet?
> Most of these problems can actually be fixed without syntax changes.
Yes, a great deal of them can be, and those should be done ASAP.
> Something that can't be sanely fixed this way are recursive dependencies,
> which I think are not worth fixing with the old parsers, but which are
> easily fixable with the new syntax.
Indeed, and those are rare corner cases.
> If you want to fix logical errors in the rulebase, they will be more
> easily fixable with the new tools. For the X interface I'm planning some
> debug options, which e.g. allow you to see the complete dependencies of
> every symbol.
Or you could, today, go build gcml2 from source with "make DEBUG=1" and run
cml-check --debug nodes arch/i386/config.in
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
Hi,
On Mon, 19 Aug 2002, Greg Banks wrote:
> Unlike you, I'm not optimistic that a switch to a new language or even a new
> parser for the old language will ever happen.
It would be nice if I could get it into 2.6, but it's not a problem if it
has to wait. I'm currently busy getting menuconfig working again and then
I'm pretty much ready for a beta release.
> In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
> David Woodhouse gives an idea of what would be necessary to get a new
> language+parser accepted. Can you achieve that yet?
If you compare it to the xconfig output, yes.
> Or you could, today, go build gcml2 from source with "make DEBUG=1" and run
I looked through the list and except from real syntax errors nothing
prevents an automatic conversion.
I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set
by a choice statement and later redefined. My new parser can't deal with
this, because user input is given the highest priority.
bye, Roman
On Mon, Aug 19, 2002 at 07:27:50PM +1000, Greg Banks wrote:
> I'm not optimistic that a switch to a new language or even a new
> parser for the old language will ever happen.
I asked Linus specifically about the replacement of the shell based parsers.
The answer were quite simple:
- It should be convinient to use a new parser.
- Fast compilation, no errors etc.
It's doable.
> In http://marc.theaimsgroup.com/?l=linux-kernel&m=101387128818052&w=2
> David Woodhouse gives an idea of what would be necessary to get a new
> language+parser accepted. Can you achieve that yet?
David suggest to use randomly generated configurations, but they lack
one important feature. They are always valid, and a new system shall be
able to deal with hand-edited .config files in the same way as oldconfig.
Sam
[email protected] said:
> David suggest to use randomly generated configurations, but they lack
> one important feature. They are always valid, and a new system shall
> be able to deal with hand-edited .config files in the same way as
> oldconfig.
I suggested those as a way for testing the equivalence of the old and new
rulesets if the language changed. My main objection to CML2 was not the
language itself or the gratuitous use of python, but the fact that the
actual configuration rules were changed in extremely dubious ways.
Think 'provably correct transforms between AndreCode and C'.
You do also want to deal with hand-edited .config files in a similar manner
to the existing tools, yes -- but that's a different issue.
--
dwmw2
On Mon, 19 Aug 2002, Greg Banks wrote:
> Roman Zippel wrote:
> >
> > The problem here is one should consider, how all these little changes will
> > help to solve the big problems. Do they allow to more easily fix the big
> > problems or have these changes to be dumped again?
>
> I believe fixing the existing rules within the existing syntax is an exercise
> worth doing, and that the results will carry across to whatever extended syntax/
> new language/new parsers/whatever will be the long-term solution.
Let me just second this. This doesn't mean to try random changes hoping
that in the end the result is something sensible. But there are many cases
which are obviously bugs or deficiences, and fixes / cleanups there are
definitely a good idea as a first step.
--Kai
Hi,
On Fri, 23 Aug 2002, Kai Germaschewski wrote:
> > I believe fixing the existing rules within the existing syntax is an exercise
> > worth doing, and that the results will carry across to whatever extended syntax/
> > new language/new parsers/whatever will be the long-term solution.
>
> Let me just second this. This doesn't mean to try random changes hoping
> that in the end the result is something sensible. But there are many cases
> which are obviously bugs or deficiences, and fixes / cleanups there are
> definitely a good idea as a first step.
Let me mention (again), that we are talking about two different problems
here. On the hand bugs in the rulebase can be fixed with either syntax. On
the other hand major cleanups/extensions are better done with only a
single parser.
bye, Roman