Re: [9fans] Go Plan 9
On Tue, Apr 5, 2011 at 7:33 AM, Lucio De Re lu...@proxima.alt.za wrote: No, and no yuck, either: Go executables are different animals and they are allowed to be identified as such. Until they are not, when they are allowed to become the same animal. snip... And maybe it's just me being uninformed, but I have this suspicion that you need a Go toolchain with Plan 9 targets to produce Plan 9 executables. Maybe I should phrase this as a question: does the default Go toolchain produce Plan 9 executables or is a separate toolchain required for it? I'm pretty certain there's a need for two toolchains, but I'll be very happy to be proven wrong (and Ron right, of course). The vanilla Go distribution will produce ELF executables on Linux/FreeBSD/Darwin when the GOOS is set accordingly. If GOOS is set to plan9, 8l will produce a real Plan 9 a.out executable (it might complain it cannot find runtime and other packages unless you follow the procedure to build them). Pavel
Re: [9fans] Making read(1) an rc(1) builtin?
2011/4/4 smi...@zenzebra.mv.com: Unfortunately, echon.c doesn't solve the problem either, because it doesn't output a trailing newline. The crux of the problem is how to output -n on a line by itself, followed by a newline. I don't think it can be done symmetrically without adding another option to echo. This has been discussed before: http://9fans.net/archive/2008/03/491 Rob Pike gave an excellent answer to your question: echo -n -n' ' Lyndon's echon.c and echo.c are another solution, as many others which have been discussed here and in the 2008 thread. I'm really impressed of how much we can talk about such a simple program as echo. -- - yiyus || JGL .
Re: [9fans] Making read(1) an rc(1) builtin?
On 04/05/2011 03:19 AM, Anthony Sorace wrote: On Apr 4, 2011, at 17:35, smi...@zenzebra.mv.com wrote: All combined (forking read/test/echo, forking awk/sed/dd, parsing /mnt/acme/%d/events, etc.)... this, I think, is why languages like Perl came into existence and became so popular. I could definitely write an Acme event parser in Perl, or even in bash(1). rc(1) is just a few small features shy of making it practical to do in rc(1). I think this does a very good job of summing up the issue. I think the point you might be missing, though, is that most of the Plan 9 community is quite happy about the current state of things. You're likely right that considerations like this led to perl and bash - but rc's state is not an accident. We know where to get perl and bash if we want them. [bsd@werc ~] man bash |tail -24 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 builtin 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 subshell, which may be stopped as a unit. Array variables may not (yet) be exported. There may be only one active coprocess at a time. GNU Bash-4.2 2010 December 28 BASH(1) BTW, that highlighting, above, is mine ;) Put another way, your problem seems to be I can't write an acme client in rc with performance I'm happy with (leaving aside, for the moment, questions of measurement). Your solution is expand rc; I suspect the consensus of the community would be either deal with it or use C. Actually, that might be the consensus of the community on *most* issues. :-) -- Balwinder S bdheeman DheemanRegistered Linux User: #229709 Anu'z Linux@HOME (Unix Shoppe)Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Plan9, T2, Arch/Debian/FreeBSD/XP Home: http://werc.homelinux.net/ Visit: http://counter.li.org/
Re: [9fans] Making read(1) an rc(1) builtin?
On 4 April 2011 22:35, smi...@zenzebra.mv.com wrote:
roger peppe rogpe...@gmail.com writes:
when i've needed a -n safe version of echo in
the past, i've used something like this:
fn myecho {echo -n $* ^ '
'}
That doesn't work right when (~ $#* 0). It outputs a rogue space prior
to the newline. echo, with no arguments, should ouput just a newline.
it works fine, with no rogue spaces. did you try it?
I'm trying to write an Acme client in rc(1). I'd like to avoid spawning
a new read(1) process every time I make a keystroke or click the mouse.
Using multi-line reads wouldn't help much, because interactivity needs
to be maintained.
I'm using rc(1) because the /mnt/acme/%d/events interface is
well-documented (in /sys/doc/acme/acme.ps), but the C code under
/acme/bin/source/ for reading /mnt/acme/%d/events it is definitively
cryptic. I've managed to peel away the extra layers of code from one of
the simpler Acme clients, in /acme/bin/source/adict/win.c, and am in the
process of creating a general-purpose Acme event parser in C. The
output of the filter will be in a form easily digestible by scripts, and
would provide a good skeleton example of event parsing for other
coders to build upon. (There doesn't currently appear to be any such
starter code under /acme/bin/source or /sys/doc.)
If only Acme put a single extra space immediately prior the first
integer (c0) in it's event messages, this parsing could have been done
almost entirely within rc(1).
the usual solution to problems like this is to write a little
helper program in C. you might want to look at
http://man.cat-v.org/p9p/1/acmeevent
Re: [9fans] Go Plan 9
Anthony Martin al...@pbrane.org once said: -#define MaxArena32 (2U30) +#define MaxArena32 (240U20) I forgot to mention this earlier but for the curious, I used 240mb here because that is USTKTOP-USTKSIZE in 9vx. Anthony P.S. Has anyone ran into the SEGMAPSIZE limit on native Plan 9? The current value of 1984mb was set on Sep 16 1998 and if I've inferred the heuristic correctly, it was meant to be USTKTOP-4*USTKSIZE. (At the time, the top of user VM was 0x8000). Using the current USTKTOP would give a size of 3520mb.
Re: [9fans] Making read(1) an rc(1) builtin?
This discussion is interesting. rc is not as good a shell as bash because it lacks built-ins that make it a good programming language for writing an acme extension Did I summarizer it correctly? Once summarized, am I the only one who finds it absurd? ron
Re: [9fans] Go Plan 9
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox r...@swtch.com wrote: The best answer might be to make USTKTOP 1GB. Agreed. ron
Re: [9fans] Making read(1) an rc(1) builtin?
This whole discussion has been absurd.
to quote fgb, relax. or to quote dek, \relax{}
- erik
Re: [9fans] Making read(1) an rc(1) builtin?
On 5 April 2011 17:52, Jacob Todd jaketodd...@gmail.com wrote: This whole discussion has been absurd. On Apr 5, 2011 11:50 AM, ron minnich rminn...@gmail.com wrote: This discussion is interesting. rc is not as good a shell as bash because it lacks built-ins that make it a good programming language for writing an acme extension Did I summarizer it correctly? Once summarized, am I the only one who finds it absurd? ron No. The discussion was not absurd. And no, Ron's summary was not a summary. Ruda
Re: [9fans] Making read(1) an rc(1) builtin?
On Monday 04 of April 2011 23:35:26 smi...@zenzebra.mv.com wrote: (...) I know that using awk(1) is a possibility, but awk(1) still has to system() every test -e, just like rc(1) does. (...) instead of test -e (and other object-related tests), why not to pipe from awk to plumb (the program) or to /mnt/plumb/send? i guess plumber is the default `dispatch-if-object-exists' mechanism in p9. using the `plumb' program would require exactly one rfork()/exec() for one message you decide in awk to pass through -- less than one per click. even better, piping to /mnt/plumber/send is just one open()/write(). your script is free to add and/or change plumber rules upon start. -- dexen deVries [[[↓][→]]] ``In other news, STFU and hack.'' mahmud, in response to Erann Gat's ``How I lost my faith in Lisp'' http://news.ycombinator.com/item?id=2308816
Re: [9fans] Making read(1) an rc(1) builtin?
I don't want to get into the rc discussions but this caught my eye: I would use scheme, but the scheme in fgb's contrib doesn't seem to provide any way of stat(2)ing path names without resorting to its foreign function interface. :( I am adding a bunch of stuff to Nils Holm's s9fes (Scheme 9 from Empty Space) Scheme interpreter. Mainly access to most of the syscalls (including stat). libc as needed (though I first try to implement its functions in s9). I can do things like (define fd (sys:open foo 0)) (display (sys:read fd 1)) (sys:close fd) I won't touch threads or things like seg*(), *brk() for now at least. Goal is to see how well one can do systems programming in Scheme. More to do but let me know if you are interested.
Re: [9fans] Making read(1) an rc(1) builtin?
On Tue, Apr 5, 2011 at 9:04 AM, Rudolf Sykora rudolf.syk...@gmail.com wrote: No. The discussion was not absurd. And no, Ron's summary was not a summary. Well, I'm not so sure, because the original motivation was this: I'm trying to write an Acme client in rc(1). I'd like to avoid spawning a new read(1) process every time I make a keystroke or click the mouse. This seemed to be the starting point. I'm not that worried, quite \relax'ed in fact, I just find the whole thing kind of ... well ... I'm at a loss for words :-) ron
Re: [9fans] Go Plan 9
On Mon, Apr 4, 2011 at 9:22 PM, Russ Cox r...@swtch.com wrote: The number of people who want to run Go on Plan 9 is already small. The number of people who want to run Go on Plan 9 on 9vx is smaller yet. At that point why not just run Go directly? 9vx is a nice hack but still a hack. Russ What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively. InfernGo? Dave
Re: [9fans] Go Plan 9
On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox r...@swtch.com wrote: All that Microsoft thinking (99.9%-thinking, if you find the other label offensive) to avoid adding a minute, one-off change to the Go runtime? It is not a minute, one-off change. I don't know how to fix it to cope with tiny virtual address spaces like those in 9vx. It's not something I anticipated when I wrote the allocator, and it's not something I really want to spend time on for such a tiny fraction of use cases. We have limited time. We don't even support OS X 10.5 anymore. I'm not sure apple support OS X 10.5 anymore either? I think that's why the OS updates are so inexpensive :-) (what was it like 40 bucks to go from 10.5 to 10.6?) The best answer might be to make USTKTOP 1GB. Russ
Re: [9fans] Go Plan 9
What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively. InfernGo? huh? - erik
Re: [9fans] Go Plan 9
On Tue, Apr 5, 2011 at 10:36 AM, erik quanstrom quans...@labs.coraid.comwrote: What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively. InfernGo? huh? - erik Inferno-like Go based OS (instead of Limbo??) Not necessarily with any kind of virtual machine but it could be a neat project...
Re: [9fans] Go Plan 9
InfernGo? Goribund ;)
Re: [9fans] Go Plan 9
2011/4/5 andrey mirtchovski mirtchov...@gmail.com InfernGo? Goribund ;) What a positive sounding project name!
Re: [9fans] Making read(1) an rc(1) builtin?
Lyndon Nerenberg lyn...@orthanc.ca writes: Unfortunately, echon.c doesn't solve the problem either, because it doesn't output a trailing newline. That's the whole point. 'echon' replaces 'echo -n ...', then echo.c loses all knowledge of any option flags. Oh. So there's another version of echo, too? I didn't know that. /me pulls up lyndon's contrib again... Hm. I don't see an echo.c in there. But anyway, yes, splitting echo and echo -n into two commands would solve the problem in a symmetric way. ron minnich rminn...@gmail.com writes: This discussion is interesting. rc is not as good a shell as bash because it lacks built-ins that make it a good programming language for writing an acme extension Did I summarizer it correctly? Once summarized, am I the only one who finds it absurd? No, I think a statement of the problem would be more like rc(1) is not as useful a language as $fill_in_your_favorite_turing_complete_luggage because it's not Turing complete. You cannot map arbitrary input to arbitrary output with a program of finite size in pure rc(1). Developing an Acme client is just, historically, how I came to that discovery (and to my subsequent frustration with rc's feature set). I think string parsing and numeric comparisons are reasonable features to include in almost any programming language. I think having primitives for line-oriented input and line-oriented output are more than appropriate for a line-oriented language like rc(1). As it stands, rc(1) can have it's cake, but it can't eat it without a fork(2). -- +---+ |E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---+
Re: [9fans] Making read(1) an rc(1) builtin?
This discussion is interesting. rc is not as good a shell as bash because it lacks built-ins that make it a good programming language for writing an acme extension Did I summarizer it correctly? Once summarized, am I the only one who finds it absurd? No, I think a statement of the problem would be more like rc(1) is not as useful a language as $fill_in_your_favorite_turing_complete_luggage because it's not Turing complete. You cannot map arbitrary input to arbitrary output with a program of finite size in pure rc(1). space shuttles are not as useful as cars, because the space shuttle is not d.o.t. approved. that might be true as you've stated the problem, but you do realize that rc is an acronym for run commands? and you do realize that the unix philosophy is all about this sort of encapsulation and modularity, right? the shell by design doesn't have to do everything. i really don't understand why you can't just skip reading the acme events you don't want, or if they're mixed in with important events. write a little filter in c that pushes the ones you don't want back to acme. is the problem here that you are unfamiliar with c and don't want to write that bit? - erik
Re: [9fans] Go Plan 9
2011/4/5 Lucio De Re lu...@proxima.alt.za: As for not running Go on 9vx, that's a pain, I have such a nice 9vx installation on my Ubuntu 32-bit laptop that it almost fools me into believing it's Plan 9. I don't always have a convenient CPU server at hand to run Go on it. Why not to run Go directly on your Ubuntu laptop – without the 9vx abstraction?
Re: [9fans] Making read(1) an rc(1) builtin?
On 5 Apr 2011, at 9:58 am, yy wrote: I'm really impressed of how much we can talk about such a simple program as echo. Me also. Yet another solution is not to use echo in the first place. This won't work on p9p, but on plan 9 if you want to echo $foo where $foo(1) might possibly be '-n', you can cat /env/foo instead. If you have a var which is never going to contain _just_ '-n' alone, then you can echo $foo
[9fans] plan9 as a dedicated remote file server
I want to set up a dedicated remote plan9 system to periodically check mail and print parts of emails from certain senders. I think I see how to do this using rc. I'm not sure about a restart after a power restoration. Do I have to modify the kernel to provide for a fixed user and root, instead of the usual login? Or, is there an easier solution? Thanks, -Tom
Re: [9fans] Making read(1) an rc(1) builtin?
Me also. Yet another solution is not to use echo in the first place. This won't work on p9p, but on plan 9 if you want to echo $foo where $foo(1) might possibly be '-n', you can cat /env/foo instead. please google the famous bikeshed post. - erik
Re: [9fans] plan9 as a dedicated remote file server
I'm not sure about a restart after a power restoration. set the machine to automaticly boot. you will need to be careful about power loss. if you expect power loss, you will be happier without venti, and perhaps without fossil. Do I have to modify the kernel to provide for a fixed user and root, instead of the usual login? if you use a cpu kernel and nvram, you will not need a login. - erik
Re: [9fans] Go Plan 9
So I can write go programs that take advantage of private namespaces and other Plan9 innovations. Paul On Tue, Apr 5, 2011 at 12:06 PM, Yaroslav yari...@gmail.com wrote: 2011/4/5 Lucio De Re lu...@proxima.alt.za: As for not running Go on 9vx, that's a pain, I have such a nice 9vx installation on my Ubuntu 32-bit laptop that it almost fools me into believing it's Plan 9. I don't always have a convenient CPU server at hand to run Go on it. Why not to run Go directly on your Ubuntu laptop – without the 9vx abstraction? -- I'm migrating my email. plalo...@telus.net will soon be disconnected. Please use paul.a.lalo...@gmail.com from now on.
Re: [9fans] plan9 as a dedicated remote file server
Or, is there an easier solution? If I understand you correctly, you are running a standalone terminal with the pcf kernel. Then, you can set variables nobootprompt and user in you plan9.ini. For example: nobootprompt=local!#S/sdC0/fossil user=glenda -- David du Colombier
Re: [9fans] Making read(1) an rc(1) builtin?
On 5 Apr 2011, at 8:56 pm, erik quanstrom wrote: Me also. Yet another solution is not to use echo in the first place. This won't work on p9p, but on plan 9 if you want to echo $foo where $foo(1) might possibly be '-n', you can cat /env/foo instead. please google the famous bikeshed post. That was an easy comment off the top of my head. I am sorry I didn't read your post properly before posting. I get rather caught up in replying to people who want to add features when there's already a hundred workarounds because I thought I wasn't very good at solving problems. I'm very much not good enough to deal with my offline (not computer-related) problems which everyone around me wants to make out are trivial.
Re: [9fans] Making read(1) an rc(1) builtin?
i threw in the line reading code from /sys/src/cmd/read.c into rc.
here are the results:
9grid% cat builtinread
#!/tmp/rcread
for (i in `{seq 1 1}) { echo $i | read } /dev/null
9grid% cat origread
#!/bin/rc
for (i in `{seq 1 1}) { echo $i | read } /dev/null
9grid% cat noread
#!/bin/rc
for(i in `{seq 1 1}) { echo $i } /dev/null
9grid% time builtinread; time origread
1.49u 14.63s 17.61r builtinread
1.63u 21.99s 18.58r origread
I do see a decrease of the context switches by half, but that time is
certainly taken by rc itself.
just the effects of the echo preceding the read:
9grid% time noread
0.87u 9.36s 13.20r noread
9grid%
and just by itself (the rc builtin doesn't support arguments, this
should illustrate that it is in fact a builtin):
9grid% read /tmp/test
test
9grid% read /tmp/test
(broken)
(broken)
9grid% /bin/read /tmp/test
test
9grid%
under a debugging ramdisk we can see the difference in reads for the
two programs (you can guess that the context switch and the reading of
the binary are lost in the noise of reading a file char-by-char:
9grid% read test
ramfs 518560:-Twalk tag 12 fid 579 newfid 693 nwname 1 0:test
ramfs 518560:-Rwalk tag 12 nwqid 1 0:(0003 3 )
ramfs 518560:-Topen tag 12 fid 693 mode 0
ramfs 518560:-Ropen tag 12 qid (0003 3 ) iounit 8192
ramfs 518560:-Tread tag 12 fid 693 offset 0 count 1
ramfs 518560:-Rread tag 12 count 1 't'
ramfs 518560:-Tread tag 12 fid 693 offset 1 count 1
ramfs 518560:-Rread tag 12 count 1 'e'
ramfs 518560:-Tread tag 12 fid 693 offset 2 count 1
ramfs 518560:-Rread tag 12 count 1 's'
ramfs 518560:-Tread tag 12 fid 693 offset 3 count 1
ramfs 518560:-Rread tag 12 count 1 't'
ramfs 518560:-Tread tag 12 fid 693 offset 4 count 1
ramfs 518560:-Rread tag 12 count 1 '
'
test
ramfs 518560:-Tclunk tag 12 fid 693
ramfs 518560:-Rclunk tag 12
9grid% ./read test
ramfs 518560:-Twalk tag 12 fid 579 newfid 693 nwname 1 0:test
ramfs 518560:-Rwalk tag 12 nwqid 1 0:(0003 3 )
ramfs 518560:-Topen tag 12 fid 693 mode 0
ramfs 518560:-Ropen tag 12 qid (0003 3 ) iounit 8192
ramfs 518560:-Twalk tag 12 fid 579 newfid 644 nwname 1 0:read
ramfs 518560:-Rwalk tag 12 nwqid 1 0:(0002 8 )
ramfs 518560:-Topen tag 12 fid 644 mode 3
ramfs 518560:-Ropen tag 12 qid (0002 8 ) iounit 8192
ramfs 518560:-Tread tag 12 fid 644 offset 0 count 32
ramfs 518560:-Rread tag 12 count 32 '01eb 7e20 1084
0420 3e21 13b7 16c6'
ramfs 518560:-Tclunk tag 12 fid 644
ramfs 518560:-Rclunk tag 12
ramfs 518560:-Tread tag 12 fid 693 offset 0 count 1
ramfs 518560:-Rread tag 12 count 1 't'
ramfs 518560:-Tread tag 12 fid 693 offset 1 count 1
ramfs 518560:-Rread tag 12 count 1 'e'
ramfs 518560:-Tread tag 12 fid 693 offset 2 count 1
ramfs 518560:-Rread tag 12 count 1 's'
ramfs 518560:-Tread tag 12 fid 693 offset 3 count 1
ramfs 518560:-Rread tag 12 count 1 't'
ramfs 518560:-Tread tag 12 fid 693 offset 4 count 1
ramfs 518560:-Rread tag 12 count 1 '
'
test
ramfs 518560:-Tclunk tag 12 fid 693
ramfs 518560:-Rclunk tag 12
9grid%
so, an optimized /sys/src/cmd/read.c that doesn't read char-by-char
should give us an improvement, right? right:
9grid% newaread
1.52u 22.56s 15.66r newaread
and that's just for the silly test string. the improvement would be
bigger for longer strings.
code for aread is on sources: /contrib/andrey/aread.c
YMMV.
