My tumblers work differently than the Xanalogical mode. There they are true numbers on which certain operations like addition and subtraction can be applied to address nodes (and all the nodes contained therein) whereas mine are not numerical at at and the operations that are performed on them do not have mathematical relationships. At least not in the Xanalogical sense.
Both systems (mine and Ted's) do allow ranges to be specified, but the mechanics differ. I'm not going to go into how Xanalogical tumblers work since that's described elsewhere. But I am going to describe what I'm working on.
Basically, my tumblers (for lack of a better term, that's why I'm using it
currently) is just a list of node identifiers, with those listed first
higher up than those below it, much like
USENET groups. You have
comp that contain all the computer related discussion groups, and
below that you have
comp.lang, which contain all the articles
pertaining to computer languages to finally having
comp.lang.forth, dealing with a
particular computer language. And you are not limited to just the period
for separating nodes—I also use slash and colon (for several reasons I
won't get into right now).
But another aspect is describing ranges. A range specifier consists of left and right sides separated by a dash. The left side specifies the starting node, while the right side specifies the ending node, relative to the starting node. So that:
would specify the nodes
A.b.1, A.b.2 and
that there are three node segments on the left side and only one on the
right. That's important. The missing segments on the right side are
inherited from the left. This inheritance only takes place if the right
side has fewer segments than the left side. If the right side is longer
than the left, it is assumed that the right side is a full specifier, like
the left side is.
The interpretation I use would return nodes
A.b.5 but nothing else in between. In this case, the comma is used
to specify to independant nodes, but with the same relationship rules used
in ranges. So far so good, but I want to be able to handle something like:
Which is a complex specification for:
1.2.3 1.2.4 1.5.3 through 1.5.5 1.3.8 through 1.4.1 18.104.22.168 22.214.171.124 126.96.36.199
I'm close to getting the parsing done.
I was hanging out with Mark and Jeff and one of the topics of conversation was over filesystems.
Okay, I'll admit up front we tend to be a bit geeky.
Anyway, a conversation about filesystems. I don't like the way Unix handles the filesystem, slapping everything under one tree, but I came from a rather heavy MS-DOS, VMS and AmigaOS background where you had volume labels (okay, so the support under MS-DOS was rather weak and ineffectual). Under AmigaDOS (for instance) if I have a floppy with a name of “StarControl” (which I actually do) and I insert it, I now have a volume I can look through called “StarControl:”. And if there is a program on that disk (which there is) it can reference files from the volume “StarControl:” such as “StarControl:config” or “StarControl:scenarios/galactic war”. And, copy protection concerns aside, I can copy the files off the floppy disk onto the harddrive (“Captain Napalm:”) into a games directory and then set the volume “StarControl:” to be equivalent to “Captain Napalm:games/star.control” and have everything work without problem.
“Ahha!” said Mark. “That's all great and everything but what if you insert two floppies with the same name?” Erm … ah … <cough> <cough> “And what if,” he continued, “I have a lot of volumes? There could be name clashes. Like both the C compiler and Pascal compiler looking for files from volume Compile?” Erm … uh … look! The Sweedish Bikini team!
“And why have a different syntax for the the volume name and then the rest of the filesystem?” asks Mark, avoiding my transparent attempt at changing the subject. “Do you allow slashes in the volume name?”
“Sure,” I said.
“And do you allow colons in filenames?”
“I'm sadistic enough of a programmer to say yes.”
“AAaaaaaaaaaaaaaaiiiiiiiieeeeeeeeeeeeeeeeeee,” he said. But point taken.
Mark, on the other hand, like the One Tree, Über Alles
approach to a file system. Other machines on the network would appear
/net. But that seems wrong to me. Each local machine
is the top of their respective trees when it seems like it should be the
other way around.
“But if I'm on a non-networked machine, just where should the root be? Should it be under /net/machinename?” Mark asked.
“No,” I repled. “It should have a volume name.”