Re: [9fans] rc's shortcomings (new subject line)
On Tuesday 28 of August 2012 16:34:10 erik quanstrom wrote: > my knee-jerk reaction to my own question is that making it easier > and more natural to parallelize dataflow. a pipeline is just a really > low-level way to talk about it. the standard > grep x *.[ch] > forces all the *.[ch] to be generated before 1 instance of grep runs on > whatever *.[ch] evaluates to be. > > but it would be okay for almost every use of this if *.[ch] were generated > in parallel with any number of grep's being run. (in Linux terms, sorry!) you can get close with find|xargs -- it runs the command for every -L lines of input. AFAIK xargs does not parallelize the execution itself. find -name '*.[ch]' | xargs -L 8 grep REGEX -- dexen deVries [[[↓][→]]] I'm sorry that this was such a long letter, but I didn't have time to write you a short one. -- Blaise Pascal
Re: [9fans] rc's shortcomings (new subject line)
On Wednesday 29 of August 2012 09:06:35 arisawa wrote:
> Hello,
>
> On 2012/08/29, at 4:34, dexen deVries wrote:
> > now i see i can do:
> >
> > x=1 y=2 z=3
> >
> > ...and only `z' retains its new value in the external scope, while `x' and
> > `y' are limited in scope.
>
> No.
>
> ar% a=1 b=2 c=3; echo $a $b $c
> 1 2 3
> ar% a=() b=() c=()
> ar% a=1 b=2 {c=3}; echo $a $b $c
> 3
> ar%
indeed, thanks.
--
dexen deVries
[[[↓][→]]]
I'm sorry that this was such a long letter, but I didn't have time to write
you a short one. -- Blaise Pascal
Re: [9fans] rc's shortcomings (new subject line)
On Wed, Aug 29, 2012 at 2:04 AM, erik quanstrom wrote: >> > the haahr/rakitzis es' if makes more sense, even if it's wierder.) >> >> Agreed; es would be an interesting starting point for a new shell. > > es is great input. there are really cool ideas there, but it does > seem like a lesson learned to me, rather than a starting point. Starting point conceptually, if not in implementation. >> I think in order to really answer that question, one would have to >> step back for a moment and really think about what one wants out of a >> shell. There seems to be a natural conflict a programming language >> and a command interpreter (e.g., the 'if' vs. 'if not' thing). On >> which side does one err? > > since the raison d'être of a shell is to be a command interpter, i'd > go with that. Fair enough, but that will color the flavor of the shell when used as a programming language. Then again, Inferno's shell was able to successfully navigate both in a comfortable manner by using clever facilities available in that environment (module loading and the like). It's not clear how well that works in an environment like Unix, let alone Plan 9. >> I tend to agree. As a command interpreter, rc is more or less fine as >> is. I'd really only feel motivated to change whatever people felt >> were common nits, and there are fairly few of those. > > there are nits of omission, and those can be fixable. ($x(n-m) was added) Right. >> > perhaps (let's hope) someone else has better ideas. >> >> Well, something off the top of my head: Unix pipelines are sort of >> like chains of coroutines. And they work great for defining linear >> combinations of filters. But something that may be interesting would >> be the ability to allow the stream of computations to branch; instead >> of pipelines being just a list, make them a tree, or even some kind of >> dag (if one allows for the possibility of recombining streams). That >> would be kind of an interesting thing to play with in a shell >> language; I don't know how practically useful it would be, though. > > rc already has non-linear pipelines. but they're not very convienient. And somewhat limited. There's no real concept of 'fanout' of output, for instance (though that's a fairly trivial command, so probably doesn't count), or multiplexing input from various sources that would be needed to implement something like a shell-level data flow network. Muxing input from multiple sources is hard when the data isn't somehow self-delimited. For specific applications this is solvable by the various pieces of the computation just agreeing on how to represent data and having a program that takes that into account do the muxing, but for a general mechanism it's much more difficult, and the whole self-delimiting thing breaks the Unix 'data as text' abstraction by imposing a more rigid structure. There may be other ways to achieve the same thing; I remember that the boundaries of individual writes used to be preserved on read, but I think that behavior changed somewhere along the way; maybe with the move away from streams? Or perhaps I'm misremembering? I do remember that it led to all sorts of hilarious arguments about what the behavior of things like, 'write(fd, "", 0)' should induce in the reading side of things, but this was a long time ago. Anyway, maybe something along the lines of, 'read a message of length <=SOME_MAX_SIZE from a file descriptor; the message boundaries are determined by the sending end and preserved by read/write' could be leveraged here without too much disruption to the current model. > i think part of the problem is answering the question, what problem > would we like to solve. because "a better shell" just isn't well-defined > enough. Agreed. > my knee-jerk reaction to my own question is that making it easier > and more natural to parallelize dataflow. a pipeline is just a really > low-level way to talk about it. the standard > grep x *.[ch] > forces all the *.[ch] to be generated before 1 instance of grep runs on > whatever *.[ch] evaluates to be. > > but it would be okay for almost every use of this if *.[ch] were generated > in parallel with any number of grep's being run. > > i suppose i'm stepping close to sawzall now. Actually, I think you're stepping closer to the reducers stuff Rich Hickey has done recently in Clojure, though there's admittedly a lot of overlap with the sawzall way of looking at things. - Dan C.
Re: [9fans] SOEKRIS
THX After porting it to Inferno, ethervt1605m.c works as expected on net5501 Nevertheless, I have doubts that DP83816AVNG of net4501 is properly supported by Plan 9 driver; modern 9load crashes (MAP VA PA issue) at early stage whilst ported ether83815.c with Soekris support doesn't show better result. I'll try again later on if time available [...]. Any hint, feedbak net4501 + ether83815 + recent 9load & kernel are most welcome. +F On Friday, August 24, 2012 8:24:17 PM UTC+5:30, David du Colombier wrote: > > Does anybody know what is drivers status regarding latest n/w > > > chipsets on Soekris boards? > > > > > > Is VT6105M for the NET5501 now fully supported? > > > > I have a Soekris net5501 with eight VT6105M interfaces > > and it works fine. > > > > > I am asking this because I have a bunch of them (recent boxes) but > > > could not initialize n/w properly under Inferno Native. > > > > I haven't tried Inferno, but they are properly supported on Plan 9. > > > > > So my question is this: if any is relevant, which /ether.c > > > has to be ported to Inferno in order to make it happen again? > > > > /sys/src/9/pc/ethervt6105m.c > > > > -- > > David du Colombier
Re: [9fans] rc vs sh
On 08/28/2012 03:22 PM, dexen deVries wrote: On Tuesday 28 of August 2012 10:57:06 Rudolf Sykora wrote: Hello, I am just curious... Here http://9fans.net/archive/2007/11/120 Russ Cox writes he uses bash as his default shell. Does anybody know the reason? Is this for practicality within the linux environment? Or has he found rc too limiting? FWIW, i'm using bash as the interactive shell too, in `konsole' terminal emulator, because of bash' interactive line edition and command history. 9term doesn't fit me. I added command line editing and history to ash under minix a decade ago, it worked like a charm; the same ash is known as dash in Debian world, but did not bother to submit a patch. Whereas, the bash man-page itself explains a lot: BUGS It's too big and too slow. There are some subtle differences between bash and traditional versions of sh, mostly because of the POSIX specification. Aliases are confusing in some uses. Shell built-in commands and functions are not stoppable/restartable. Compound commands and command sequences of the form `a ; b ; c' are not handled gracefully when process suspension is attempted. When a process is stopped, the shell immediately executes the next command in the sequence. It suffices to place the sequence of commands between parentheses to force it into a sub-shell, which may be stopped as a unit. Array variables may not (yet) be exported. There may be only one active co-process at a time. GNU Bash-4.2 2010 December 28 BASH(1) all scripting -- both standalone and in mkfiles -- goes in rc, thou. It's strange that though ArchLinux uses bash as a system shell :P -- Balwinder S "bdheeman" Dheeman (http://werc.homelinux.net/contact/)
Re: [9fans] finally success with pentium d dualcore D945PLrn board
> would need to reboot it to get mp table dump or the > effective pci interrupt routing. :-( well, if you get a chance. that would be great. - erik
Re: [9fans] rc's shortcomings (new subject line)
> > rc already has non-linear pipelines. but they're not very convienient. > > And somewhat limited. There's no real concept of 'fanout' of output, > for instance (though that's a fairly trivial command, so probably > doesn't count), or multiplexing input from various sources that would > be needed to implement something like a shell-level data flow network. > > Muxing input from multiple sources is hard when the data isn't somehow > self-delimited. >[...] > There may be other ways to achieve the same thing; I remember that the > boundaries of individual writes used to be preserved on read, but I > think that behavior changed somewhere along the way; maybe with the > move away from streams? Or perhaps I'm misremembering? pipes still preserve write boundaries, as does il. (even the 0-byte write) but tcp of course by definition does not. but either way, the protocol would need to be self-framed to be transported on tcp. and even then, there are protocols that are essentially serial, like tls. > > i suppose i'm stepping close to sawzall now. > > Actually, I think you're stepping closer to the reducers stuff Rich > Hickey has done recently in Clojure, though there's admittedly a lot > of overlap with the sawzall way of looking at things. my knowledge of both is weak. :-) - erik
Re: [9fans] rc's shortcomings (new subject line)
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.78.5331 Paul Haeberli, ConMan: A Visual Programming Language for Interactive Graphics (1988) I supervised a student who did an implementation for a Blit-like environment on the Sun3 as a project; unfortunately I didn't keep a copy. I remember there were several things left to work out based on the paper. (The Blit-like environment replaced megabytes of Sunview, in case you were wondering, and enabled some serious fun. Sunview enabled some serious head-banging.)
Re: [9fans] rc vs sh
Changing my default shell from bash to rc caused even terminal windows (let alone 9term ones) to appear almost instantly on Ubuntu (9term windows appear instantly on the click). We slowly standardise on slow standards, with degradation everywhere.
Re: [9fans] rc vs sh
For compatibility I use ash in xterm and rc in 9term ;)
Re: [9fans] rc vs sh
I have an rc script, allowing u ./configure, u make, u man, ... % cat bin/u #!/bin/rc SHELL=/bin/sh path=(/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/bin/X11 /usr/games) MANPAGER=/bin/cat exec $* On 29 August 2012 16:22, hiro <23h...@gmail.com> wrote: > For compatibility I use ash in xterm and rc in 9term ;) > >
Re: [9fans] dns poisoning
you are right!
baddelegation() is checking for that, but it was not effective because it
bailed out before even entering that for loop because of:
if(t == nil)
t = lookupinfo("dom");
if(t == nil)
return 0; <- delegation loop will not be checked :(
the following patch makes it work:
dblookup.c:799,806 - /sys/src/cmd/ndb/dblookup.c:799,804
if(t == nil)
t = lookupinfo("dom");
- if(t == nil)
- return 0;
for(; rp; rp = rp->next){
if(rp->type != Tns)
dblookup.c:816,821 - /sys/src/cmd/ndb/dblookup.c:814,822
return 1;
}
+ if(t == nil)
+ continue;
+
/* see if delegating to us what we don't own */
for(nt = t; nt != nil; nt = nt->entry)
if(rp->host && cistrcmp(rp->host->name, nt->val) == 0)
--
cinap
Re: [9fans] dns poisoning
Nice catch!
2012/8/29 :
> you are right!
>
> baddelegation() is checking for that, but it was not effective because it
> bailed out before even entering that for loop because of:
>
> if(t == nil)
> t = lookupinfo("dom");
> if(t == nil)
> return 0; <- delegation loop will not be checked :(
>
> the following patch makes it work:
>
> dblookup.c:799,806 - /sys/src/cmd/ndb/dblookup.c:799,804
>
> if(t == nil)
> t = lookupinfo("dom");
> - if(t == nil)
> - return 0;
>
> for(; rp; rp = rp->next){
> if(rp->type != Tns)
> dblookup.c:816,821 - /sys/src/cmd/ndb/dblookup.c:814,822
> return 1;
> }
>
> + if(t == nil)
> + continue;
> +
> /* see if delegating to us what we don't own */
> for(nt = t; nt != nil; nt = nt->entry)
> if(rp->host && cistrcmp(rp->host->name, nt->val) == 0)
> --
> cinap
>
Re: [9fans] dns poisoning
> dblookup.c:816,821 - /sys/src/cmd/ndb/dblookup.c:814,822 > return 1; > } > > + if(t == nil) > + continue; > + > /* see if delegating to us what we don't own */ > for(nt = t; nt != nil; nt = nt->entry) > if(rp->host && cistrcmp(rp->host->name, nt->val) == 0) do we need this? it will prevent nt->next from being checked. - erik
[9fans] dmi dumper
i wrote a little dmi dump program that may be of interest, or at least curiosity. contrib quanstro/dmi. for example, ... ; aux/dmi -t 1 1: type sysinfo 1 len 27 handle 1 mfg ECS product IC890GXM-A version 1.0 serial uuid00020003000400050006000700080009 waketypepowersw (0x6) sku family it would be great to get feedback and/or corrections. i don't have any laptops, so things like battery info are completely unchecked. - erik
Re: [9fans] rc vs sh
> The minimal being a subset of POSIX.2 for the tools, Maybe I'm pushing too hard here, but even Posix isn't followed by all implementations of /bin/sh (no, I'm not sure, but there is no proof possible, as the future is also a factor). Thing is, Bash is well-defined, by a single implementation. That's the original issue: why Bash over RC? Go is incidental, but a data point in a big statistical set. All Bashes are equal, all instances of /bin/sh aren't: it's not better, it's singular. ++L
