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: Fri, 16 Dec 2005 19:18:05 -0800

First of all, I have to ask, have you (or anybody else who wants to
trivialize menuconfig'ing spells) actually programmed interactive menu
based systems? I dont mean that to sound belittling, but I want to know what
level I need to explain things at.

Second, cast has two main phases, the first phase is called 'depends
resolution', this is PREPARE -> DETAILS -> CONFIGURE -> DEPENDS and a
few other things. All important questions are asked here. There is no
deterministic ordering of spells to be processed, cast is processing each
spell once, and growing its list of other spells it needs to process
until whats called closure is reached, which means there are no more
spells that need to be proccessed. The second phase of cast is the
build phase, this is PRE_BUILD -> BUILD -> PRE_INSTALL -> INSTALL ->
FINAL plus some sorcery code to commit information to permanent disk
based tables or clean things up depending on the spell's result. This
phase has a deterministic order which is determined by dependencies and
triggers determined from depends resolution. This is a quick 50,000 foot
view of whats going on intended to give insight into what im refering
to and hopefully reduce any miscommunications.

>
> Wait. Yes, I already noted that spells consist of shell scripts... but are
> they really allowed to do everything? Could a spell config script do `rm -f
> /boot/*` ? I'd think that spell scripts (apart from install) should only
> (be able to) access system information in a read-only way and store their
> config/do their compilation in a confined place. And besides what is
> allowed for them to do, what is possible in reality? Can one guarantee a
> certain set of commands to be available to the scripts (sed, perl, ...)
> even on a very, very minimal system? How far does the turing completeness
> go in reality?

spell scripts can do whatever they want, including remove everything,
so can sorcery, so can *any* program you run within its permission limits.

What I meant though was that there can be logic based on user input. So, for
a trivial example:

optional_depends foo
if query "do you want x?"; then
optional_depends bar
y=bar
else
optional_depends qux
y=qux
fi

if [[ $y == bar ]] ; then
query "do something else" ...
fi

Yes this is a trivial example, and yes the second 'if' could be folded
into the first, this is just a summary of a more complicated hypothetical
situation where something like that might be needed.

Making a useful menu for that would be difficult. The ideal menu would
look like kinda this, i guess.
[ ] optional depends foo?
[ ] Do you want to use x?
[ ] optional depends bar
------
[ ] optional depends qux
[ ] do something else?

In practice to take the above code and magically turn it into a menu,
you'd have to execute it, then when you get to the conditional, execute
both branches. This gets even more fun when you bring loops, recursion
or just nested control structures. To actually implement this, we'd
have to catch all the control structures and do non-trivial error prone
things with them. You could make a bunch of menus for each step, but
thats what we already have. Auto-generating a menu from a script that
intends to run linearly could be a fun thesis for someone, but again
I think theres more urgent feature requests to fulfill. Keep in mind
theres a big heap of sorcery feature requests.

It might be possible to have a question asking if you want to re-process
a spell. After completing it. Internally all the settings from a spell
are (mostly) committed into the larger data structures once the spell's
processing is done.


>
> > any way to predict what they'll do without doing it or jump back in the
> > middle again.
>
> Ok, but - for a start - what's with not jumping back in the middle but just
> have a hot-key to restart CONFIGURE for the current spell in a multi-spell
> cast? It should be possible to restore the state the spell's CONFIGURE
> started in; unless the script created - or worse: modified - some random
> files in the system... I think spells should be at most allowed to write to
> a temporary directory (subdir of cast/xxxx ?) and the unpacked source
> directory, of course. At the final install stage, there are some files in
> the system to be modified, of course... but everything before that
> shouldn't have any reason (and possibly possibility) to do that.

Im not talking about the build phase, theres no building done during
depends resolution (if there is, its a bug), and your request would only
apply to depends resolution (that first part of cast). However its true
that following one path might set up something that would later confuse
something or break an assumption, so who knows how well that would work
in general.

>
>
> > [much more about problem complexity, dynamic structure, weird places...]
>
> OK, you have quite some points there... I still think that in principle the
> configuration could be done in a menuconfig-like way (on the look-and-feel
> side, not internally) for a whole cast together, but I see that the spell
> design would have to take care of being able to go back and forth, support
> enabling and disabling of things. So even if this could be done, it won't
> be done in the near future.
>
> What I think is possible, then, is to drop the whole-cast approach and to
> provide sorcery functions for the spells that do what some spells (glibc
> with locales) do now with self-coded dialog scripting, I guess. Extending
> the API so that spells can easily let their configuratuion step appear as
> (nested) menus.

Or a grimoire library... The movement is to do stuff like this in
grimoire libraries and have sorcery provide lower level interfaces.
Helps avoid version skew issues and helps facilitate more rapid innovation.

>
> Instead of
>
> config_query VAR "Question?" y
>
> for every option, I'd like to specify the list of options/questions somehow
> (with some means to indicate relationships between options) and execute
>
> config_menu
>
> to get my variables set by the user working in a menu. I have to think a
> bit about the DEPENDS file since I'd like to have it integrated, too.

You could do things that way, personally, I wouldn't want a menu forced
on me though.

>
> This approach leaves existing spells unharmed (would they get an error if
> they define a config_menu function themselves?) and would give me the
> non-linearity that I want for the more complex spells.

For what its worth we have procedures in place for sorcery/grimoire
version skew.

>
> Is there opposition against that API extension (supposed that probably I'll
> do the work and manage to write such a menu function / its helpers to
> specify the structure)?

I doubt there would be if you went ahead and started. Although like I
said before, it would probably have to fallback to the linear questions
if the user doesnt want a menu. I'll be happy to help you write dialog
based stuff or extend sorcery APIs to help, assuming the extensions make
sense. Irc tends to work better for those discussions than email though.

So to summarize, you've picked the right approach, which is to start by
menu-ifying spells, once thats done the process of menu-ifying the entire
depends resolution process might be a more realistic idea than it is now.

-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