943. Chris_Wass (207.227.21.162) –
04 Nov 2003 10:30:07
[ WRIMO BEGIN! ]
Taboos be damned! We're talking word count here, baby! |
| |
942. Tom 7 (h-66-167-161-29.phlapafg.dynamic.covad.net) –
03 Nov 2003 22:05:42
[ WRIMO BEGIN! ]
Writing about writing is the one taboo to avoid! But I like the idea of tattoos on asses. |
| |
941. Chris_Wass (207.227.21.162) –
03 Nov 2003 18:15:00
[ WRIMO BEGIN! ]
Writing about Writing, aka, A Tattoo On My Ass of An Ass |
| |
940. David C. Daniel (64-40-57-131.nocharge.com) –
03 Nov 2003 06:26:55
[ WRIMO BEGIN! ]
Oh, almost forgot my phrase donation for your project: nation building |
| |
939. David C. Daniel (64-40-57-131.nocharge.com) –
03 Nov 2003 06:25:41
[ WRIMO BEGIN! ]
Well, if the two orphans together aren't longer than one book you can count them both as one. Another option is to physically combine the two MSs. Viola! one orphaned book.
I have only one orphaned novel. I briefly considered turning it into a screenplay. I decided it should be a novel first. |
| |
938. Tom 7 (h-66-167-161-29.phlapafg.dynamic.covad.net) –
02 Nov 2003 21:27:28
[ WRIMO BEGIN! ]
But I already have an orphaned book laying around. It's bad to have two! |
| |
What about <i>Where in the World is Carmen Sandioago?</i>? That shit on for far too long. |
| |
936. David C. Daniel [http://keylight.blog... (66-109-197-177.nocharge.com) –
02 Nov 2003 19:43:24
[ WRIMO BEGIN! ]
I'm glad to see you're still still around! I'm a big fan of your fonts. I'm also a writer (for the screen), and a blogger, as it were. I've been on a bit of a break too: I have pages submitted to an L.A. management company and it's as good an excuse as any to stop writing for a bit.
I've been playing with CSS (my ranking is novice) on my new home page:
http://dcdaniel.greatnow.com/
I have some freeware fonts there and a link to your site too.
Good luck with the novel. Don't feel bad if you don't finish it--every writer has at least one orphaned book laying around.
|
| |
935. Anonymous (205.136.84.146) –
02 Nov 2003 19:22:50
[ FLAMING TEXT ]
in |
| |
934. Anonymous (205.136.84.146) –
02 Nov 2003 19:16:56
[ FLAMING TEXT ]
chantel farrington
|
| |
933. Clyde, friend of Stulove (dyn116.usa.utulsa.edu) –
02 Nov 2003 12:01:53
[ WRIMO BEGIN! ]
Obviously, "Lemmata of Love". |
| |
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. |
| |
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. |
| |