sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
- From: Sergey A Lipnevich <sergeyli AT pisem.net>
- To: Mark Andrews <msasgl AT msa-enterprises.com>
- Cc: SM-Discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] sorcery purists do not read!
- Date: Tue, 10 Dec 2002 11:57:57 -0500
Mark Andrews wrote:
Hello Sergey,It brings the old questions of trying to automate a decision on what part of coolthing-b5-beta-18 is the version, and if coolthing-6.5 is a higher version than the former. Going in the direction of blending different pieces of data together in such way will bring you nowhere.
Tuesday, December 10, 2002, 3:10:37 AM, you wrote:
SAL> Just a couple of notes. Versions in spell (directory) names are quite SAL> difficult to version-track.
Depends if it's a computer or human doing the tracking ;-) At this
stage having the versions in the spell names and the spell names in
one place makes my life a lot easier. I can see where I'm at. Hey look
my autoconf-2.56 should be autoconf-2.57 8-)
I suppose previous versions might be needed, and the URLs in two similar versions of the spell are almost the same, and some files similar to BUILD will be completely the same. Unless there's only one directory for each spell (which will have to be enforced).
SAL> Then, even though advanced systems like Perforce can handle it,
SAL> exported grimoire would include too many similar files.
Not sure what your point is here, but grimoire is a somewhat fuzzy
concept at this stage in my code, which is experimental after all.
With the version information in the spell name, there will be far far
fewer updates but more "new" spells. Tracking updates is less of an
issue with this design IMHO. Rampant grimoire growth could be a
downside though..
No, I mean something which would allow sort spells in the order of dependency for casting. Currently, it's done with an elaborate part of code which builds dependency trees using bash variable names (which is either awesome or disgusting depending on one's programming tastes).
SAL> Also, zsh still doesn't have hashes and multi-dimensional arrays,
SAL> or does it?
There's a hash command for command / directory hashing if that's what
you mean.
There's associative arrays, but not multi-dimensional AFAIKThat's something definitely worth consideration. I guess that's the ultimate feature of any shell in existence before it becomes a "scripting language".
but isn't that the same in bash?That's why I asked. I'm trying to figure out what does zsh has to offer beyond bash. Is it GPL by the way?
You certainly can declare an intermediate local variable and do your thing. You were referring to sed and awk features that are in zsh, maybe you could elaborate on that?
SAL> I'm also wondering what might zsh have that bash doesn't in
SAL> various ${} var expansion constructs?
Things like ${$(locate "*.h"):t} which fall over under bash but work
great in zsh spring immediately to mind. There's a lot of extra ways
to do things in zsh due to the support of nested parameters like
this. I kept having problems trying to do things like this when I was
Thanks!
Sergey.
-
Re[2]: [SM-Discuss] sorcery purists do not read!,
Mark Andrews, 12/09/2002
-
Re: [SM-Discuss] sorcery purists do not read!,
Sergey A. Lipnevich, 12/09/2002
-
Re[2]: [SM-Discuss] sorcery purists do not read!,
Mark Andrews, 12/10/2002
-
Re: [SM-Discuss] sorcery purists do not read!,
Sergey A Lipnevich, 12/10/2002
- Re: [SM-Discuss] sorcery purists do not read!, Dufflebunk, 12/10/2002
- Re[2]: [SM-Discuss] sorcery purists do not read!, Mark Andrews, 12/10/2002
-
Re: [SM-Discuss] sorcery purists do not read!,
Sergey A Lipnevich, 12/10/2002
-
Re[2]: [SM-Discuss] sorcery purists do not read!,
Mark Andrews, 12/10/2002
- Re[3]: [SM-Discuss] sorcery purists do not read!, Mark Andrews, 12/10/2002
-
Re: [SM-Discuss] sorcery purists do not read!,
Sergey A. Lipnevich, 12/09/2002
Archive powered by MHonArc 2.6.24.