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: Juuso Alasuutari <iuso AT sourcemage.org>
  • To: 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: Sun, 16 Apr 2006 23:51:38 +0300

On Friday 14 April 2006 23:40, Seth Woolley wrote:
> I don't think we need a complicated server-client distinction
> implemented in config_query.  We can override config_query* easily
> already, it's just the code around the config_query that can lead to
> problems.  I think we need a cli that merely has well-defined hooks that
> we 1) audit and 2) promise not to change frequently.  The audit is so we
> get the problems out of its use before we give a blessing to freely use it.

Well, yeah there are probably other ways to achieve "that authentic
server-client feeling" during cast and other operations. Right? As lost as I
am with technical words, I hope the bottom line is somewhat agreed on: to be
able to go back to the previous question, and to be able to easily implement
different (g)uis that make use of sorcery's power, and the possibility to
write scripts which talk to sorcery - these would rock. Please correct me if
I'm not talking about the original idea anymore...

Proper testing is of course a token, or at least should be. If and when
sorcery evolves towards something like this, I'm the first hobo on the block
begging for spare hardware on which to run testing stuff...

> Eliminating global effects during dependency resolution are all we
> really need to untie the interface from a one-pass-only interface.  It's
> that simple change from one-pass-only to "we can go back if we need to"
> that enables the gui interface, because the gui interface philosophy is
> "let me experiment and go back, commit last.

Of this I think I understand most of what's said.

> If we enforced restrictions on global effects by using installwatch to
> monitor what happens during configure and depends resolution on the
> filesystem and checked the environment before and after for bad things
> that's an optional feature that developers could turn on to lint-check
> things.

This I really don't get. But I don't think that matters at this point.

> Writing a front end that wraps around sorcery then is a piece of cake.
> What we have works.  Don't forget that we already have the delve tool
> that increases scriptability tenfold.  Let's try and minimize the actual
> changes we make to the current setup.

I feel stupid for not having a go at delve so far. But what you're saying
sounds good. But it also sounds like it needs a more detailed roadmap. Me and
David are guaranteed to help out once we know how.

I've been thinking about David's idea for the last two days, and I have some
kind of vision how cast could handle user interaction. I have very limited
understanding of sorcery as a whole, so this might be far off, but bear with
me anyway and please tell if it's a realistic idea.

1) Cast starts processing a spell file which requires interaction, e.g.
CONFIGURE
2) The file is read from top to bottom without stopping; config_queries don't
ask anything themselves, but only give cast information about what questions
are to be asked and what variables they set
3) The first query (config_query VAR1 yadayada...) is presented. The ui that
does this can be anything basically)
4) After an answer is received from the user, part 2) is run again, so that
possible "if [[ VAR1 == x ]]; then config_query..." options are revealed
5) Now the next prompt is presented, "next" meaning "the one following the
prompt which sets VAR1"

And so it goes on, until all prompts have been answered. The same happens
with
DEPENDS, and of course you can also later return to CONFIGURE after you've
left it.
Of course this kind of system means that you would have to strictly restrict
user interaction to specific spell files (almost done already), and allow no
other scripting in them. At the moment I believe PREPARE is allowed to have
both, so it couldn't be sourced multiple times like this.

Juuso




Archive powered by MHonArc 2.6.24.

Top of Page