* Re: [9fans] rewriting paths [was: mv vs cp] @ 2001-10-09 6:25 ` Fco.J.Ballesteros 2001-10-09 6:41 ` George Michaelson 2001-10-09 14:19 ` Richard 0 siblings, 2 replies; 17+ messages in thread From: Fco.J.Ballesteros @ 2001-10-09 6:25 UTC (permalink / raw) To: 9fans One thing I like in Plan 9 is that by keeping the fs alive, you can survive crashes on any other machine. The renamefs would make you more dependent on crashes not happening in the machine w/ renamefs before it moves everything around. The other question I have: is all this worth just to avoid mv doing a cp+rm? Beware that even if you could move, the worm would burn a copy unless you also modify it. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] rewriting paths [was: mv vs cp] 2001-10-09 6:25 ` [9fans] rewriting paths [was: mv vs cp] Fco.J.Ballesteros @ 2001-10-09 6:41 ` George Michaelson 2001-10-10 9:05 ` Douglas A. Gwyn 2001-10-09 14:19 ` Richard 1 sibling, 1 reply; 17+ messages in thread From: George Michaelson @ 2001-10-09 6:41 UTC (permalink / raw) To: 9fans Something maybe not covered so far is what mv etc do with sparce files, if memory serves me right some operations are 'safe' and some have a habit of filling the empty extent with data, having unforseen consequences for the real size of used disk. Of course, if 9 doesn't have them, it doesn't have the problem either. -George ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] rewriting paths [was: mv vs cp] 2001-10-09 6:41 ` George Michaelson @ 2001-10-10 9:05 ` Douglas A. Gwyn 0 siblings, 0 replies; 17+ messages in thread From: Douglas A. Gwyn @ 2001-10-10 9:05 UTC (permalink / raw) To: 9fans George Michaelson wrote: > Something maybe not covered so far is what mv etc do with sparce files, > if memory serves me right some operations are 'safe' and some have a habit > of filling the empty extent with data, having unforseen consequences for > the real size of used disk. > Of course, if 9 doesn't have them, it doesn't have the problem either. It wouldn't much matter, since it's just an optimization issue and could be "fixed". ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] rewriting paths [was: mv vs cp] 2001-10-09 6:25 ` [9fans] rewriting paths [was: mv vs cp] Fco.J.Ballesteros 2001-10-09 6:41 ` George Michaelson @ 2001-10-09 14:19 ` Richard 1 sibling, 0 replies; 17+ messages in thread From: Richard @ 2001-10-09 14:19 UTC (permalink / raw) To: 9fans Fco.J.Ballesteros writes: >One thing I like in Plan 9 is that by keeping the fs alive, >you can survive crashes on any other machine. The renamefs >would make you more dependent on crashes not happening >in the machine w/ renamefs before it moves everything around. I see your point. In renamefs's defense, I note that most users most of the time are working on their own stuff, not making any chanages to the parts of the network that everyone relies on. If the renamefs is running on your own terminal or cpued to some cpu server, and your working on your own stuff, a crash of the renamefs will not affect the other users. Ie, do not use renamefs when you are adminning the network. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] useful language extension, or no?
@ 2002-07-16 16:08 rob pike, esq.
2002-07-16 15:31 ` Sam
2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros
0 siblings, 2 replies; 17+ messages in thread
From: rob pike, esq. @ 2002-07-16 16:08 UTC (permalink / raw)
To: 9fans
> Suppose I'm not saying "why," but "why not." IMO it's cleaner and
> quite possibly more efficient (without getting into a usec argument,
> please). Do you disagree?
Yes. The benefit is minor, too small to justify changing the language.
You're trying to formalize an idiom; just using the idiom suits me fine.
The type inclusion feature, I think, did a lot more, since it trigged type
conversion and promotion: a much bigger deal.
-rob
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] useful language extension, or no? 2002-07-16 16:08 [9fans] useful language extension, or no? rob pike, esq. @ 2002-07-16 15:31 ` Sam 2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros 1 sibling, 0 replies; 17+ messages in thread From: Sam @ 2002-07-16 15:31 UTC (permalink / raw) To: 9fans Ok, I'll bite and play devil's advocate. What about the promotion of a structure from itself to one of its members in a function call simply because it makes locking a structure easier? Surely passing in a pointer to a function and having the in-func pointer completely different violates some standard of programming languages. Why was it worthwhile to change the language in this respect, for the idiom of "always having to make sure the lock is the first item in the structure for pointer coersion is a pain?" Sam On Tue, 16 Jul 2002, rob pike, esq. wrote: > > Suppose I'm not saying "why," but "why not." IMO it's cleaner and > > quite possibly more efficient (without getting into a usec argument, > > please). Do you disagree? > > Yes. The benefit is minor, too small to justify changing the language. > You're trying to formalize an idiom; just using the idiom suits me fine. > > The type inclusion feature, I think, did a lot more, since it trigged type > conversion and promotion: a much bigger deal. > > -rob > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [9fans] more extensions 2002-07-16 16:08 [9fans] useful language extension, or no? rob pike, esq. 2002-07-16 15:31 ` Sam @ 2002-07-16 17:24 ` FJ Ballesteros 2002-07-16 16:26 ` Sam ` (3 more replies) 1 sibling, 4 replies; 17+ messages in thread From: FJ Ballesteros @ 2002-07-16 17:24 UTC (permalink / raw) To: 9fans Including tuples (perhaps as an instance of nameless structs) would simplify many interfaces, right? that's one thing I learned using Limbo. The extension would probably be not too complex, also. I don't have time to implement this during this semester, but would be willing to do so in the future if people from the Labs agree. Is there agreement on this? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] more extensions 2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros @ 2002-07-16 16:26 ` Sam 2002-07-16 17:28 ` Howard Trickey ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Sam @ 2002-07-16 16:26 UTC (permalink / raw) To: 9fans My next thought, but I figured I'd used all my contribution credits today. Sam On Tue, 16 Jul 2002, FJ Ballesteros wrote: > > Including tuples (perhaps as an instance of nameless structs) would > simplify many interfaces, right? that's one thing I learned using > Limbo. > > The extension would probably be not too complex, also. > > I don't have time to implement this during this semester, but would > be willing to do so in the future if people from the Labs agree. > > Is there agreement on this? > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [9fans] more extensions 2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros 2002-07-16 16:26 ` Sam @ 2002-07-16 17:28 ` Howard Trickey 2002-07-16 17:09 ` [9fans] New language? Sam 2002-07-16 18:23 ` [9fans] more extensions Scott Schwartz 2002-07-17 8:58 ` Douglas A. Gwyn 3 siblings, 1 reply; 17+ messages in thread From: Howard Trickey @ 2002-07-16 17:28 UTC (permalink / raw) To: 9fans This is tempting. Tuples are one of my favorite things about Limbo. However, I'm biased, as I was the one that pushed for tuples in Limbo, I think. But adding them to C's already delicate grammar might be harder than it appears. And there comes a point where an extension changes the flavor of a language a little too much, and I think this one might be over that line. - Howard Trickey > Including tuples (perhaps as an instance of nameless structs) would > simplify many interfaces, right? that's one thing I learned using > Limbo. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [9fans] New language? 2002-07-16 17:28 ` Howard Trickey @ 2002-07-16 17:09 ` Sam 2002-07-17 5:45 ` GBA 0 siblings, 1 reply; 17+ messages in thread From: Sam @ 2002-07-16 17:09 UTC (permalink / raw) To: 9fans > be harder than it appears. And there comes a point > where an extension changes the flavor of a language > a little too much, and I think this one might be over > that line. Too true. What then, a new language based on C pulling the yummy stuff out of limbo? One that's not interpreted, without a garbage collector, and no atend >:), but that has tuples, array bounds checking, etc? At this point should we just considering loosening up Oberon a little and making a few additions? I'd be willing to help so long as we fix the BCPL inherited '&' precedence. Sam ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] New language? 2002-07-16 17:09 ` [9fans] New language? Sam @ 2002-07-17 5:45 ` GBA 2002-07-17 6:23 ` Lucio De Re 0 siblings, 1 reply; 17+ messages in thread From: GBA @ 2002-07-17 5:45 UTC (permalink / raw) To: 9fans Don't know much about Limbo, but have you seen this? http://www.digitalmars.com/d/index.html > Too true. What then, a new language based on C pulling the > yummy stuff out of limbo? One that's not interpreted, without > a garbage collector, and no atend >:), but that has tuples, array bounds > checking, etc? At this point should we just considering loosening up > Oberon a little and making a few additions? > > I'd be willing to help so long as we fix the BCPL inherited '&' > precedence. > > Sam > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] New language? 2002-07-17 5:45 ` GBA @ 2002-07-17 6:23 ` Lucio De Re 0 siblings, 0 replies; 17+ messages in thread From: Lucio De Re @ 2002-07-17 6:23 UTC (permalink / raw) To: 9fans On Tue, Jul 16, 2002 at 10:45:02PM -0700, GBA wrote: > > Don't know much about Limbo, but have you seen this? > > http://www.digitalmars.com/d/index.html > What, no tuples?! More seriously, I'm happy to work further on Alef, but I have long ago accepted Bell Labs' view that maintaing the libraries is a disaster. I see the "D" people mention "versioning". I'm insufficiently knowledgeable to decide whether that is something I would appreciate or despise. I know NetBSD is hooked on it (in the sense that meat hangs from hooks in refrigerators, sadly) because of their use of dynamic libraries. I guess that makes it a useful solution, if you can't get rid of the problem in the first place. ++L ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] more extensions 2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros 2002-07-16 16:26 ` Sam 2002-07-16 17:28 ` Howard Trickey @ 2002-07-16 18:23 ` Scott Schwartz 2002-07-16 18:47 ` Dan Cross 2002-07-17 8:58 ` Douglas A. Gwyn 3 siblings, 1 reply; 17+ messages in thread From: Scott Schwartz @ 2002-07-16 18:23 UTC (permalink / raw) To: 9fans | Including tuples (perhaps as an instance of nameless structs) would | simplify many interfaces, right? that's one thing I learned using | Limbo. Yeah, but limbo has bounds checked arrays, which are even more useful. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] more extensions 2002-07-16 18:23 ` [9fans] more extensions Scott Schwartz @ 2002-07-16 18:47 ` Dan Cross 2002-07-16 19:05 ` Jon Snader 0 siblings, 1 reply; 17+ messages in thread From: Dan Cross @ 2002-07-16 18:47 UTC (permalink / raw) To: 9fans > | Including tuples (perhaps as an instance of nameless structs) would > | simplify many interfaces, right? that's one thing I learned using > | Limbo. > > Yeah, but limbo has bounds checked arrays, which are even more useful. Has anyone ever wondered, ``why not just port limbo?'' Surely the runtime environment provided by Dis can be emulated using a library. Not in response to Scott's comment, but in general, I'm not a big fan of changing C; C is what C is. If you want something else, use something else, but don't try to morph C into another language. - Dan C. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] more extensions 2002-07-16 18:47 ` Dan Cross @ 2002-07-16 19:05 ` Jon Snader 0 siblings, 0 replies; 17+ messages in thread From: Jon Snader @ 2002-07-16 19:05 UTC (permalink / raw) To: 9fans On Tue, Jul 16, 2002 at 02:47:27PM -0400, Dan Cross wrote: > > Not in response to Scott's comment, but in general, I'm not a big fan > of changing C; C is what C is. If you want something else, use > something else, but don't try to morph C into another language. > As a wise man once said (sort of): ``If you want limbo, you know where to get it.'' ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] more extensions 2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros ` (2 preceding siblings ...) 2002-07-16 18:23 ` [9fans] more extensions Scott Schwartz @ 2002-07-17 8:58 ` Douglas A. Gwyn 3 siblings, 0 replies; 17+ messages in thread From: Douglas A. Gwyn @ 2002-07-17 8:58 UTC (permalink / raw) To: 9fans FJ Ballesteros wrote: > Including tuples ... Tuples are truly useful. There are some syntactic issues to solve when adding them to C, but assuming they're dealt with I would welcome this experiment. It would provide some leverage in arguing for standardization of the feature for C0x. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [9fans] mv vs cp @ 2001-10-07 16:23 jmk 2001-10-08 17:43 ` [9fans] rewriting paths [was: mv vs cp] Richard Uhtenwoldt 0 siblings, 1 reply; 17+ messages in thread From: jmk @ 2001-10-07 16:23 UTC (permalink / raw) To: 9fans As Dave points out, there are a lot of balls in the air during an atomic 'rename'. 4.2BSD introduced the 'rename' system call, and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify to how long it took to get it right and how much ugly code was involved. --jim ^ permalink raw reply [flat|nested] 17+ messages in thread
* [9fans] rewriting paths [was: mv vs cp] 2001-10-07 16:23 [9fans] mv vs cp jmk @ 2001-10-08 17:43 ` Richard Uhtenwoldt 0 siblings, 0 replies; 17+ messages in thread From: Richard Uhtenwoldt @ 2001-10-08 17:43 UTC (permalink / raw) To: 9fans I was thinking about this in the bathtub just now. One could interpose a filesystem between the user and kfs --or wherever one's files are really stored-- called renamefs, which rewrites paths before forwarding them to kfs. 9P requests do not really contain paths, but you get the idea: the new file server, renamefs, maintains a rewrite table containing the paths specified by past move commands (2 paths per move command to be precise). This state is used to rewrite certain 9P requests (eg, some walk requests) before relaying them to the server that really stores files. To increase the usefulness of renamefs, we allow it to store 2 types of records. Specifically, a record can take the form D<path> , which means that the string <path> "no longer lives here" (ie, renamefs will act as if <path> does not exist), or it can take the form A<path><path2> , which means that <path2> will get rewritten as <path> and does not carry the implication that <path> no longer lives here. (Yes, yes, I know: between <path> and <path2> you need some lexeme that does not occur in paths.) Then, Mv <path> <path2> can be implemented by adding two records, A<path><path2> and D<path>, and something resembling Unix's Ln -s <path> <path2> is implementable by adding one record, A<path><path2>, to the rewrite table inside renamefs. The main socioeconomic purpose of these features is to make Unix users feel more at home by providing means to move directories, means to do inter-directory moves and symlinks. Moreover, Del <path> which just adds D<path> to the rewrite table, is a delete that supports undelete (via removal of the D record). And resource forks can be implemented via ... --Just kidding. No need to modify 9P of course: just have renamefs listen on a specific file like /foo/rename where foo might be mnt (sorry for my unfamiliarity with Plan9 file naming conventions) and have mv write requests (candidates already in the form of strings for entry into the rewrite table) to /foo/rename (rather than having mv send rename or copy and delete requests like it does now). When everyone is sleeping, or when the user says so, renamefs can empty the rewrite table by actually copying and deleting files in the underlying filesystem. Call this operation "update". There are multiple ways I'm sure to create pathological situations with renamefs, and I do not know enough about Plan 9 to address them, except to point out that one way to recover from pathology --assuming the update operation has not run yet-- is simply to delete the rewrite table via, eg, echo clear >>/foo/rename or, if the namespace is so screwed up that that impossible, to reboot without mounting renamefs. Advantages of my design: Users who do not need the functionality do not pay any cost: the code for renamefs and it's clients (eg, the new mv command) lie dormant on the hard drive where they cannot cause problems. No modification of extant code is required. Makes Plan 9 look more like Unix for those who want want that sort of thing, and yes I hear loud and clear that many here do not. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2002-07-17 8:58 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <nemo@gsyc.escet.urjc.es> 2001-10-09 6:25 ` [9fans] rewriting paths [was: mv vs cp] Fco.J.Ballesteros 2001-10-09 6:41 ` George Michaelson 2001-10-10 9:05 ` Douglas A. Gwyn 2001-10-09 14:19 ` Richard 2002-07-16 16:08 [9fans] useful language extension, or no? rob pike, esq. 2002-07-16 15:31 ` Sam 2002-07-16 17:24 ` [9fans] more extensions FJ Ballesteros 2002-07-16 16:26 ` Sam 2002-07-16 17:28 ` Howard Trickey 2002-07-16 17:09 ` [9fans] New language? Sam 2002-07-17 5:45 ` GBA 2002-07-17 6:23 ` Lucio De Re 2002-07-16 18:23 ` [9fans] more extensions Scott Schwartz 2002-07-16 18:47 ` Dan Cross 2002-07-16 19:05 ` Jon Snader 2002-07-17 8:58 ` Douglas A. Gwyn -- strict thread matches above, loose matches on Subject: below -- 2001-10-07 16:23 [9fans] mv vs cp jmk 2001-10-08 17:43 ` [9fans] rewriting paths [was: mv vs cp] Richard Uhtenwoldt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).