Messages in this thread | | | Date | Mon, 24 Jul 2000 21:03:27 -0400 | From | "Eric S. Raymond" <> | Subject | Re: CML2 0.7.1 is available |
| |
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/
| |