Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] sorcery purists do not read!

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • To: Sergey A Lipnevich <sergeyli AT pisem.net>
  • Cc: Mark Andrews <msasgl AT msa-enterprises.com>, <SM-Discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] sorcery purists do not read!
  • Date: Tue, 10 Dec 2002 12:09:57 -0500 (EST)

On Tue, 10 Dec 2002, Sergey A Lipnevich wrote:
> Mark Andrews wrote:
> >Hello Sergey,
> >
> >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-)
> >
> >
> 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.
Yeah, I've done some work on automatic versioning. It's a bitch. On my
site I have a versioning.sh which does most versioning (probably >80%),
but when it is wrong, it's very wrong.

> >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..
> >
> 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> 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.
> >
> 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).
That variable name stuff is nicely abstracted as hashing (aka associative
tables) and graphs ;) I think it's quite nice, but then I'm a little
biased ;)

> >There's associative arrays, but not multi-dimensional AFAIK
> >
> That'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?
>
> >
> >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
> >
> >
> 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?
>
> Thanks!
> Sergey.
I believe he's refering to a way of crytographicly signing source code, so
that only the programmer is able to explain how it works... thus prooving
his identity as the author ;)
In bash you can't nest things in the first portion of a
${<variable><symbol><string>}, but you can nest after the first symbol.


--


Quidquid latine dictum sit, altum sonatur.
-----------------
PGP public key at
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3327A9A5
F1






Archive powered by MHonArc 2.6.24.

Top of Page