[Greg Banks]
> Have you assessed the impact of making the visibility guard
> (CONFIG_HOTLPLUG in this example) also a value limit for the symbols
> defined in the source'd file?
Not an issue, as CONFIG_HOTPLUG is a bool, and I see no conceivable
reason it should become a tristate.
But yes, when
Peter Samuelson wrote:
>
> [Greg Banks]
> > There are other ways to use "if" statements not covered by these two
> > cases, for example a couple of minutes of manual scanning reveals...
> >
> > int ' default tagged command queue depth' CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS 8
> > if [ "$CONFIG_SCSI
[Greg Banks]
> There are other ways to use "if" statements not covered by these two
> cases, for example a couple of minutes of manual scanning reveals...
>
> int ' default tagged command queue depth' CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS 8
> if [ "$CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS" = "0" ]; th
Peter Samuelson wrote:
>
> There are lots of instances of things like
>
> if [ "$CONFIG_FOO" = "y" -o "$CONFIG_FOO" = "m" ]; then
> dep_tristate 'Bar' CONFIG_BAR $CONFIG_FOO
> ...
> fi
>
> which can be replaced by
>
> dep_if CONFIG_FOO
> tristate 'Bar' CONFIG_BAR
> ..
[I wrote]
> > I guess I wasn't quite clear: my current implementation is both
> > visibility + value, not visibility only (like current if [ ]) or
> > value only (like an earlier discussion of dep_if).
[Greg Banks]
> Aha. I think you're going to be arguing uphill to get it in.
Could be. Per
Peter Samuelson wrote:
>
> > > > I think a better solution would be to provide separate "if"like
> > > > statements,[...]
> > >
> > > I think that is overengineering.
>
> [Greg Banks]
> > Sure. I was just saying that if we want a conditional statement
> > with combined value+visibility semantic
Peter Samuelson wrote:
>
> My current implementation of if_dep is *not*, as previously theorised,
> a drop-in two-way replacement for adding dependencies to the end of
> dep_* statements. I currently have it short-circuiting, so statements
> are in effect *not* executing in the 'n' case (or the
[Greg Banks]
> Ok, we need to be a little bit careful about semantics here, or
> there is going to be issues converting the existing corpus.
Agreed.
> Currently the "if" syntax and dependencies are not the same thing;
> the "if" condition is purely a visibility limit, and deps are both
> value
[Kai Henningsen]
> Incidentally, wouldn't it make sense to use "dep_if" instead of "if_dep"?
Yes, probably. I'll go ahead and change it in my tree, unless anyone
objects violently.
Peter
---
This sf.net email is sponsored by: OSDN - Tired o
Hi,
On Mon, 19 Aug 2002, Greg Banks wrote:
> If you wanted to add the ability to express this in CML1, you would need
> a completely different syntax for choices, say something like this:
>
> menuchoice next_comment
> comment 'Kernel page size'
> choiceitem '4KB' CONFIG_IA64_PAGE_SIZE_4K
Peter Samuelson wrote:
>
> My main goal is to make it easier to write Config.in files, by making
> the syntax and semantics less awkward. [...]
>
> * The current 'if' statement is really ugly and unintuitive,[...]
Agreed.
> * Current 'if' semantics are hard to get right in many common cases.[.
Peter Samuelson wrote:
>
> [Kai Germaschewski]
> > I didn't look into like choice statements, but I'd hope it's
> > possible to add dependencies to them, too, for consistency.
>
> I agree. Actually, if we're changing 'choice' anyway, it should be
> redesigned. Status quo takes three arguments:
Kai Germaschewski wrote:
>
> On Thu, 15 Aug 2002, Peter Samuelson wrote:
>
> > The more I think about it, the more I think the default if_dep should
> > do the m-restricting thing. That way:
> >
> > dep_bool FOO1 BAR BAZ
> > dep_mbool FOO2 BAR BAZ
> > dep_tristate FOO3 BAR BAZ
> >
> > is
[EMAIL PROTECTED] (Greg Banks) wrote on 16.08.02 in
<[EMAIL PROTECTED]>:
> No specific cases, but I was thinking that with your proposed syntax
> we'd have a large level of compatibility in both syntax and semantics
> between "if_dep" and "dep_bool", much more so than with "if" and
Incidentall
Hi,
Peter Samuelson wrote:
> +If you think in terms of Boolean algebra, most of the above rules make
> +sense if you think of each primitive value ("y", "m" and "n") as two
> +bits: "y"=11, "m"=01, "n"=00. Adjacent words are implicitly ANDed
> +together, and the "or" statement, with lower prece
Hi,
Peter Samuelson wrote:
> +If the dependency yields "m", the first block is executed and the
> +second skipped, just as with "y", but with one crucial difference: the
> +output for certain verbs is restricted. "bool" and "dep_bool"
> +statements are suppressed entirely; "tristate" and "dep_t
[I wrote]
> I've come up with syntax I think I'm happy with.
Thank you one and all for all the discussion and suggestions for
improvement on my proposals. I've incorporated a lot of feedback.
I know I promised to try and come up with a working prototype
including some Config.in files, but some
Hi,
On Fri, 16 Aug 2002, Peter Samuelson wrote:
> Basically the current discussion revolves around the best way to
> evolve the config language to make it more suitable for its purpose.
> This is of course in contrast to what ESR and you have tried, which is
> to replace the whole thing.
I have
[Roman Zippel]
> I really hate to spoil the fun
(:
> but could someone explain to me, why this is necessary? What
> problems does that fix?
It's not necessary, technically - it doesn't directly fix any bugs.
It falls under "cleanup", and as such, it is supposed to make bugs
harder to write an
Hi,
On Fri, 16 Aug 2002, Kai Germaschewski wrote:
> Oh well, I think the only way to find out if all that is really a good
> idea is to try, convert some config.in's and look at the result.
I really hate to spoil the fun, but could someone explain to me, why this
is necessary? What problems doe
[Kai Germaschewski]
> Seeing it from that point of view, it may actually turn into
> something which can agree with much more easily.
Great! I've been hoping for your support - not only because I respect
your judgment, but also because Linus takes patches from you. (:
> Maybe it actually suffi
On Thu, 15 Aug 2002, Peter Samuelson wrote:
> The more I think about it, the more I think the default if_dep should
> do the m-restricting thing. That way:
>
> dep_bool FOO1 BAR BAZ
> dep_mbool FOO2 BAR BAZ
> dep_tristate FOO3 BAR BAZ
>
> is exactly equivalent to
>
> if_dep BAR BAZ
>
On Wed, 14 Aug 2002, Peter Samuelson wrote:
> I've reused the syntax for a dependency line (the tail end of a
> dep_bool / dep_mbool / dep_tristate), like so:
>
> if_dep dependency line
> ...
> endif
Honestly, I do not like this. It's probably the best that can be done in
shell, but I
Peter Samuelson wrote:
>
> The more I think about it, the more I think the default if_dep should
> do the m-restricting thing. That way:
>
> dep_bool FOO1 BAR BAZ
> dep_mbool FOO2 BAR BAZ
> dep_tristate FOO3 BAR BAZ
>
> is exactly equivalent to
>
> if_dep BAR BAZ
> bool FOO1
>
[Greg Banks]
> Sure, but with something like "if_dep" <-> "dep_bool" and "if_mdep"
> <-> "dep_mbool" there exists a simple and bidirectional textual
> rearrangement which completely preserves semantics, to go between
> using the if and using the dep_*. This means people can safely
> switch betwe
Peter Samuelson wrote:
>
> [Greg Banks]
> > I was thinking that with your proposed syntax we'd have a large
> > level of compatibility in both syntax and semantics between "if_dep"
> > and "dep_bool", much more so than with "if" and "dep_bool"
>
> As you said the other day, "This is not a coinci
[Greg Banks]
> I was thinking that with your proposed syntax we'd have a large
> level of compatibility in both syntax and semantics between "if_dep"
> and "dep_bool", much more so than with "if" and "dep_bool"
As you said the other day, "This is not a coincidence." (:
But technically, if_dep c
Peter Samuelson wrote:
>
> [Kai Germaschewski]
> > Honestly, I do not like this. It's probably the best that can be
> > done in shell, but I think it's ugly and not intuitive.
> [...]
> The shell-syntax if [ ] might seem intuitive at first glance, if you
> already know the Bourne shell, but that
Peter Samuelson wrote:
>
> [Giacomo A. Catenazzi]
> > I don't like calling it "or"... It is error prone because it is a non
> > binary system,
> > thus can confuse the lazy developers.
>
> [...]But
> nobody thinks of "max" as an infix operator, and infix is IMO the most
> natural way to express
Peter Samuelson wrote:
>
> Greg, in regards to another question you had - no I don't think there
> is value in having a variant if statement that treats 'm' differently.
> You can already get the same effect by using 'CONFIG_FOO=y' or
> 'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
>
> You are m
[Kai Germaschewski]
> Honestly, I do not like this. It's probably the best that can be
> done in shell, but I think it's ugly and not intuitive.
I accept that it is not pretty. But unless we can switch to mconfig
or gcml2 or some other static parser for everything, we will need
shell-parsable s
[Giacomo A. Catenazzi]
> I don't like calling it "or"... It is error prone because it is a non
> binary system,
> thus can confuse the lazy developers.
I had to call it something. I for one think 'or' is quite intuitive
here. If you insist that OR can only be done on binary values, think
of '
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding examples
[Brendan J Simon]
> > Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
> Yes, the _s should be consistent.
Peter Samuelson wrote:
> * 'or' placed between dependencies functions as a logical OR, and
> takes very low precedence. This complements the implicit AND
> performed between every pair of dependencies.
>
> x or x -> x, for any x
> n or m == m or n -> m
> n or y == y or n -> y
Brendan J Simon wrote:
>
> Greg Banks wrote:
>
> >>[*] "almost enough" because I haven't implemented an 'else'
> >>directive. It would be trivial, but I'm not sure what to call it.
> >>'else' itself is a shell primitive, so the shell-based parsers
> >>(Configure, Menuconfig) wouldn'
Greg Banks wrote:
>>[*] "almost enough" because I haven't implemented an 'else'
>>directive. It would be trivial, but I'm not sure what to call it.
>>'else' itself is a shell primitive, so the shell-based parsers
>>(Configure, Menuconfig) wouldn't like it.
>>
>>
>
>You will nee
Peter Samuelson wrote:
>
> I've come up with syntax I think I'm happy with. It supports most of
> the current [ ] based if statement semantics, can be implemented in
> shell, and (most importantly for me) drops those $ signs. This lays
> the groundwork for stuff like better error checking and a
[I wrote]
> Mutating the language, long-term, so that it looks less like sh and
> more like a specialised language, is IMO a worthy goal. And I think
> it can be done. The main thing to deal with is adding an
> alternative syntax for 'if' statements which doesn't look like
> test(1). More abou
39 matches
Mail list logo
