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: Sat, 17 Dec 2005 22:47:15 -0800

On Sun, Dec 18, 2005 at 05:03:16AM +0100, Thomas Orgis wrote:
> Am Fri, 16 Dec 2005 19:39:37 -0800
> schrieb Andrew <afrayedknot AT thefrayedknot.armory.com>:
>
> > There is a rule. If you answer the question and the spell file completes
> > the answers go to the persistent configuration file, if you recast the
> > spell without -r, then the answers are re-used without prompting. In
>
> What is "spell file completes"? I remember having a cast with several
> spells; having made an error at configuring spell N. Ctrl+C.

A 'spell file completes' when the code stops executing and returns control
to the caller... In sorcery when this happens certain data is written out
to files. On subsequent casts it is re-read. However, hitting ctrl-c
in the middle of that file will not cause that data to be written out,
and those answers wont be remembered.

> Cast again: some anwsers for spells M<N are remembered non-promptly and
> some promptly... by that may be the spells doing stuff on their own as
> hinted in another mail...

I would suggest a different word than 'promptly', that has a different
meaning in english than i think you intend. Yes, I explained this in other
emails, some of the queries use a specific api that doesn't prompt after
the first answer, some use an older api, plus theres the narrow case
above where a spell file is interrupted.

And, as has been explained multiple times, you can circument all the
non-prompting by using the -r parameter to cast. Previous answers are
still remembered in that situation, except in the narrow case I mention
above with ctrl-c, and spells using the older api.

>
> > > jadetex failed because don't know: no compile log there
> > > gtk+ failed because X not there
> > > tk failed because of many compile errors ... somehow looks like
> > > assumed to have some X headers. Interesting that this doesn't fail when
> > > th header is not found but instead manages to produce many parsing
> > > errors with the non-defined stuff.
> > > qt-x11 because cups test failed (cups was selected but dropped)
> > > xdvi because no X (another circular one: X pulls jadetex for docu
> > > and this puts tetex in front of X on the row)
> > > arts because of no X (why the heck does a sound daemon need X?)
> > > lesstif of course because of no X
> > > aspell spreads some fear because of an internal compiler error
> > > (segmentation fault) in line 1016 of common/config.cpp
> > > pyrex failed - and that's a good one! - because python is not there
> > > (was on the install list)! Another circle closed.
> >
> > You should file bugs for each of those. Although menuconfig wont make
> > it any better...
> >
>
> Eh... most of them seems to be victims of circular dependency... whose
> fault is this? Do we need bug reports just to keep the term in mind for the
> day it may be able to handle it in sorcery?

Well, I already said how the problem is to be dealt with...theres a bug
open for 'suggests', and there supposedly was work done to make xorg not
depend on espgs, but that either didnt happen or isnt in the grimoire
you're using. In either case, thats out of my range of responsibilities
and falls under the grimoire and qa teams.

> > It does do something for circular dependencies. However theres more it
> > can do, which is break the cycle at an optional dependency.
>
> Do you mean what I said (two builds (basic/fullfeature) to circumvent the
> loop) or block optional dependencies to prevent the circular dependency to
> come up at the first place?

I meant exactly what I said before. I couldn't quite figure out what
you were trying to devise. I dont think its particularly important
either way since there are other simpler solutions to the problem of
circular depends. I was pointing out that, yes, in fact the problem is
known, and the potential solutions have been well thought out as well...

There is plenty of code and unit tests to ensure reasonably sane handling
of circular depends/triggers (although it may not look like it, there
are far far worse things that could happen than what happens now). The
real problem is that theres no distinction between optional_depends for
runtime features vs convenience usage, eg it might be nice to build espgs
with xorg for enhanced documentation, but xorg is fine without it. *real*
circular dependencies are exceedingly rare in practice. Hance 'suggests'.

>
> > The other answer is to use a 'suggests' api, which
> > doesnt imply an ordering like optional depends does but allows the user
> > to build stuff that might be useful.
>
> Could you explain what this should mean - saying yes to a suggestion
> doesn't cause the suggested dependency to be build if it would lead to a
> dependency loop? Something totally different?
>

It would add the spell to the list of things to be built (if its not
already installed), but not imply a relationship between the two.

A dependency implies that 1) the spell should be built if it isnt
installed already, and 2) an ordering between the parent and
child. 'Suggests' would be a convenient api to do the first without
the second.

-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