Randy Dunlap <randy.dunlap@intel.com>:
> > The upshot is your EXPLs are gone but those symbol prompts should now
> > have (EXPERIMENTAL) appended.
>
> That's good news. Somewhere in my patch file or in applying/modifying
> it, one line got mussed up. Patch attached.
OK, I've applied this kernel-symbols patch and the corrected kernel-rules
patch you followed up with.
> > If you're seeing anything but off-by-ones relating to syntax errors
> > at end of line, tell me. The off-by-ones are a known bug which I
> > would have to tremendously complicate the lexer to fix.
>
> No, this was by a few hundred, but it could have been (my) user error or
> not reading which file name (kernel-rules, kernel-symbols, or
> kernel-menus) had the error at the listed line number.
> I'll let you know if I see it again.
OK. It is highly unlikely that the lexer could get it that badly wrong;
the code is brute-force simple
> > I don't know of any forward-reference problems in the 0.7.2 rulebase.
> > I see that you commented some stuff out. I'll try uncommenting it and
> > see if I get any forward errors.
>
> I uncommented:
> # unless SOUND!=n suppress USB_AUDIO
> and have a forward-reference error.
> (BTW, this line is changed to <above> in the attached patch file.)
I see that. This is a rulebase-design problem. As the new section on
rulebase design in the manual observes:
<sect1><title>Good style in rulebase design</title>
<para>The configuration experience defined by a CML2 rulebase can vary greatly
in its degree of apparent complexity to a human user, depending on how
much context and interdependency information the user has to keep in mind
to get through the process. In general, you want to minimize this cognitive
load. </para>
<para>Good choices of menu organization and rules can help accomplish this.
In particular, human beings will find easiest a sequential set of
questions in which few questions depend on questions previously asked,
and <emphasis>no</emphasis> questions depend on questions that are
asked after them.</para>
<para>Most CML2 declarations can be written in any order, and CML2 constraints
can reach either forwards or backwards in that order. But the full power
of this generality unleashed creates rulesets that are hard for humans
to reason about. So it's good style to use that power in a more controlled
way.</para>
<para>To do this, it's important to think about three different
ordering relationships. The first is the order of declarations in the
rulebase. The second is the "natural" order of questions in the menu
tree -- a depth-first or preorder traversal defined by the ordering
and inclusion relationships in the menus. And the third is the order
in which human users driving the configurator will normally answer the
questions.</para>
<para>To make life as simple as possible for developers and users, these
three orders should largely coincide (though the order of declarations
in the rulebase is only important for readability by developers,
and need not be as tightly coupled
to the other two orderingss as they should be to each other).</para>
<para>To remind you of this, the compiler warns about uses of question
symbols in a visibility-guard or dependency expression for a symbol
occuring <emphasis>before</emphasis> the associated question in
preorder. This is what the compiler warning "FOO depends on ['BAR']
forward" means.</para>
<para>There are other heuristics you can follow to keep life simple.
Holding explicit dependencies, requirements, and visibility
expressions (as opposed to implicit ones defined by the menu
structure) to a minimum is an important one; these, typically,
represent links across the tree rather than locally from parent to
child nodes, and complicate things.</para>
<para>Also, put global questions that will greatly constrain other choices
early in the preorder, even if this sometimes means separating them
from submenus that perhaps would naturally go beneath them.</para>
<para>In the Linux kernel configuration rulebase, for example, there
is a `buses' menu that contains enabling symbols for major subsystems
like IDE, SCSI, and PCMCIA. The menus for IDE, SCSI, and PCMCIA are
not beneath this menu as might seem natural but rather later on in the
preorder. The reason for this is that some devices have
cross-dependencies on more than one bus or controller type (there are
PCMCIA SCSI cards, for example.) To avoid forward dependencies, it's
best to group all of these bus/controller symbols before the hardware
driver menus they control.</para>
</sect1>
Once this machinery is in place, the tree is un for some serious
reordering.
> > > 5. You said that you expect the curses interface to be the most-used
> > > one and I agree with you. The tkinter interface, in its present
> > > form, is very klunky (a highly technical term, of course).
> > > I can go into details and examples if needed.
> >
> > Please. I went to some lengths to try to make it nice; if I failed, I'd
> > like to know why.
>
> Will be in a separate email.
OK, I got it. Will respond shortly.
-- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>"To disarm the people... was the best and most effectual way to enslave them." -- George Mason, speech of June 14, 1788
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:18 EST