Re: [9fans] Plan9 development
On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote: > > mash has a make builtin. very brief, as all the shell type stuff in mk > goes away.. > I seem to remember that the mash source was lost? ++L
Re: [9fans] Plan9 development
no. it was the last thing i wrote for the bidness unit. brucee On Fri, Nov 5, 2010 at 6:11 PM, Lucio De Re wrote: > On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote: >> >> mash has a make builtin. very brief, as all the shell type stuff in mk >> goes away.. >> > I seem to remember that the mash source was lost? > > ++L > >
[9fans] Passing a file descriptor between processes
One of the ugliest interface in Unix is passing a file descriptor between processes [1]. Does Plan9 provide any mechanism for it? [1] http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch17lev1sec4.html -- Kirill A. Shutemov
Re: [9fans] Passing a file descriptor between processes
On Fri Nov 5 06:32:55 EDT 2010, kir...@shutemov.name wrote: > One of the ugliest interface in Unix is passing a file descriptor between > processes [1]. Does Plan9 provide any mechanism for it? > > [1] > http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch17lev1sec4.html there is no mechanism similar to sending fds over a socket. the two ways of file descriptor sharing are via (a) rfork(2); and (b) srv(3) rfork (optionally) allows a process to share a file descriptor table with a child process. srv allows a process to post a file descriptor by a given name in /srv. the normal file operations apply on that file. in particular, it must be opened before use. - erik
Re: [9fans] Passing a file descriptor between processes
On Fri, Nov 05, 2010 at 12:29:46PM +0200, Kirill A. Shutemov wrote: > > One of the ugliest interface in Unix is passing a file descriptor between > processes [1]. Does Plan9 provide any mechanism for it? > You can pass fds in channels between threads, but for processes you should look at #s for guidance. ++L
Re: [9fans] Passing a file descriptor between processes
see srv(3) http://plan9.bell-labs.com/magic/man2html/3/srv On 5 November 2010 10:29, Kirill A. Shutemov wrote: > One of the ugliest interface in Unix is passing a file descriptor between > processes [1]. Does Plan9 provide any mechanism for it? > > [1] > http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch17lev1sec4.html > > -- > Kirill A. Shutemov > >
Re: [9fans] Passing a file descriptor between processes
On Fri Nov 5 07:36:42 EDT 2010, rogpe...@gmail.com wrote: > see srv(3) > http://plan9.bell-labs.com/magic/man2html/3/srv > > On 5 November 2010 10:29, Kirill A. Shutemov wrote: > > One of the ugliest interface in Unix is passing a file descriptor between > > processes [1]. Does Plan9 provide any mechanism for it? > > > > [1] > > http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch17lev1sec4.html the op may have seen this: http://lwn.net/Articles/411845/ —which i found hard to read because the author's changing definition of "unix". - erik
Re: [9fans] Passing a file descriptor between processes
On Fri, Nov 5, 2010 at 7:41 AM, erik quanstrom wrote: > On Fri Nov 5 07:36:42 EDT 2010, rogpe...@gmail.com wrote: > > see srv(3) > > http://plan9.bell-labs.com/magic/man2html/3/srv > > > > On 5 November 2010 10:29, Kirill A. Shutemov > wrote: > > > One of the ugliest interface in Unix is passing a file descriptor > between > > > processes [1]. Does Plan9 provide any mechanism for it? > > > > > > [1] > http://book.chinaunix.net/special/ebook/addisonWesley/APUE2/0201433079/ch17lev1sec4.html > > the op may have seen this: http://lwn.net/Articles/411845/ > —which i found hard to read because the author's changing > definition of "unix". > > - erik > > There was a discussion here a while ago about it too: search for 'sendfd on native Plan 9' from december 2008. Start here: http://9fans.net/archive/2008/12/515, follow till January 2009. Currently, if your processes have a common parent, you can use rfork; if not, you must resort to #s. '#s' is a pretty unfortunate interface, though... -- vs
Re: [9fans] Passing a file descriptor between processes
On Fri, Nov 05, 2010 at 08:16:30AM -0400, Venkatesh Srinivas wrote: > > '#s' is a pretty unfortunate interface, > though... > Maybe. But it is only a tool and as such it can be replaced or augmented. It's unlikely that Plan 9 will retain its integrity without #s, but that does not mean that an alternative can't be installed with similar, but more friendly semantics. Hm, let me try this: it means that an alternative can be installed, more suitable to a slightly different application. It does need to be a kernel device. ++L
Re: [9fans] Passing a file descriptor between processes
> Currently, if your processes have a common parent, you can use rfork; if > not, you must resort to #s. '#s' is a pretty unfortunate interface, > though... okay, practicially speaking, what's wrong with #s, and what do you propose? - erik
Re: [9fans] Plan9 development
Quite right: http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash Although, no doubt brucee has a new, improved version not fit for mere mortals to gaze upon. -eric On Fri, Nov 5, 2010 at 2:55 AM, Bruce Ellis wrote: > no. it was the last thing i wrote for the bidness unit. > > brucee > > On Fri, Nov 5, 2010 at 6:11 PM, Lucio De Re wrote: >> On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote: >>> >>> mash has a make builtin. very brief, as all the shell type stuff in mk >>> goes away.. >>> >> I seem to remember that the mash source was lost? >> >> ++L >> >> > >
Re: [9fans] Plan9 development
> http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash that one is indeed fairly old, much as we received it, except for changes to fit any changes in the environment, but http://www.vitanuova.com/inferno/man/1/mash.html and http://www.vitanuova.com/inferno/man/1/mash-make.html gives you some idea, especially the latter, in this context.--- Begin Message --- Quite right: http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash Although, no doubt brucee has a new, improved version not fit for mere mortals to gaze upon. -eric On Fri, Nov 5, 2010 at 2:55 AM, Bruce Ellis wrote: > no. it was the last thing i wrote for the bidness unit. > > brucee > > On Fri, Nov 5, 2010 at 6:11 PM, Lucio De Re wrote: >> On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote: >>> >>> mash has a make builtin. very brief, as all the shell type stuff in mk >>> goes away.. >>> >> I seem to remember that the mash source was lost? >> >> ++L >> >> > >--- End Message ---
[9fans] Plan 9 libc locks and semacquire?
Hi, In the paper 'Semaphores in Plan 9' by Sape and Russ Cox, there was this note: "The performance of the semaphore-based lock implementation is sometimes much better and never noticeably worse than the spin locks. We will replace the spin lock implementation in the Plan 9 distribution soon." As far as I can tell, this has not happened; is there any reason why? Are there any objections of the sem*-based locks? Thanks, -- vs
[9fans] anyone else having difficulty booting kw today?
I just did a pull and a recompile. The kernel boots to the point where it wants to get the root. I tell it the same root server I used before the rebuild, and the prompt comes back again asking for the root. Any thoughts on where I should look? usb/hub... root is from (tcp)[tcp]: 192.168.1.250 root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: Dave
Re: [9fans] anyone else having difficulty booting kw today?
OOPS dumb mistake on my part... I should have just pressed enter there. I really ought to script that. On Fri, Nov 5, 2010 at 9:41 AM, David Leimbach wrote: > I just did a pull and a recompile. > > The kernel boots to the point where it wants to get the root. I tell it > the same root server I used before the rebuild, and the prompt comes back > again asking for the root. > > Any thoughts on where I should look? > > usb/hub... root is from (tcp)[tcp]: 192.168.1.250 > root is from (tcp)[192.168.1.250]: > root is from (tcp)[192.168.1.250]: > root is from (tcp)[192.168.1.250]: > root is from (tcp)[192.168.1.250]: > root is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root > is from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is > from (tcp)[192.168.1.250]: root is from (tcp)[192.168.1.250]: root is from > (tcp)[192.168.1.250]: > > Dave >
Re: [9fans] Plan9 development
On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote: > Quite right: > http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash > > Although, no doubt brucee has a new, improved version not fit for mere > mortals to gaze upon. A honest question: what is the rationale for merging functionality of make and shell into one? Is mash meant to be default interactive shell? -- dexen
Re: [9fans] Plan9 development
> A honest question: what is the rationale for merging functionality of make and > shell into one? Use your imagination Nick
[9fans] Google code-in?
Google just announced a code-in. Is Plan9 participating? EBo --
Re: [9fans] Plan9 development
On Friday 05 of November 2010 18:18:44 Nick LaForge wrote: > > A honest question: what is the rationale for merging functionality of > > make and shell into one? > > Use your imagination Tried, failed. To me, make is a tool for generating an acyclic, directed graph of dependencies between build steps from some explicit and some wildcard rules -- and then traversing it in a sensible order. How's that for daily use shell? Perhaps something about `doing a reasonable action for every target file named on the command line'? -- dx
Re: [9fans] Plan9 development
> To me, make is a tool for generating an acyclic, directed graph of > dependencies between build steps from some explicit and some wildcard rules > -- and then traversing it in a sensible order. How's that for daily use shell? your focus is too narrowed on building. a sequence of commands piping output to each other is also a directed acyclic graph.
Re: [9fans] Plan9 development
On Fri, Nov 5, 2010 at 10:32 AM, dexen deVries wrote: > On Friday 05 of November 2010 18:18:44 Nick LaForge wrote: > > > A honest question: what is the rationale for merging functionality of > > > make and shell into one? > > > > Use your imagination > > Tried, failed. > To me, make is a tool for generating an acyclic, directed graph of > dependencies between build steps from some explicit and some wildcard > rules > -- and then traversing it in a sensible order. How's that for daily use > shell? > > Why is a shell that can generate acyclic digraphs of dependencies bad? Someone clearly found a use for it at some point or it wouldn't have been done. I guess one could try to use make as an init system for services in a configuration, but I don't see why not having those features in a shell is better than having those features in a shell. I do not currently use mash, however, I wonder if it's suitable for a startup mechanism for services just after booting a kernel, to get stuff started in the right order, without lavish attempts at building up those dependencies in a script that can't make acyclic digraphs of dependencies make sense natively. > > Perhaps something about `doing a reasonable action for every target file > named > on the command line'? > The possibilities are finite! > > -- > dx > >
Re: [9fans] Plan9 development
On Friday 05 of November 2010 18:39:14 andrey mirtchovski wrote: > > To me, make is a tool for generating an acyclic, directed graph of > > dependencies between build steps from some explicit and some wildcard > > rules -- and then traversing it in a sensible order. How's that for > > daily use shell? > > your focus is too narrowed on building. a sequence of commands piping > output to each other is also a directed acyclic graph. A bit in the style of plumber, one would have set of make-like rules defined in some $home/lib/mash, and mash would automagically apply them when target(s) match? Currently shell use consists of indicating data source and actions to be taken. With mash it would be more about indicating desired targets in the current context, to be created with mash rules in currenct context, right? On Friday 05 of November 2010 18:45:17 David Leimbach wrote: > The possibilities are finite! and so is the memory in a Turing machine... *mumbles something about turing tar-pit*
Re: [9fans] Plan9 development
> > -- and then traversing it in a sensible order. How's that for daily use
> > shell?
> >
> >
> Why is a shell that can generate acyclic digraphs of dependencies bad?
> Someone clearly found a use for it at some point or it wouldn't have been
> done.
it is silly bloat if it's not an essential part of the shell.
but (as andrey has noted) if you were to replace the
machinery behind these normal shell dag builders
('&', '&&', '||', if, '|', 'and '`{}') with something general
enough to replace mk, you'd be on to something.
personally, i think getting the syntax right would be
the hard part.
> I guess one could try to use make as an init system for services in a
> configuration, but I don't see why not having those features in a shell is
> better than having those features in a shell.
that's been done with mk for linux by a rose hullman
student. it was faster than some of the fancy purpose-
built tools due to better parallism. see the list archives.
- erik
Re: [9fans] Plan9 development
On 5 November 2010 18:14, erik quanstrom wrote:
>> > -- and then traversing it in a sensible order. How's that for daily use
>> > shell?
>> >
>> >
>> Why is a shell that can generate acyclic digraphs of dependencies bad?
>> Someone clearly found a use for it at some point or it wouldn't have been
>> done.
>
> it is silly bloat if it's not an essential part of the shell.
> but (as andrey has noted) if you were to replace the
> machinery behind these normal shell dag builders
> ('&', '&&', '||', if, '|', 'and '`{}') with something general
> enough to replace mk, you'd be on to something.
i did a mash-inspired version of mk as an inferno shell module once.
it required no new syntax (although it could be confused by
files named ":"...)
part of the problem was that it's not that useful to have
a "mkfile"-like syntax that's only understood on one system.
we ended up porting mk.
Re: [9fans] Plan9 development
On Thu, 04 Nov 2010 22:20:04 - Charles Forsyth wrote: > >But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfil > e and acid) > >at least as long as all that Java in the ant distribution (213151 lines)? > >That's a lot of catching up to do. > >The market has clearly spoken, and it appears that more lines dominates the > soup. > > one interesting thing about that example is that if it were done again > for the Plan 9 environment, mk might well be even smaller, since > some of the existing functionality isn't really used, > or might be achieved by simpler mechanisms, or with functionality > added instead by further composition with other programs; > alternatively, it might be redone in a radically different way. > > either way you probably wouldn't get an entire O'Reilly book out of it though. Some random thoughts triggered by Charles'es message: 1. The idea is to map mk to a special filesystem -- "mkfs" takes on a whole new meaning! One would overlay mkfs on a source tree. We are going to build foo mkdir foo foo/src cd foo Specify a build rule for command foo: echo 8c src/*.c -o .build > .rule Specify dependencies a b & c of foo: ln -s ../^(a b c) .dep/ Build foo: ls .build This checks dependencies a b c (if they are directories, checks a/.build etc) and builds them. This will need to be fleshed out the most... Default rules can be added with something like plumb Install foo: cp .build /bin/foo Remove temporary files rm .obj/* .build I used symlinks to point to dependencies but may be there is a smarter way. A default .rule can be derived depending on what is in src/ Initial .dep/ may be derived by mkfs running a dependency deriving program. Objects in .obj/ may be similarly derived. The utility if any is that a small set of mechanisms is used, coupled with a simple convention. This was fun little exercise (spent more time on writing this email) so I am sure there are lots of holes. Probably not worth building. It'd be too slow. 2. Factor out a way to track changes in any fs and trigger commands. This would probably obviate the need to build a number of special purpose file systems.
Re: [9fans] Plan9 development
> > ('&', '&&', '||', if, '|', 'and '`{}') with something general
> > enough to replace mk, you'd be on to something.
>
> i did a mash-inspired version of mk as an inferno shell module once.
> it required no new syntax (although it could be confused by
> files named ":"...)
what you did was very cool, but iirc this was in addition
to, not replacing the standard && || ... bits. one
could build pipelines and specify command order in one
unified way, no?
- erik
Re: [9fans] Google code-in?
Code-in? Could you elaborate? On Nov 5, 2010 1:22 PM, "EBo" wrote: > Google just announced a code-in. Is Plan9 participating? > > EBo -- > >
Re: [9fans] Google code-in?
'Summer of code' for high school students? Frankly, looking at its phrasing, it just looks like open-outsourcing on a whole new level. Nick On 11/5/10, Jacob Todd wrote: > Code-in? Could you elaborate? > On Nov 5, 2010 1:22 PM, "EBo" wrote: >> Google just announced a code-in. Is Plan9 participating? >> >> EBo -- >> >> >
Re: [9fans] Plan9 development
On Fri, Nov 5, 2010 at 12:07 PM, dexen deVries wrote: > On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote: >> Quite right: >> http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash >> >> Although, no doubt brucee has a new, improved version not fit for mere >> mortals to gaze upon. > > > A honest question: what is the rationale for merging functionality of make and > shell into one? Is mash meant to be default interactive shell? > Perhaps Brzr could post the paper -- perhaps that what was lost -eric
Re: [9fans] Google code-in?
On Fri Nov 5 16:06:59 EDT 2010, nicklafo...@gmail.com wrote: > 'Summer of code' for high school students? > > Frankly, looking at its phrasing, it just looks like open-outsourcing > on a whole new level. i don't think that's accurate. the tasks need to be small enough and easy enough for a 12-17 year old student to resonably get one done in a week. it would be much easier to just do these tasks oneself than to even write up the task, let alone walk a student through the problem-solving process. so i see this as even more magnanimous than gsoc. google is essentially putting money directly into education. we're not participating this year for lack of time. but if there are any students who would like to participate, please contact me off list. - erik
Re: [9fans] Google code-in?
> i don't think that's accurate. the tasks need to > be small enough and easy enough for a 12-17 year old > student to resonably get one done in a week. it would be > much easier to just do these tasks oneself than to even > write up the task, let alone walk a student through the > problem-solving process. Thanks for setting me straight. Nick
Re: [9fans] Passing a file descriptor between processes
i wish #s had a directory structure and enforced group permissions. On Fri, Nov 5, 2010 at 5:21 AM, erik quanstrom wrote: >> Currently, if your processes have a common parent, you can use rfork; if >> not, you must resort to #s. '#s' is a pretty unfortunate interface, >> though... > > okay, practicially speaking, what's wrong with #s, and what do you propose? > > - erik > >
Re: [9fans] Google code-in?
Code-in? Could you elaborate? http://code.google.com/gci EBo --
Re: [9fans] Google code-in?
i don't think that's accurate. the tasks need to be small enough and easy enough for a 12-17 year old student to resonably get one done in a week. it would be much easier to just do these tasks oneself than to even write up the task, let alone walk a student through the problem-solving process. so i see this as even more magnanimous than gsoc. google is essentially putting money directly into education. we're not participating this year for lack of time. but if there are any students who would like to participate, please contact me off list. The only students I know of at the moment who have the skills are interested in robotics and code in C, but I have not been in contact with them for a year or two. I'll talk to their parents about next year. EBo --
Re: [9fans] Plan9 development
> A honest question: what is the rationale for merging functionality of make and > shell into one? at the time, people were pushing more and more scripting or programming language functionality into accretions of the original make, and someone observed that it might be better instead to put a small amount of support for dependencies into a proper scripting language.
Re: [9fans] Plan9 development
i can answer that one easily. that's why it's called mash rather than "random marketting name". the intention was to replace plan9 rc with a shell that was maintainable and had loadable modules. i wrote it in limbo to show it works, damned well. the first requirement was a make loadable. it's not built into mash, it's loadable. a few pages of code that uses the shell rather than mk's builtin shell like stuff. brucee On Sat, Nov 6, 2010 at 4:07 AM, dexen deVries wrote: > On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote: >> Quite right: >> http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash >> >> Although, no doubt brucee has a new, improved version not fit for mere >> mortals to gaze upon. > > > A honest question: what is the rationale for merging functionality of make and > shell into one? Is mash meant to be default interactive shell? > > -- > dexen > >
