Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] [Fwd: Re: minimize global effects in CONFIGURE and DEPENDS (Was: Using dialog for the net-conf spell)]

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: Robert Figura <rfigura AT aubergine.zwischengesicht.de>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] [Fwd: Re: minimize global effects in CONFIGURE and DEPENDS (Was: Using dialog for the net-conf spell)]
  • Date: Sat, 22 Apr 2006 07:39:57 -0700

On Fri, Apr 21, 2006 at 06:37:06PM +0200, Robert Figura wrote:
> On Sunday 16 April 2006 23:12 wrote Juuso Alasuutari:
>
> > I'm glad I've understood some of the issues here. So, do you have any
> > suggestions how we could further the goal and prepare the ground? As I
> > said, I feel a roadmap would be good. (Keeping in mind of course the
> > priorities of things with such a small crew that we have.)
>
> I think it would be especially handy to have a clean configuration
> dataformat. Gui configuration tools would then become a lot easier to
> realize (or feasible at all). Saving and even mergeing of configurations
> would relatively simple to implement. Should be quite useful in cauldron
> and prometheus as well.
>

Clean means fewer features. Right now it is turing-complete and with
rich interfaces into the system. The magical part of this distro is the
scriptable configuration format

> To ponder ahead: Will The dependency code of Sorcery play nicely? One way
> we
> have the case where the gui config tool results indicate that a spell has
> to be casted or removed. The other way is Sorcery signalling an additional
> spell's config to be added.
>
> The meat:
>
> - Currently CONFIGURE computes what questions to ask and then asks.
> Depending on the answers, different subtrees of the configuration
> become relevant. This is hierarchical!
> - Let's try to separate the code which finds out what config is relevant
> from the tree representing all possible configurations.
> - Sometimes questions will be implicitly answered based on scripted inquiry.
> - Thinking a bit deeper it may be useful to think of the DEPENDS as being
> related to CONFIG in this context.
>
> I'll address these issues:
>
> 1. A hierarchical and script-free configuration format.

This is unfeasable, for we lose power. My suggestion, which is to
require no global side-effects except on the last run doesn't limit
its power.

> 2. A set of external agents which may decide to make certain subtrees
> irrelevant before asking questions.

My suggestion accomplishes this, and all it takes is a re-parse of the
script.

> 3. Interface to Sorcery and dependency code.
>
> I don't know if 2. is relevant. At least it is nice.
>
>
> On one hand a line based config format has some advantages.
> - Easy to parse
> - Attracts hack-alike shortcuts i.e. may be bash-parseable

None of the suggestions below are backwards compatible. Furthermore,
they could be gotten out of my relatively compatible proposal. I might
need to fix fifty spells under my proposal. You're proposing we rewrite
them all for no actual benefit and many losses.

>
> But i'd like to focus on the fields first therefor i offer an example
> config
> file format like this:
>
> [VARNAME]
> # comment
> field_name=value_name
> ...
> [VARNAME2]
> ...
>
> where fields may be:
>
> # all nodes:
> REQUIRE="VARNAME=value" # this node is relevant if VARNAME=value
> TITLE="question to ask"
> HELP="if needed"
> DEFAULT="value"
>
> # one type per node:
> TYPE="YESNO"
> R[0]="--configure-option-no"
> R[1]="--configure-option-yes"
>
> TYPE="CHOICE"
> T[0]="option number one"
> R[0]="--configure-option-one"
> T[1]="option number two"
> R[1]="--configure-option-two"
>
> TYPE="PROVIDER"
> WHAT="GLUT" # for example
> # could be merged with AGENT:
>
> TYPE="AGENT"
> COMMAND="ls spec/config.spec" # let pwd be SPELL_DIR
> # commands are executed as soon as they become relevant
> # they write a list of options to stdout or a single one if no choice is
> # possible
>
>
> Some common sense additions: Definitions should be strictly free of forward
> references. Similar Conditions should be grouped. It should not reference
> any sorcery internals from COMMAND.

This command variable isn't magical to me.

>
> Answering the questions should result in the same 'protocol' for BUILD (and
> friends) as we have it now:
>
> VAR_NAME="value"
>
>
> Now the hard part: How to integrate into sorcery.

My proposal required no integration into sorcery. Sorcery stays the way
it is. We want less code in sorcery, not more.

>
> First we need a way to communicate the answers back to sorcery. This could
> be done by piping a simplified CONFIGURE (only simple assignments).

You've broken most of its power.

> Or by
> generating proper tablet entries (doesn't feel right, though).
>
> Also we need to address the dependency issue: As noted before dependencies
> are similar to configuration. If we do not merge these two we'd need to
> have communication between sorcery and the gui:
>

I'd like you to take a look at the sorcery code that handles dependency
resolution and see if you think it's feasable to have every gui
implement it, including all the sub-depends and up/down trigger logic.

> gui says: added/removed an optional_depend
> sorcery answers: add/remove these sub-depends...
>

It doesn't work this way -- the code flow would have to be completely
rewritten.

> (I think this idea was already stated in this thread near the client/server
> buzzword. Maybe a request executes sorcery^wgaze and the reply comes on
> stdout - as simple as that)

Yes, I shot down that idea.

>
> If we merge we have all the nice code in sorcery to compute dependencies to
> be reviewed or implemented again in the gui. May be faster though.
>
>
> Now i see a slight redundancy since BUILD has sometimes to restate the
> hierarchy in order to make sense of the configuration:
>
> if [ "$VAR_NAME" = "y" ]
> use "$VAR_NAME_SUB1"
> else
> use "$VAR_NAME_SUB2"
> fi

This isn't restating hierarchy, this is a first-level ? : trinary
operation and if those vars go on the ./configure line it can be done on
the optional_depends line. We could add a "this if yes" "otherwise
this" setup to config_query/etc. for the non-dependency case into the
existing sorcery code without reimplementing,

>
> Would be nice to have this automated as well but this is not worse than it
> is now. Don't think that's very easy without severely disturbing the
> current spell format. Probably this doesn't matter at all and i'm
> hallucinating.
>
>
> I'm not 100% sure about how many of the spells do sophisticated stuff in
> CONFIGURE and if there might be cases which are impossible to convert.
>

There are, see mutt, linux, etc.

>
> Many details missing, no code yet. Comments Welcome.
>
>
> Regards
> - Robert Figura
>
> --
> /* mandlsig.c v0.23 (c) by Robert Figura */
> I=1702;float O,o,i;main(l){for(;I--;putchar("oO .,\nm>cot.bitamea\
> @urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l=
> 0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss




Archive powered by MHonArc 2.6.24.

Top of Page