Skip to Content.
Sympa Menu

sm-users - Re: [SM-Users] menuconfig for casts

sm-users AT lists.ibiblio.org

Subject: Sourcemage Users List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Wed, 14 Dec 2005 13:52:06 -0800


On Wed, Dec 14, 2005 at 09:23:39PM +0100, Thomas Orgis wrote:
>
> 1. You get asked many questions in a linear way. Your answers are final (so
> it looks to me). What to do when in a cast with several spells you type
> accidentally "y" where you wanted to type "n"? Abort and redo all answers
> that have been answered already?

Actually, it remembers the answers you just gave so you dont really have
to think about them again.

>
> 2. There are different kinds of remembered/guessed answers (default value
> and automatic answering without possibility to change it). I don't yet
> understand how and why... there is this conflict of having as much as
> possible worked out / remembered correctly by sorcery but still being able
> to change _this_ particular option. Much code (that's a guess;-) determines
> if a question is asked at all.

There is no code in sorcery that guesses an answer for you and uses it
without the user agreeing to it. Im not sure what you're trying to say.
I'll point out that backing up after you answer a question isnt really
a trivial thing to do in a robust and efficient way. Theres a lot more
going on then whats just presented to the end user. All relavent spell
files are shell scripts in a turing complete language, theres not really
any way to predict what they'll do without doing it or jump back in the
middle again.

>
> 3. The answer to a question may depend on the consequences it has.
> Do I want to cast support spell X? OK... but wait! This thingy pulls 10
> other spells in - no, that's not worth it!

Remember that spell files are not simple configuration files. Theres no
way to figure out what one will do without running it. Effictively this
is the turing problem in practice. The logical response is to execute
them in a different environment that avoids the consequences of normal
execution. Thats non-trivial from a regular implementation standpoint
because again, spell files can do whatever they want and may not expect
to be run in some weird environment. Also it would never be accurate
because code execution depends on user input. Trying to predict what
the user will do is a lost cause. Sure you could have really dynamic menus
but without completely changing the entire paradigm of how spells work,
its not going to work very well.

Unlike other binary packaging tools you might be used to, or menuconfig, our
dependency resolution phase is non-deterministic (spells have options, unlike
prebuilt packages). Prebuild packages and menuconfig use an effictively
static configuration, theres not really any dynamic code thats executed
when selecting a menu item, and if there is, its very limited, unlike
spell files.

>
> 4. There are some spells that have lists of options of some common type to
> choose from - example is glibc's locale choice. There I see a menu where I
> can quickly mark the few locales I want instead of saying y or n to all of
> them.
> There is the more complex xorg configuration using menu and choice lists.
> There are other spells that would benefit from such a behaviour (net-tools
> is a good example).
Those are per-spell and usually for one consistent thing.
Tying them all together into a unified whole that
works like menuconfig is an entirely different problem.
Again, static configuration vs scripting language.

>
>
>
> I see a similarity of the cast configuration step to what the kernel's
> `make menuconfig` has to to. We have many yes/no items, lists of choices,
> some structural hierarchy, interdependencies (with dynamic restructuring of
> menus)...
Spell files would all need to be touched to ensure they could be executed
repeatedly with no bad consequences. Realize that this would change all
the rules the scripts are executed under. This is as opposed to menuconfig
where each list item just refers to some part of a static configuration
chain, as opposed to a fully dynamic turing complete setup like whats
in spells.

>
> I kindof remember that the kernel config user interface started somehow
> where SMGL config is now... the same evolution towards menuconfig (and the
> choice to do it either way!) in SMGL would make a great pile of sense, IMHO.
>
>
> So, here is my propostion: Menuconfig for spell configuration!

Easier said than done unfortunatly. I'm not saying its impossible and
could never be done (it certainly could, but the cost/payoff tradeoff
doesnt really look good at this time) or that out of the box thinking
isn't useful (it is, and I really like hearing feedback and new ideas),
but doing this in a useful way would require a lot work in both sorcery
and across all 3000 spells in the grimoire...

-Andrew


--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page