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: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-users AT lists.ibiblio.org
  • Subject: Re: [SM-Users] menuconfig for casts
  • Date: Wed, 24 Jan 2007 15:30:08 -0600

On Dec 21, Andrew Stitt [afrayedknot AT thefrayedknot.armory.com] wrote:
> On Thu, Dec 21, 2006 at 08:23:20AM +0200, Juuso Alasuutari wrote:
> > On Thursday 21 December 2006 01:23, Eric Sandall wrote:
> > <snip>
> > > We do have defaults, at least for queries, but not optional dependencies
> > > (though those can be set by using `sorcery default add ...`.
> > >
> > > Perhaps another Sorcery feature would be to 'silence' queries/optional
> > > dependencies which have already been answered. If you enabled this
> > > option, you wouldn't be asked to continue using xorg to provide X11-LIBS
> > > *unless* you used -r when casting. Would that work?
> >
> > I think all pre-answered prompts should be skipped, it shouldn't only be
> > an
> > option. On the contrary I think an uninterrupted configure && depends
> > phase
> > should be the norm whenever possible, afterall we do have -r for
> > reconfiguring.
> >
> > Maybe if this would become the norm we could then add a refined -r option
> > to
> > cast that would let the user define what kind of prompts should be
> > re-asked
> > during cast. That way it wouldn't be an all-or-nothing situation, but
> > instead
> > you could decide to recast e.g. all your X11-dependent spells and only
> > have
> > the provider prompts bother you (and in all other cases have them _not_
> > bother you, unlike now).
> >
>
> This (and the other rescent comments) are just one particular instance
> along the continuum of how eager sorcery should be about asking questions
> and how hard it should look for a default. This particular instance
> is just near one of the extremities, biased against asking questions.
> Really what you're asking for is a higher degree of granularity between
> cast with and without -r. Not everyone wants the same behavior of course.

I also think that somewhere this sub-thread jumped from "don't have sorcery
ask the same provider question twice in the same cast" (e.g. asking for an
X11-LIBS provider once for xpdf and then also asking it later on for xmms)
to "don't have sorcery ask the 'continue to use...' provider question on
subsequent casts of the same app" (cast xmms && cast xmms).

I would say that the latter makes sense, since it doesn't make much sense
to the user if they're asked something they answered last time (assuming
they didn't specify -r). The former I would definitely not want, as
sometimes I really do want to use different jpeg providers for two
different apps (sometimes), or don't want everything that can use jpeg
support to use it (very often), and this is a primary reason I started
using sourcemage.

> I think any future discussion needs to be outside the realm of personal
> preferences about individual questions and on the larger picture of how
> to control what questions users are asked and when.
>
> Please frame this discussion within the context that PREPARE,
> CONFIGURE and DEPENDS may only be executed *once*, and may not be
> parsed. You absolutely can not run them more than once, you can not
> make any assumptions about what they do, what the code looks like,
> none of that. You may only assume that when the files want to ask
> the user a question, control eventually ends up in a grimoire/sorcery
> function. Within that function you do not and can not know the answers
> to subsequent unasked/unanswered questions.

But you can know the answer to previously answered questions for the same
spell, correct? Is there a particular reason we have the 'continue to use
<provider x>' question when -r wasn't used? As noted init.d is the other
place that happens but that's the grimoire's problem now.

> Sorry if I seem blunt or like Im being difficult, but if we want to have
> a productive intelligent technical discussion, we have to talk about how
> things actually work, not how we want them to work or think they work.
> This particular (year-old) thread had some issues with that, and I'd like
> to move past that.

Yes it's a year old but it's also a recurring theme and one day I'll
actually have time to read the whole thread. :-)

Attachment: pgpZrklmvnrdd.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page