932. Marc (h00102b024a85.ne.client2.attbi.com) – 02 Nov 2003 09:41:29 [ WRIMO BEGIN! ]

"Make An Online Friend! Incidentally excellent fun is poked at Euripides and his dramatic methods,"

931. KGB (h57n2fls35o828.telia.com) – 02 Nov 2003 07:22:12 [ Axe Throw ]

What a trow!!! Man...you people like to live dangeriously

930. mike (h-66-167-161-29.phlapafg.dynamic.covad.net) – 02 Nov 2003 02:14:00 [ WRIMO BEGIN! ]

"freedom lives. now hiring"

929. Tom 7 (h-66-167-161-29.phlapafg.dynamic.covad.net) – 02 Nov 2003 00:02:28 [ WRIMO BEGIN! ]

All you have to do is do it!

928. Tuuur (supercow.kabel.utwente.nl) – 01 Nov 2003 17:30:03 [ WRIMO BEGIN! ]

*suffering accute writer's block*

927. nothings (adsl-63-203-74-132.dsl.snfc21.pacbell.net) – 01 Nov 2003 17:10:50 [ WRIMO BEGIN! ]

Ok, I changed my mind and am going to try it again this year, but I'll probably allow myself to get distracted with AADs instead.

http://www.livejournal.com/~nothings_nnwm

926. Tom 7 (h-66-167-161-29.phlapafg.dynamic.covad.net) – 01 Nov 2003 15:56:16 [ WRIMO BEGIN! ]

Ha, I actually for a moment this morning considered calling the novel "Excluded Middle."

925. Kaustuv (pool-151-201-11-162.pitt.east.verizon.net) – 01 Nov 2003 15:09:11 [ WRIMO BEGIN! ]

Chapter titles -- "It's Either True Or Not, Okay?", "A Judgemental Reconstruction Of Eighteenth Century Furniture" (alternately, "A Proof Theory Of Human Relationships"), "Abstract, Introduction, Three Sections, And Conclusion".

924. Tom 7 (h-66-167-161-29.phlapafg.dynamic.covad.net) – 31 Oct 2003 08:49:18 [ Why ''..'' dirent? ]

I think they are special case, actually, in almost any application. For instance:

mkdir /a
mkdir /a/b
mkdir /a/c
cd /a
mv b c (works normally)
mv .. c (doesn't work)
mv . .. (doesn't work)

In this sense "." and ".." *don't* act like normal directory entries.

Otherwise, yeah, that is what I am suggesting. Give the process a way to know its path, and then it (or libc) knows how to go 'up' when a filename specifies 'up'. I don't care how it's spelled, only that the underlying filesystem has consistent semantics.

Yes, in my example earlier it goes to /x under standard unix semantics. That's a little strange because we arrived at that directory by cd b ; cd c. What I was saying was that ".." doesn't correspond to "up" if you try to make DAGs in unix, ie, "cd dir" and "cd .." are not inverses.

923. nothings (adsl-63-203-74-132.dsl.snfc21.pacbell.net) – 30 Oct 2003 23:20:56 [ Why ''..'' dirent? ]

Ok, I guess it's fair to suggest that '.' and '..' shouldn't appear as enumerated files when you query for a list of files in a directory. But right now things like 'mv' and any other application does NOT have special handling for '.' and '..'; that stuff is either handled by the runtime library (e.g. 'fopen'), or, more likely, by the underlying OS, so it's confusing when you say they're already special cased.

On the other hand, if you were to try to manually expand "*/*/*", you DO have to special case '.' and '..' so you don't use them, since "*/*/*/" is definitely not supposed to refer to "../../..". In unix you don't worry about this since the shell does it, but I do have to write code for this in programs when I'm recursively traversing directories. So not enumerating would be nice, yes. But I need some kind of OS interface that can say something like "../../foo", regardless of how this functionality is implemented under the hood. Maybe you'd be happier with "^^foo" or something like that which didn't look like a normal filename.

Doesn't your example with the soft link work perfectly fine under unix, except that the mv goes to /x ? This is why I was confused what you meant about DAGs, since "proper" DAGs don't have parent pointers at all, since they're *acyclic*, hence Unix can do them fine. But yes, in the sense of being able to backwards-traverse the DAG, you're stuck with unix.

922. Tom 7 (gs82.sp.cs.cmu.edu) – 30 Oct 2003 15:07:17 [ Why ''..'' dirent? ]

I'm not asking to get rid of ".." entirely. There should definitely be a way to open files "from the parent directory", etc. It's just weird that ".." is an *actual* directory entry in each dir, that links up to its parent.

Each process currently stores its cwd ("current working directory"). My alternate suggestion is to store the cwp ("current working path"), which would be a sequence of directories that the process took to get to wherever it is. The filesystem calls like open can take this into account, and there can be a way of writing "parent directory" (we can even write that ".." to be compatible with existing notation) in the specification of a file so that you can still do all the things you can do today. It's just that instead of following the ".." links in each directory, it would instead use the process's cwp.

.. is already a special case in all sorts of applications. For instance, suppose I do this:

cd /
mkdir a
mkdir a/b
cd /
cd a
cd b
cd ..
cd b
cd ..
cd b
cd ..
pwd

I get:

/a

NOT:

/a/b/../b/../b/../

even though that's logically what I did: When I say cd to a relative path, it means, go into that directory. However, the shell understands that when I "cd ..", that shouldn't be in my working directory (even though /a/b/../b/../b/../ = /a in the above example), it means instead, "go up." If it's special case, and needs to be treated specially in all sorts of applications, why not fully admit that it's a special case and then not make it look like a real directory entry in each dir?

921. Marc (h00102b024a85.ne.client2.attbi.com) – 30 Oct 2003 09:45:42 [ Why ''..'' dirent? ]

Shells aren't the only place where you use .. though. They are useful for specifying relative paths in other environments, too. For example, I use .. sometimes for specifying the paths of files in a development project so that I can move the entire project dir (or more importantly, other people can check it out from cvs to anywhere on their system) and things will still work. Along the same lines, sometimes it's useful to use .. in #includes in source files. I'm not saying that there might not be a better solution for this, too, but I'm just saying that it's not just the shell environment that you have to think about.

920. Tom 7 (h-66-167-161-29.phlapafg.dynamic.covad.net) – 30 Oct 2003 09:12:16 [ Why ''..'' dirent? ]

I'm not suggesting that the pervasive environment not support any notion of "parent directory". Er, I am suggesting that the idea of ".." be handled by storing a *path* from the root as the process' cwd, rather than just the working directory. mv and other programs that manipulate files would need to understand that, but they already make special cases for "." and ".." anyway, so, no big deal.

In this system, you can combine your two examples with sensible (to me) results:

cd /
mkdir a
mkdir b
cd b
ln (-s) /a c
cd c
touch x
mv x ..

x is in /b/x, not /x.

Unix hard links don't support DAGs. Soft links don't, either, because the parent pointers (..) have to be unique.

919. nothings (adsl-63-203-74-132.dsl.snfc21.pacbell.net) – 30 Oct 2003 04:40:13 [ Why ''..'' dirent? ]

You'd give up the ability to do things like:

"mv foo .."
"cd somesymboliclink ; cd .."

You can do the first by cd'ing up first, or by using absolute paths, but that's the whole point of "..", to allow you to make filename references--not just 'cd' references--that go in any direction without having to go up. If you have ten files you want to move up a directory, it's a lot easier to say "mv a b c d e f g h i j .." then to say "cd ..;mv mydirectory/a mydirectory/b mydirectory/c mydirectory/d mydirectory/e mydirectory/f mydirectory/g mydirectory/h mydirectory/i mydirectory/j ."

Hierarchies are easier to understand and remember than DAGs; objects have a single clearly defined "location".

Alt: why would you need to take *out* .. entirely to do what you want? (Do unix hard links not allow true dags? Heck, don't soft links allow dags?) It seems like all you need is a shell "cdup" to get everything you want, and taking .. out is unnecessary.

NB: I haven't used unix in 10 years, but I still use ".." in commands all the times in dos boxes in windows.

918. Anonymous (199.235.112.238) – 29 Oct 2003 10:05:11 [ FLAMING TEXT ]

stupid bum

917. Tom 7 (gs82.sp.cs.cmu.edu) – 28 Oct 2003 13:20:28 [ Nanowrimo ]

Yeah!!

916. Tuuur (supercow.kabel.utwente.nl) – 28 Oct 2003 13:17:25 [ Nanowrimo ]

I did it, I am in as well!

915. Tom 7 (gs82.sp.cs.cmu.edu) – 28 Oct 2003 12:10:56 [ Nanowrimo ]

Yeah!! Novel party!

914. Heather (cobamide.bio.pitt.edu) – 28 Oct 2003 11:47:37 [ Nanowrimo ]

I am in...

913. Tom 7 (gs82.sp.cs.cmu.edu) – 27 Oct 2003 13:05:47 [ Nanowrimo ]

Plus, if you're not eating, what else to do with the extra free time?

912. chris_wass (207.227.21.162) – 27 Oct 2003 12:43:15 [ Nanowrimo ]

Well, I've decided to sign up. I've decided to use it as a brain dump. I want to extract out as much as I can about what I think about during the day and see what else comes out with it. I expect it to be completely incoherent. And that's ok. I just want it to be about the writing.

My friend Rich (www.sadsalvation.com) is going to do it too. He was thinking of fasting for Ramadan this year, though he's not muslim, but doesn't want to do both "projects" at once. I think that he should. I think that his reasons for exploring each of these endurance-demanding processes are connected.

911. Tom 7 (h-66-167-47-66.phlapafg.dynamic.covad.net) – 27 Oct 2003 10:50:23 [ Nanowrimo ]

Sure, man, what's wrong with Dutch?

910. Tom 7 (h-66-167-47-66.phlapafg.dynamic.covad.net) – 27 Oct 2003 09:53:26 [ Escape Alpha ]

Tadbot, yes, #6 is not implemented yet. Unless the map is *really* big, that is indeed a bug (the algorithms are designed to run pretty quickly), and in fact, I have a "XXX once this didn't terminate for me" for randtype 3. I recommend only using types 0 and 1.

909. Tuuur (gw-kamst.gw.utwente.nl) – 27 Oct 2003 04:11:52 [ Nanowrimo ]

Hmmm... maybe I WILL try... but in dutch, as my writing in english is not that good.
Which is fine with the organization. They only count the words, not paying attention to the contents that much.

908. Tadbot (pcp03750699pcs.walngs01.pa.comcast.net) – 26 Oct 2003 23:06:39 [ Escape Alpha ]

Huzzah, I finally beat those 3 remaining levels.
I also noticed a couple buggish things while starting to level-edit:

I changed the size to larger than the screen, and when I tried to randomize the map with randomize mode 3, it seemed to freeze. Maybe this randomizing method just takes longer depending on the size of the map, and I was impatient.

Also, randomize mode 6 gives me a "randtype not implemented" error, but maybe that's because you just haven't implemented that yet.