sm-grimoire AT lists.ibiblio.org
Subject: Discussion of Spells and Grimoire items
List archive
- From: Seth Woolley <seth AT tautology.org>
- To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
- Cc: Duane Malcolm <d.malcolm AT auckland.ac.nz>, Andrew <afrayedknot AT thefrayedknot.armory.com>, sm-grimoire AT lists.ibiblio.org
- Subject: Re: [SM-Grimoire] Starting from scratch (again)
- Date: Tue, 10 Jun 2003 16:48:43 -0700 (PDT)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 10 Jun 2003, Sergey A. Lipnevich wrote:
> Duane Malcolm wrote:
>
> > 1. CVS update of the grimoire. Amazing for someone with a 56k modem.
>
> That's smart, and grimoire's user actions really resemble that of a
> programmer developing source code. What happens if there's a conflict
> though? CVS will effectively destroy the file's value with ">>>>>>>". I
> think rsync is much more suitable here.
>
I was thinking rsync as well.
> > 4. During an email conversation with Kyle, he mentioned he was wanting
> > to get the grimoire down to 1024 spells or less. And after thinking
> > about it. I think it's a great idea. I read an article about how a
> > flaw with linux is there are to many people rewriting software instead
> > on supporting, developing or adding missing features to current
> > software. That's not to say there shouldn't be a few of the same type
> > of application, ie. mozilla, galeon, etc... But anyway, let's say
> > there was a core grimoire and an extras grimoire, the core grimoire
> > would include the best of your basic software and the extra will
> > include others. Over time spells in the extra grimoire can be moved
> > into the core grimoire if it's supported by number of Sourcemage
> > users. Because the core grimoire is small, Sourcemage will find it
> > easier to support a core grimoire and be confident it works together.
>
> I don't see the point. How's supporting 2000 spells is different from
> 1000? If somebody wants a new spell, s/he creates it, and then somebody
> who needs it will fix it if it's broken. Spells that belong to the core
> are maintained all the time because they're needed by many. That's
> effectively the core of it.
I agree as well, sometimes I like to have those obscure spells, and a lot
of users have adopted their own obscure spells to follow up on. With
rsync gimoires, this won't be a big deal, anyways.
>
> > 2. Can cast most of the recent versions of spells, eg, cast
> > mozilla,1.3a or cast mozilla,1.4, there are a default set of BUILD,
> > CONFIGURE files and if the BUILD is different from default there is a
> > BUILD,1.4 file.
>
> So that eventually the grimoire will grow to unmanageable size having
> all Mozillas from 0.9.7 to 10.11.12?
If we supported multiple version, please make it be only sparingly used.
Currently, I don't mind the current way we do it -- just have another
spell with 2 after it or -devel or something.
>
> > 3. It also has a flag for the size of the source which can give an
> > estimate of the download size.
>
> We can jam that into MD5 preparation routines when they're sufficiently
> automated.
I'd rather not, as wget does a good job of determining file size and eta
at least sourcefile-level, and who's to say how fast programs will
compile? Seems kind of overkill for not much benefit... with more
broadband... download size won't be much of a big deal. It also doesn't
help when different servers have different bandwidth caps, etc.
>
> > 4. Compile viewer gave a % completion for the compilation of a spell
> > also had simutaneous casting. Craig will tell you more about this.
> > This is what crashed during my rebuild process and where I gave up.
>
> I have 100% CPU utilization during compilation all the times and on
> different systems. How would running two GCCs at once improve timing?
It won't unless you are on SMP.
- --
Seth Alan Woolley <seth at tautology.org>, SPAM/UCE is unauthorized
Key id 7BEACC7D = 2978 0BD1 BA48 B671 C1EB 93F7 EDF4 3CDF 7BEA CC7D
Full Key at seth.tautology.org and pgp.mit.edu. info: www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)
iD8DBQE+5m5d7fQ833vqzH0RAtAIAKCN06GB7SEw4Mg2NpxdG/K7KqdVowCfVEMY
MIlNdlNZZaGwHy8bGYMxqXc=
=xfrU
-----END PGP SIGNATURE-----
-
[SM-Grimoire] Starting from scratch (again),
Craig Dyke, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Andrew, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Duane Malcolm, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Sergey A. Lipnevich, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Seth Woolley, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Andrew, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Seth Woolley, 06/10/2003
- Re: [SM-Grimoire] Starting from scratch (again), Dufflebunk, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Seth Woolley, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Duane Malcolm, 06/10/2003
- Re: [SM-Grimoire] Starting from scratch (again), Craig Dyke, 06/11/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Andrew, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Seth Woolley, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Sergey A. Lipnevich, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Duane Malcolm, 06/10/2003
-
Re: [SM-Grimoire] Starting from scratch (again),
Andrew, 06/10/2003
Archive powered by MHonArc 2.6.24.