Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
On Tue, Mar 17, 2009 at 5:26 PM, Uriel wrote: > Unfortunately that doesn't work in this case, my input is HTTP post > data, which is a single line of URL-encoded text which I have to > decode into multiple parameters of arbitrary length. writing a shell script doesn't mean you have to write everything in the shell. why not write a simple c program that reads stdin, decodes the key=value arguments, and writes each "value" to /env/form_key? russ
Re: [9fans] I can not remember if I sent this or not: MIPS-64 (sort of) notebook
ron is suggesting is that with minimal effort the plan 9 kernel could be made to compile using gcc instead of the standard plan 9 compilers. he's right. erik's point is that once you have a kernel up, you still need to give it executables to run. this either requires porting the standard compilers to the target machine or somehow making the entire source tree compile under gcc, which would require significantly more effort than the kernel. he's also right. it all depends on what you want from plan 9. for me, the fleet plan 9 compilers save me so much time and make me so much more productive compared to waiting on gcc that on balance i'd rather spend the time to port the compiler than switch to gcc. ron is already using gcc to generate binaries to run on plan 9, though, and his use of plan 9 depends much more heavily on the "plays well with networks" aspect than it does on the fast compilation. and maybe there's no one to write the new compiler. there, using gcc might make sense. russ
Re: [9fans] kernel tag bug?
On Tue, Mar 24, 2009 at 10:59 AM, erik quanstrom wrote: > it looks like devcons is suffering from some sort of tag collision. > a Rwrite is coming back for a Tread. > > Sat Jan 24 09:43:47: mnt: proc rc 10946: mismatch from /mnt/temp/data > /dev/cons rep 0xf63661a8 tag 1 fid 1170 T116 R119 rp 1 > Sat Jan 24 10:06:26: unexpected reply tag 1; type 117 > Fri Jan 30 15:21:48: 336082 page: checked 75 page table entries > Wed Mar 18 11:27:27: mnt: proc rc 4632855: mismatch from /mnt/temp/data > /dev/cons rep 0xf69e84e8 tag 37 fid 5644 T116 R119 rp 37 > > i don't immediately see the cause of the problem. i've seen this for years in various forms but it had never happened regularly enough to track down, and it was never clear that it was the kernel's fault (and not, say, the 9p server). if you want to look for the problem, you might find it easier in 9vx. i see it in 9vx all the time if i interrupt an outstanding 9p message by typing DEL. 9fs sources; ls /n/sources; DEL on a slow connection, for example. russ
Re: [9fans] drawterm font
On Tue, Mar 24, 2009 at 12:35 PM, Benjamin Huntsman wrote: > Not a big issue, but is it possible to change the default font in drawterm? no; the bitmaps for the ascii characters are embedded in the drawterm binary. you could perhaps arrange to build a different binary but it is easier to use rio. you could start a rio with a single large window automatically and then at least you'd have the benefit of snarf/paste, scroll, etc. russ
Re: [9fans] kernel tag bug?
> doesn't the kernel get credit either way? either > it's the source (devmnt) or the server (devcons). > am i missing something? if devmnt is involved, devcons is not. it is some 9P server mounted on /dev/cons, not the kernel's devcons. russ
Re: [9fans] rc output redirection
> But when you do something like
> cmd1 | cmd2 |[2] cmd3
> you get cmd1's stdout piped to cmd2's stdin; but my confusion begins
> here: is it cmd1's or cmd2's stderr that gets redirected to cmd3's
> stdin? maybe both? my guess is that ...
why guess?
% {echo cmd1 >[1=2]} | {echo cmd2 >[1=2]} | sed 's/^/cmd3: /'
cmd1
cmd2
% {echo cmd1 >[1=2]} | {echo cmd2 >[1=2]} |[2] sed 's/^/cmd3: /'
cmd3: cmd1
cmd3: cmd2
%
not what i expected, but there you have it.
and it makes sense: cmd1 and cmd2 are both
writing to the same stderr, so redirecting it
redirects both.
> how can I redirect cmd1's stderr to cmd3's stdin instead
> of cmd2's? or both?
if you don't care about cmd2's stderr, then you can get rid of it
% {echo cmd1 >[1=2]} | {echo cmd2 >[2]/dev/null} |[2] sed 's/^/cmd3: /'
cmd2
cmd3: cmd1
%
> It's easy to think of more complex cases.
it's easy to think of elephants.
rc does its general-purpose job very well.
if you have special-purpose needs,
as lucio suggests, write a c program.
russ
Re: [9fans] self inflicted gunshot wound
> abort()+0x0 /sys/src/libc/9sys/abort.c:6 > plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125 >n=0x93 >a=0x3e990 >s=0x3a430 >t=0x3a497 t is unlikely to be correct here; it would have been saved at the last call to strlen but since then got +='ed with the result. > acid: regs() > PC 0xc80c abort /sys/src/libc/9sys/abort.c:6 > SP 0x00068e78 ECODE 0x0004 EFLAG 0x0206 > CS 0x0023 DS0x001b SS 0x001b > GS 0x001b FS0x001b ES 0x001b > TRAP0x000e page fault > AX 0x0003a4c3 BX 0x0003a4c6 CX 0x0003a430 DX 0x0093 > DI 0x0003a4c7 SI 0x0003ea19 BP 0x0003e9f0 there's s+n in AX. t is likely to be BX or DI, judging from the pointer values; it has either written 3 or 4 bytes past the end of the allocated section, which explains the abort. you'd have to disassemble plumbpackattr to make sure. it would be interesting to print *(*plumbpackattr:s\s) to see if the string is corrupted. > the interesting thing that happened at the > time was that one of plumber's clients was > off in the weeds waiting for something to > happen. i don't understand what you mean. plumbers clients are always waiting for something to happen. the plumber's only job is to tell them when it does. i suspect the global buffer in plumbpackattr's quote. if you had multiple threads running through plumbpackattr at once, it might cause the kind of crash you saw. all the ordinary plumbing is protected by the QLock named queue, but it looks like maybe if you'd been writing the rules file at exactly the same time, that might have triggered a simultaneous plumbpackattr call. i'd prefer to be sure before throwing a lock in plumbpackattr. russ
Re: [9fans] self inflicted gunshot wound
> acid: *(*plumbpackattr:s\s) > filetype=mail sender=x...@.xxx length=8749 mailtype=delete > date='Sun Mar4de7153cecd4a9b45aead1clfs > digest=aff98fb56526d94ab768adbc93d12d989a11ed53 > several were waiting on something else to happen; they were > sleeping waiting for an exclusive-open file. the only reason > i mentioned it is that may have been 5 minutes between the > time that plumber tried to write the message and when it > could be delivered. aha. plumbunpackattr is also using attrbuf. that explains it. a new plumbing message came in at the same time an old one was being delivered. this can only happen if a reader gets behind and is catching up while new messages are still coming in. i would put a lock around the use of attrbuf in both plumbpackattr and plumbunpackattr. russ
Re: [9fans] exportfs security question
> /* exchange random numbers */ > srand(truerand()); > for(i = 0; i < 4; i++) > key[i+12] = rand(); if one really cared, the right thing to do would be fastrand() calls. truerand is only for things that absolutely must be random (not pseudo-random) or for seeding random number generators, as in this example. all the auth protocols are due for a rework, but honestly i don't think anyone cares enough to see it through, myself included. russ
Re: [9fans] noweb and literal programming
Noweb has a nice simple interface (if literate programming is what you want) and runs on Plan 9. It's somewhere: I'm sure if you dig around you can find it. Maybe it's in /n/sources/extra. I used it quite a bit with latex. I don't remember whether I ever used it with troff. Russ
Re: [9fans] extensions of "interest"
> I still can't figure what "typestr" does in the C compiler! right on schedule! http://9fans.net/archive/2001/05/482 (may 31 2001) http://9fans.net/archive/2005/05/69 (may 7 2005) russ
Re: [9fans] sources browser script?
On Fri, Apr 17, 2009 at 4:12 AM, Skip Tavakkolian <9...@9netics.com> wrote: > i think it's a different thing. yes > there's an old thread where ehg > mentions it a filtering fs based on exportfs. that's yet another different thing. the sources pages are internally rewritten into /magic/something/path and then ip/something (not released) gets run to generate those pages. ultimately it's just a shell script wrapped around ls. i'm sure one could recreate it in not very much time. it's not in the distribution, and in fact i don't even remember the name of "something". russ
Re: [9fans] security questions
> That said, I don't disagree. Perhaps Plan 9's environment hasn't been > assumed to contain malicious users. Which brings up the question: Can > Plan 9 be safely run in a potentially malicious environment? Based on > this argument, no, it cannot. Since I want to run Plan 9 in this sort > of environment (and thus move away from that assumption), I want to > address these problems, and I kind of feel like it's weird to be > essentially told, ``Don't do that.'' If you were trying to run Plan 9 on systems that were allowed to flip 1% of the bits in memory at random each day, we'd tell you "don't do that" too. Linux and FreeBSD and OS X can't be run in the kind of environment you describe either. If people are being malicious and trying to take down the system, the right fix is to kick them off. If you want true isolation between the users you should give them each a VM, not a Plan 9 account. Russ
Re: [9fans] automatic page sharing
> Assuming statically linked-in libraries are properly aligned, > we'll have lots of equal pages in the system, so the kernel could > find and automatically map them together. This is not true. When static libraries are linked into a target binary, only the necessary objects are taken, and all the symbol references are resolved (avoiding the need for relocation at load time), and the code is not position-independent. So even if they were "properly aligned", the bits of common code would be very small. You'll see this if you run an experiment and compare two big binaries for common code sequences. They'll be there, but nothing nearly as big as a page. Russ
Re: [9fans] missing ed's line numbering in sam -d
On Fri, Apr 24, 2009 at 1:03 AM, Rudolf Sykora wrote: > when using 'sam -d' to remotely edit files I really miss the option to > print line numbers along with lines, like ed's e.g. '1,10n'. > > Is there anything like that? Why not? no. because for remotely editing files, you're supposed to use sam -r. russ
Re: [9fans] wrarenas
rdarenas reads directly from disk. wrarenas writes to venti, which means all of the network and seek overhead. 36 hours is too long, but it definitely isn't going to run at disk speeds. it sounds like your bloom filter wasn't doing anything useful. russ
Re: [9fans] Borderless rio
> I also have a question. I'm running this script to open rio with workspaces : > %vx ; cat bin/rc/riows > #!/bin/rc > > labels=$* > if(test $#labels -lt 1) > labels=(1 2 3 4) > > rio.b -I -i'\ > for(label in $labels) > window -miny 40 ''rio -i label ''$label > # give time to set all the labels > sleep 0.5 > window -dy 39 ''winwatch -e ^(winwatch|stats|faces)''' > > My question is: what is the better way to avoid that lot of quotes? I > can think of variables or functions, but I wonder what is the idiom > for nested quotes. the better way is to make each one of your giant quoted strings its own shell script. that's more useful too. russ
Re: [9fans] 9vx
the current 9vx tree builds and runs fine using ubuntu on x86-64: c2=; cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=8.10 DISTRIB_CODENAME=intrepid DISTRIB_DESCRIPTION="Ubuntu 8.10" c2=; uname -a Linux c2 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux c2=; the tree has been broken for a few months. i removed -fno-inline from the gcc command line but apparently that was making gcc work! if you have a partially built tree, you need to make clean after pulling the updates. russ
Re: [9fans] ssh v2, using a remote linux server
> 2) > More generally: > I use a powerful linux machine for doing some havier calculations. I > have no possibility of changing anything serious on that computer > (like that it could serve ssh v1), I am just an ordinary user. So far > I usually do the programming on my 'local' linux computer using p9p > versions of acme & rc (sometimes the linux's gvim), run some small > manageable tests on this local computer, then make a copy to the > remote machine, recompile it there (fortran) using a textual ssh > connection, and finally run it there. This brings along a /number of > complications... It'd be nicer if I could use the remote linux machine > in a way a plan9 cpu server is used. Is this possible? When you're developing on the big machine, you could mount the big machine's file system locally, and then you can continue to use acme to edit. If you want to use 9p, you could add the -e flag to srv and then use u9fs over ssh + 9pfuse. Alternately, if you have fuse installed you could use sshfs instead (Linux tool, not p9p tool). This way you mount the remote machine on /n/big and set things up so that the remote machine sends back path names like /n/big/home/you, so things like plumbing continue to work just fine. (Instead of awd in your cd alias (see label(1)), you'd use label /n/big`pwd`/-big.) Russ
Re: [9fans] problems with redirection in rc
On Tue, May 5, 2009 at 6:29 AM, Rudolf Sykora wrote:
> Hello everyone!
>
> To get some useful information from a file I write:
>
> ; for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na}
>
> to get lines from the 'otdit' files in *_r subdirectories with the
> word 'total' on them, but no 'na' on them. This works to my liking and
> produces sth. like
>
> 10_r total : 9.4105E-01
> 11_r total : 9.3897E-01
> 12_r total : 9.3685E-01
> 13_r total : 9.3446E-01
> 14_r total : 9.3180E-01
> 15_r total : 9.2890E-01
> 16_r total : 9.2589E-01
> 17_r total : 9.2299E-01
> 18_r total : 9.1860E-01
> ...
> 9_r total : 9.4317E-01
>
> Ok, now I wanted to save this, so I naively appended '> res'. But then
> the contents of 'res' was only the last line:
> 9_r total : 9.4317E-01
In
; for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep -v na} > res
the >res binds tighter than the for loop, so it runs a separate
redirection for each iteration. You need
; { for (i in *_r) @{cd $i; echo -n $i^' '; grep total otdit | grep
-v na}} > res
> Ok, so I thought '>> res' should be used instead. But then I got sth. like
>
> ];/home/sykora/CALC/doing/tests/9_r/-xeon4 9_r total : 9.4317E-01
> ];/home/sykora/CALC/doing/tests/10_r/-xeon4 10_r total :
> 9.4105E-01
> ];/home/sykora/CALC/doing/tests/11_r/-xeon4 11_r total :
> 9.3897E-01
> ];/home/sykora/CALC/doing/tests/12_r/-xeon4 12_r total :
> 9.3685E-01
> ];/home/sykora/CALC/doing/tests/13_r/-xeon4 13_r total :
> 9.3446E-01
> ];/home/sykora/CALC/doing/tests/14_r/-xeon4 14_r total :
> 9.3180E-01
> ];/home/sykora/CALC/doing/tests/15_r/-xeon4 15_r total :
> 9.2890E-01
> ];/home/sykora/CALC/doing/tests/16_r/-xeon4 16_r total :
> 9.2589E-01 ,
>
> which quite surprised me... Can you tell me why this happens? I am running
> p9p.
You've got the cd implementation from label(1) loaded.
In interactive mode, it echos escape codes that are
supposed to update the label in your terminal window.
Instead it wrote them to the redirected file.
I changed label to write to /dev/tty explicitly, which should
avoid this problem.
Russ
Re: [9fans] problems with redirection in rc
On Tue, May 5, 2009 at 8:44 AM, roger peppe wrote: > in that case, surely it'd be trivial to make a root-suid > executable that allows namespace manipulation in > a non-sensitive area (e.g. /mnt)? maybe it could > be distributed as part of p9p meaning hacks like > $NAMESPACE could go away under linux. > maybe it already has been, and i'm as ignorant as usual. if you have the fuse kernel module installed, you can run mkdir $HOME/acme acme -m $HOME/acme and acme will mount itself there via 9pfuse. in general i don't view fuse etc as stable enough to warrant throwing away $NAMESPACE. also you'd still have to deal with non-linux systems. finally, in the specific case of label: the echoing trick is sad but also works around the lack of exported file system when you connect to another machine via ssh. (in plan 9, if you cpu somewhere rc can still find the terminal's /dev/label. not so on linux, even in the supposed presence of usable per-process name spaces.) russ
Re: [9fans] command output on acme
win takes a command to run as an argument.
win tail -f yourfile
would be almost exactly what you want.
You'd just delete the window when you're done watching.
The only problem is that on Plan 9, Del in the
new window doesn't send a "hangup" note to tail,
but it should.
% diff -c /n/sources/plan9/acme/bin/source/win/main.c .
/n/sources/plan9/acme/bin/source/win/main.c:107,112 - ./main.c:107,113
while(*s==' ' || *s=='\t' || *s=='\n')
s++;
if(strcmp(s, "Delete")==0 || strcmp(s, "Del")==0){
+ write(notepg, "hangup", 6);
windel(w, 1);
threadexitsall(nil);
return 1;
%
Russ
Re: [9fans] auto reconnect for cpu servers
On Tue, May 12, 2009 at 11:43 AM, Steve Simon wrote: > Is there a technique or program that can be used on a diskless > cpu server to make it auto-reconnect when the file server reboots? > > I remember reading about the Challange file servers at the labs, > in which (I believe) the cyclone driver would write reboot to > /dev/reboot if the connection dropped. > > Is there somthing similar I could do elegantly with a tcp/ip > connection? I could just do a readdir(2) of / every 10 secs and > reboot if that fails but I assume somthing already exists. aux/reboot there is also recover (gorka should know where the source is these days) but that requires building a custom kernel to connect through it, and i'm not sure how well that particular setup works. russ
Re: [9fans] P9P on Lemote Yeeloong
I don't know that p9p has ever been built on a MIPS machine, so you might run into more problems after this one. You are almost certainly running Linux 2.6 so you shouldn't need to edit u.h -- it should be using pthreads already. You probably need to edit src/libthread/sysofiles.sh to add a case mips-Linux-2.6.*) echo pthread.o Linux-mips-context.o ;; Then you'll need to write Linux-mips-context.S and mips-context.h to provide useful versions of getcontext and setcontext and change threadimpl.h to use them on MIPS (like it does for __APPLE__ and __OpenBSD__). I looked around but I don't think I have any such implementations lying around. They're not too hard: just save and restore every register (technically, just the callee-saves, but I'm too lazy to look up which ones are which and too paranoid to trust them not to change). Russ
Re: [9fans] Permission Problem with p9p vnfs
On Thu, May 14, 2009 at 3:06 AM, Matthias Teege wrote: > Moin, > > I run "vnfs -L -i -b16k -c1k venti.score" on linux and mount it with > "vmount 127.0.0.1 /dump". If I try to access a private file as root I've > got "permission denied". You need to edit src/libdiskfs/*.c to change the access routines to add have = ino.mode&0777; if(ino.uid == au->uid) have >>= 6; else if(ino.gid == au->gid || ingroup(au, ino.gid)) have >>= 3; if(au->uid == 0)// <<< these two lines have = 7; Russ
Re: [9fans] aux/acidleak pool pathology
> obviously the Brdline loop in main is reallocating data and block > so they don't fit in their previous buckets and pool sbrk's more > memory. it would seem that pool is missing the fact that It's probably a combination of data and block growing together along with the occasional estrdup that is causing the fragmentation. You should rewrite both of the reallocs to double the array when they outgrow the current one instead of growing by a fixed amount. The fixed amount is nice because it avoids the extra variable tracking the maximum size of the array, but it's a terrible algorithm. Russ
Re: [9fans] aux/acidleak pool pathology
On Thu, May 21, 2009 at 9:54 AM, erik quanstrom wrote: > On Thu May 21 12:39:00 EDT 2009, r...@swtch.com wrote: >> > obviously the Brdline loop in main is reallocating data and block >> > so they don't fit in their previous buckets and pool sbrk's more >> > memory. it would seem that pool is missing the fact that >> >> It's probably a combination of data and block growing together >> along with the occasional estrdup that is causing the fragmentation. >> You should rewrite both of the reallocs to double the array when >> they outgrow the current one instead of growing by a fixed amount. >> The fixed amount is nice because it avoids the extra variable >> tracking the maximum size of the array, but it's a terrible algorithm. > > in this simple case, that is an fine solution. but i also see similar > behavior with upas/fs, especially when opening and closing multiple > mailboxes. i was actually trying to debug a case where upas/fs has > sbrk'd 800mb but had not had an active set >43mb when i ran across > this behavior. all allocators have fragmentation and reuse problems. some are better than others, but they all do. linear reallocs are always a bad idea; the worse part is requiring the array to be contiguous in the first place, but you can't qsort a linked list. if upas/fs is allocating arbitrarily large buffers, then its allocation behavior is broken too. > more importantly, since pool is used in the kernel, i would imagine > that a determined attacker could force the kernel to "run out" of > memory in a similar fashion. perhaps by dd'ing large chunks and > small chunks from /dev/zero. maybe there's a simple reason this can't > happen that i'm missing. but i don't currently see it. if the kernel can be forced to allocate an arbitrarily large chunk of data, that's the bug to fix, not the allocator behavior. it probably can, in its handling of strings like user names and large paths passed to open. /dev/zero doesn't allocate at all. russ
Re: [9fans] aux/acidleak pool pathology
> even after changing to a power-of-two allocation and starting > with 8k items, aux/acidleak still takes 400mb on a 40mb proc > with only 155278 bytes actually allocated (in the target process). > > is the a chance that pool is not packing the small > allocations together well? i wouldn't judge pool based on acidleak. have you checked how much data acidleak is allocating in that 400mb? i expect the data array to be huge: it knows about every word in memory that looks vaguely like a pointer. acidleak was never intended to be lightweight. >> if upas/fs is allocating arbitrarily large buffers, >> then its allocation behavior is broken too. > > there are a fixed number of large buffers. up to 15 messages > and mdir uses dirreadall so it can qsort. the qsort is easy enough > to eliminate, but it's more difficult to bound message buffers. i never said fixing it was easy. ;-) russ
Re: [9fans] acme --- undo/redo in a win window
On Thu, May 28, 2009 at 12:37 PM, Rudolf Sykora wrote: > it is somehow unclear to me, what happens in a 'win' window when I > 2-click 'Undo' or 'Redo' (I write it somewhere manually). Are some > commands processed again? (I happened to delete some text from the > window and thus had the idea to write 'Undo' and 2-click on it; sth. > happened, but I am puzzled from it.) If you Undo it undoes the edit to the window. If you Redo it redoes the edit. If as a result of those operations, new text appears after the cursor output point, that text is sent to the shell running in the window (or whatever is reading from the console). Russ
Re: [9fans] eqn and unicode
On Thu, May 28, 2009 at 4:08 AM, Gregory Pavelcak wrote: > If you write the eqn-word for a greek letter, "GAMMA" for > example; eqn passes the unicode character (the output of > Alt-*G) to troff. If, on the other hand, you type Alt-*G in eqn, > it passes `"\f2Γ\fP' to troff, thus producing, by my lights anyway, > a nicer looking character. I was just wondering if this was > intended as a way to give people both a roman-greek letter > and an italic one, or if it was intended to discourage the use > of eqn's letter names in favor of unicode, or if it just sorta > happened. Perhaps none of the above. Anyone know? Eqn should not generate different output for GAMMA vs Γ. Feel free to fix it. Russ
Re: [9fans] acme: dirty state after 1-2, 1-3 click in a tag line
The behavior is useful if the command is mk instead of win. You can run mk and it says mk in the top left until mk finishes and then it goes away. If you don't like seeing the win win win in the top corner, you can always edit the text yourself. Russ
Re: [9fans] plan 9 regexp
? is useful when it's not at the end of the pattern. grep 'utf-?8' is shorter than grep 'utf8|utf-8'. russ
Re: [9fans] Drawterm /mnt/term permissions issue
On Thu, Jun 4, 2009 at 4:58 PM, Ethan Grammatikidis wrote: > I run a plan 9 cpu server in Qemu and use drawterm to connect from the Linux > host. > I thought the /mnt/term mechanism would be very convenient for exchanging > files > between host & guest, but the guest sees all user/group names as > unknown/unknown, preventing writing. That's surprising. Drawterm isn't going around enforcing permission bits: if it can write, it writes. What it shows you in ls is what it gets from stat, but it doesn't rely on that to make decisions about what you can open. It just tries to open it. http://cvs.pdos.csail.mit.edu/cvs/drawterm/kern/devfs-posix.c?rev=1.5;content-type=text%2Fplain Russ
Re: [9fans] plan 9 regexp
> I'm sure. This is something that I would be interested in revisiting; > do you have any pointers to particularly relevant information? I > wonder how nicely these tree automata could be packaged into an > awk-like form. In addition to what others have suggested, look up [tree regular expressions] and [regular tree expressions]. Regarding ssam, I've always found it equally workable, if slightly clunky, to cat >/tmp/a; echo script | sam -d /tmp/a; cat /tmp/a. In fact, most of the time I want to be able to iterate over the whole input multiple times, so it's hard to imagine doing better. Russ
Re: [9fans] simple question: multiple rename
On Mon, Jun 8, 2009 at 12:50 AM, Rudolf Sykora wrote:
> Hello,
> Still wonder, what's the right way to make the following work:
The right way is
s=`{echo $i | sed 's/(.+)_g/\1/'}.
> s = `{sam -d <[2] /dev/null
> 1s/(.+)_g/\1
> p
> EOF
> }
If you must use sam, the right way is
s=`{echo '1s/(.+)_g/
p' | sam -d <{echo $i} >[2]/dev/null }
If you must use here docs, the way that works is
s=`{sam -d <[2]/dev/null}
1s/(.+)_g/\1
p
EOF
Russ
Re: [9fans] acme: send dot to the stdin of a more complicated command
> well, though an inspiring idea, it doesn't sound to be much practical:
> 1) I usually have a special window in which I have many commands. I
> then select the one needed and chord it to the appropriate window
> (i.e. I don't use the whole contents of a window).
> 2) sometimes I have more such windows.
This is an interesting usage model. I've never seen it before.
The power of acme is that you can extend it with external
programs. The script below implements this usage; I called it Run.
You can type and select your command in one window, with a name matching
pattern, and then in the other window's tag execute >Run pattern.
Run finds the window with a title matching pattern, pulls out the
selected text, and runs it through rc.
See http://swtch.com/~rsc/acme-Run.png for an illustration.
Russ
#!/bin/rc
if(! ~ $#* 1) {
echo 'usage: Run title' >[1=2]
exit usage
}
id=`{awk -v 'pat='$1 '$6 ~ pat {print $1}' /mnt/wsys/index}
if(~ $#id 0) {
echo 'no match for pattern' >[1=2]
exit none
}
if(! ~ $#id 1) {
echo 'ambiguous pattern' >[1=2]
exit ambiguous
}
if(~ `{wc -w /mnt/wsys/$id/rdsel} 0) {
echo 'no command selected' >[1=2]
exit missing
}
exec rc /mnt/wsys/$id/rdsel
Re: [9fans] plan9port acme can't load dump file with shell output of "9p read plumb/rules"?
Fixed. http://hg.pdos.csail.mit.edu/hg/plan9/rev/fb3ce7f4b2d1 Russ
Re: [9fans] plan9port acme can't load dump file with shell output of "9p read plumb/rules"?
On Mon, Jun 8, 2009 at 8:19 PM, Jason Catena wrote: > Applied fix locally, works like a champ. Thanks! Now I should > probably set up hg to get updates without patching it myself. If you downloaded the archive and extracted it, you can always use "cvs up -dAP" instead of hg. I keep the two in sync and the archive is a tar of a nightly cvs checkout. 9 man cvs Russ
Re: [9fans] plan9port acme can't load dump file with shell output of "9p read plumb/rules"?
> Thanks, but already cloned with hg, compiled, and verified it doesn't fail. > > Actually prefer a more advanced VC tool. I'm a big SCM geek, used > ClearCase for past 15 years. Out of curiosity, why Mercurial over Git? > Don't know either well enough to judge. A few years ago, when I made the decision, Git was the version control system for people who wanted to micromanage a version control system, and Mercurial was the one for people who wanted to get work done instead. To all the people who are going to reply saying Git is just as easy to use as Mercurial: my understanding is that Git has gotten to be about as easy to use as Mercurial, but I've already got a system that works. Thanks. Russ
Re: [9fans] critique of sockets API
> * performance overhead: app requesting data from a socket typically needs to > perform 2 system calls (select/read or alt/read) * lack of an "kernel > up-call API": which allows the kernel to inform an app each time network > data is available there is a mechanism. user programs call read(2). when data is available, the read finishes.
Re: [9fans] acme: 2-1chord on Edit in a 'win window' tag doesn't work
> In some acme window I have a command, e.g simply s/f/g/, I select it > with a mouse and 2-1 chord it on the Edit command in a tag line of a > window in which there is win running and also some text (for us e.g. > abcdefgh) is selected. Nothing happens. Only when the s/f/g/ is copied > in the tag line and the whole (together with the Edit) is 2-selected, > the command is executed, i.e. abcdefgh -> abcdeggh. > > This only happens for a win window, ordinary text window is ok as well > as a directory window. This is a design bug in acme. Acme sends events like this to external programs to handle, and if the program can't handle it, it sends the event back. Unfortunately, the "send it back" protocol is more limited and doesn't include a way to echo back the fact that this was an argument from a different window. So after this game of telephone, acme thinks you just 2-clicked Edit, not 2-1 clicked. Russ
Re: [9fans] interface for per process gdt manipulation
i haven't looked at your code, but a text interface is better than binary. if you make the first field the table index number, then you don't need to bother with seeking to fixed offsets. design a text format that is convenient to use instead of forcing the binary interface on everyone. also i wonder if this should really be in a separate ldt instead of polluting the gdt. russ
Re: [9fans] interface for per process gdt manipulation
On Mon, Jun 15, 2009 at 10:37 PM, wrote: >> i haven't looked at your code, >> but a text interface is better than binary. >> if you make the first field the table index number, >> then you don't need to bother with seeking >> to fixed offsets. design a text format that is >> convenient to use instead of forcing the binary >> interface on everyone. > > thats a good idea. i'll look into it. should the descriptor be > presented in a decoded/splitted up form or just be the text > representation of the numerical values? i would hope the former; that's what i meant by design a text format that is convenient to use. ideally, cat /dev/gdt should give me something that is easily human-readable, and if i feed the lines back into /dev/gdt one at a time aux/lines /dev/gdt it should be valid input. >> also i wonder if this should really be in >> a separate ldt instead of polluting the gdt. > > older versions of glibc use an ldt entry per thread but it got > deprecated for tls use by set_thread_area wich works only with with > gdt entries. > > also ldt is not supported on amd64, but gdt segments are still > present and used for tls on linux. good to know; thanks. russ
Re: [9fans] simple question: multiple rename
the easiest thing to do is not use spaces in
your file names, even if others do in theirs.
most people take that approach, even on unix,
and it works fine.
if you are worried about names with spaces
and want to make a script more robust, then
the simplest option is to set ifs='
'
while you are manipulating the file names
with `{} commands. spaces may be allowed
but newlines most certainly are not. i keep
nl='
'
in my profile specifically so i can say ifs=$nl.
> using ws in filenames is a fossil-only problem;
> kfs, cwfs and ken's fs won't allow it.
gee, i'm pretty sure i read somewhere that
plan 9 lets any program be a file server ...
>> So what happens when you drawterm from a un*x box or access a VFAT partition?
>
> nothing. i'm running ken's fs, so from drawterm ...
the question (quoted) was about talking to non-plan 9
file systems, i.e. a linux or windows /mnt/term or
a dossrv disk.
if you are trying to disallow space you'd have
to fiddle with every file server you could possibly
talk to, or you'd have to edit the kernel.
the barn door has been open for a decade.
it's very late to be talking about closing it.
http://swtch.com/cgi-bin/plan9history.cgi?f=1999/0323/port/chan.c;v=diff;e=1
russ
Re: [9fans] error while building p9p
On Tue, Jun 16, 2009 at 6:53 AM, Jeff Sickel wrote: > vcat.c and one other file haven't had the venti API updates applied. fixed, sorry for the delay. russ
[9fans] plan9port OS X window labels
I fixed a bug in plan9port's OS X window label handling the other day, so that 9term windows will update their labels properly in response to awd. Unfortunately it seems that the label update must be done inside the application event loop, but it originates outside the event loop. For now I have made the event loop check for updates and apply them, so the label changes at the next keystroke or mouse event. The obvious solution is to generate a fake event that is either a no-op of an existing message or that the event loop can recognize and discard, just so that the event loop notices the window label has changed. However, I could not get this to work. Perhaps there are Carbon experts here who will have better luck. http://hg.pdos.csail.mit.edu/hg/plan9/rev/12502ec69b95 Thanks. Russ
Re: [9fans] plan9port OS X window labels
> label has changed. However, I could not get this > to work. Perhaps there are Carbon experts here > who will have better luck. > > http://hg.pdos.csail.mit.edu/hg/plan9/rev/12502ec69b95 Fixed, thanks to André Günther. Russ
Re: [9fans] acme programming questions
In plan9port there is a libacme and
which makes some of this easier. It is basically
a wrapping of the routines from acme Mail.
Using libacme, your event waiter can do
something like this to send the events back:
while(winreadevent(w, e) > 0) {
switch(e->c1){
default:
Unknown:
print("unknown message %c%c\n", e->c1, e->c2);
break;
case 'E': /* write to body; can't affect us */
case 'F': /* generated by our actions; ignore */
case 'K': /* type away; we don't care */
break;
case 'M':
switch(e->c2){
case 'x':
case 'X':
case 'l':
case 'L':
/* send it back */
winwriteevent(w, e);
break;
case 'I': /* modify away; we don't care */
case 'D':
case 'd':
case 'i':
break;
default:
goto Unknown;
}
}
}
Russ
Re: [9fans] fossil/venti falling down?
On Wed, Jun 24, 2009 at 5:59 PM, erik quanstrom wrote: >> /boot/fossil: cacheLocalData: addr=155039 type got 0 exp 0: tag got >> 19383bf exp 11383bf >> /boot/fossil: cacheLocalData: addr=155167 type got 0 exp 0: tag got >> 19383bf exp 11383bf > > am i wrong in thinking that it would be an error to have the same tag at > two different addresses? the tag is more or less an inode number. every data block in a file has the same tag. russ
Re: [9fans] fossil/venti falling down?
> it's even neater to use a raid level that doesn't require venti > intervention. agreed. > does venti even keep scores on the bloom filter blocks and the icache? no, but those are soft data and can be reconstructed. russ
Re: [9fans] fossil/venti falling down?
On Thu, Jun 25, 2009 at 9:24 AM, erik quanstrom wrote: >> > does venti even keep scores on the bloom filter blocks and the icache? >> >> no, but those are soft data and can be reconstructed. > > being the paranoid type, i worry about this. does the > rebuild rate on a large (say, 1tb) venti make this a > practical strategy? there's no question that a better strategy is to use a 100% reliable underlying storage device. if that's not available and one must cope with disk failures some other way, it is very nice that venti can use the sha1 checksums to check the integrity of the core data and rebuild the rest. this is what i do when a disk fails on the mit venti backup server, which has about 5tb of data right now. it takes about an hour to rebuild everything with venti/buildindex. russ
Re: [9fans] p9p acme: incredibly slow typing in tag line for file.
The file tags tend to get redrawn in full after every change rather than incrementally like the body does. It has to do with the tag resize calculations, which I haven't gotten quite right. That said, you should be able to redraw the tag more than once per second. Is this with a remote X or some other high latency connection to the underlying graphics? Russ
Re: [9fans] when to use vac -q -d old.vac instead of simply vac -d old.vac
On Sun, Jun 28, 2009 at 6:13 PM, Fernan Bolando wrote: > man vac > "-q Increase the performance of the -a or -d options by detecting > unchanged files based on a > match of the files name and other meta data, rather than > examining the contents of the files" > > Why is -q not a default? Is there a reliability concern with that option? If the file contents change but the mtime and size remain the same, then vac -q will not notice the change and will not back up the new file contents. Some people worry about this case, others don't. Hence the flag. > I am currently doing an hourly backup using > > vac -d old_date-time.vac -f new_date-time.vac /home > which gives me a collection files with a date-time.vac filename. > > I am thinking I should just use vac -a main.vac /home > to switch to this method I only need to rename latest date-time.vac to > main.vac > and delete the other ones, right? vac -a creates a tree inside the vac archive. It expects the archive to have a top-level directory 2009 and subdirectories 0627, 0628, etc. You would need to change your vac tree to have that top-level structure before it would be valid input to vac -a. If you run it multiple times per day, the subdirectories for today would be named 0629, 0629.1, 0629.2, 0629.3, and so on. You can do this by building a local file tree with the right structure and using vac -m. On Sun, Jun 28, 2009 at 10:02 PM, Nathaniel W Filardo wrote: > It uses an astronomically large amount of memory, if nothing else. > Mirroring a little over 100MB of data from sources with vac -q occupies > roughly 85MB in core. Whether you use -q should have no effect on the memory usage. There may be a memory leak somewhere involving -q, but at first glance I don't see one. Feel free to investigate. Russ
Re: [9fans] confusing astro output
On Mon, Jun 15, 2009 at 11:33 AM, erik quanstrom wrote: > i ran astro -k a 3 times, a few minutes apart > on the same machine. the results are suprising > > The sun sets at 20:47:50 EDT > The sun sets at 20:47:49 EDT > The sun sets at 20:47:43 EDT > > Comet rises at 23:02:57 EDT > Comet rises at 23:03:06 EDT > Comet rises at 23:03:02 EDT > > can anyone explain why i don't > get the same answer? from ken: astro "events" are found by a binary search (in time) on a "crossing" of the position of objects. for an event like "rise", "set", "twilight", the event is very vague because of atmospheric bending. in those cases, the binary search is stopped before the precision of the printing (1 sec). binary searches are started from the time that the command was executed. thus the time found for the crossing will vary.
Re: [9fans] Guide to using Acme effectively?
Arguing about mouse vs keyboard misses the point. I'm very happy with acme's use of the mouse, but acme's power comes from the rest of its design. Russ
Re: [9fans] Guide to using Acme effectively?
[Revised to correct filename in cat command, sorry] On a Mac: mkdir -p $HOME/Library/KeyBindings cat >$HOME/Library/KeyBindings/DefaultKeyBinding.dict <
Re: [9fans] Guide to using Acme effectively?
> Anyway, hope people finds it useful, and please send me any extra info > on how to implement/configure/restore the standard Unix behavior in > any other environments and apps. On a Mac: mkdir -p $HOME/Library/KeyBindings cat >$HOME/Library/KeyBindings < P.S.: I even recently wrote a Google Chrome extension to implement the > Unix text editing keyboard shortcuts in web pages, it works fairly > well so far: http://repo.cat-v.org/burning_chrome/hosaka/ next task is > implementing acme-like mouse chording ;) Neat. If you could make the tab key actually generate a tab character, that would be fantastic. Russ
Re: [9fans] Joining multicolumn files
#!/bin/rc
awk 'BEGIN{
for(;;){
$0="";
ok=getline
Re: [9fans] Guide to using Acme effectively?
> Neat. If you could make the tab key actually generate > a tab character, that would be fantastic. I'm apparently not the only one. Firefox extension: https://addons.mozilla.org/en-US/firefox/addon/3955 Russ
Re: [9fans] troff and ps related
On Wed, Jul 8, 2009 at 4:49 AM, Rudolf Sykora wrote: > can anybody tell me why whatever .ps about troff/eqn I print has > misplaced lines? > E.g. quite generally, lines that make up tables either don't touch, or > stick out somewhere... this is because tbl is using characters to draw lines. it's not a great strategy. > Also, should > .BX something > make a nice box around 'something' or not? Anywhere I look I see the > top line be slightly above the side lines, it doesn't touch them. maybe should be doesn't. there's a reason no one uses it. even if it worked, boxes around words are pretty heavy weight. > Further, is there a way to view .ps files in a graceful way? Neither > proof nor page quite work for me. There is no comparison to gv in > linux at all, imho. It can't zoom well, if I manage to zoom in page > (often it takes infinitely long ---again compared to gv---, often it > ends with not enough memory; I also quite don't understand how the > zoom should work) it is not very nice, very unclear. you can start page with a ppi parameter: page -p 150 file.ps i have never managed to get gs to let me change that parameter on the fly during the gs conversation. if you can, please do, and then make zoom on postscript files use that mechanism. russ
Re: [9fans] troff and ps related
I assume you have a non-Plan 9 machine to play with. It's worth trying Heirloom troff there to see if the boxes are done better. They probably are. It would be a big integration effort to fit the Heirloom troff changes into the Plan 9 troff changes. Maybe it is worth it; maybe not. I like Heirloom troff for papers for its better handling of postscript and opentype fonts, although when I need to do nasty low-level things (like I do to generate slides) I need to fall back to the Plan 9 troff, because the low-level details seem to differ between the two. Honestly the box drawing has never really bothered me. I don't draw boxes around things because it's too noisy for my tastes anyway. Faulting troff for its box drawing is like faulting a web browser for its text blinking. > Do you think that troff is really dead? Is my pocketknife dead? Was it ever alive? When troff does what I need it to do and is the quickest way for me to get that done, it's the right tool for me. It may not be the right tool for you. Russ P.S. For what it's worth, the Plan 9 troff reads tex hyphenation rules too.
Re: [9fans] Fonts
This conversation reminded me that I have been meaning to clean up a program I wrote a while back and integrate it into plan9port. It generates Plan 9 bitmap fonts on demand using the native window system fonts. Right now it only works on OS X. I would gladly accept X11 support and OS X bug fixes. FONTSRV(4) FONTSRV(4) NAME fontsrv - file system access to host fonts SYNOPSIS fontsrv [ -m mtpt ] [ -s srvname ] fontsrv -p path DESCRIPTION Fontsrv presents the host window system's fonts in the stan- dard Plan 9 format (see font(7)). It serves a virtual direc- tory tree mounted at mtpt (if the -m option is given) and posted at srvname (default font). The -p option changes fontsrv's behavior: rather than serve a file system, fontsrv prints to standard output the con- tents of the named path. If path names a directory in the served file system, fontsrv lists the directory's contents. The fonts are arranged in a two-level tree. The root con- tains directories named for each system font. Each font directory contains subdirectories named for a point size and whether the subfonts are anti-aliased: 10 (bitmap) 10a (anti-aliased greyscale) 12, 12a, and so on. The font directory will synthesize additional sizes on demand: look- ing up 19a will synthesize the 19-point anti-aliased size if possible. Each size directory contains a font file and sub- font files named x.bit, x0100.bit, and so on represent- ing 256-character Unicode ranges. Openfont (see graphics(3)) recognizes font paths beginning with /mnt/font and implements them by invoking fontsrv; it need not be running already. EXAMPLES List the fonts on the system: % fontsrv & % 9p ls font or: % fontsrv -p . Run acme(1) using the operating system's Monaco as the fixed-width font: % acme -F /mnt/font/Monaco/13a/font Run sam(1) using the same font: % font=/mnt/font/Monaco/13a/font sam SOURCE /usr/local/plan9/src/cmd/fontsrv SEE ALSO font(7) BUGS Due to OS X restrictions, fontsrv does not fork itself into the background when serving a user-level file system. Fontsrv has no support for X11 fonts; on X11 systems, it will serve an empty top-level directory. On OS X, the anti-aliased bitmaps are not perfect. For example, the lower case r in the subfont Times-Roman/14a/x.bit appears truncated on the right and too light overall.
Re: [9fans] Announcing: iosrv for persistent rc sessions and 9gridchan.org
iosrv sounds neat. if you want a challenge, i would like to see the gui version, something along the lines of inferno's drawmux, which would be more work but also more broadly applicable. http://www.vitanuova.com/inferno/man/2/drawmux.html russ
Re: [9fans] what does #pragma fpround do?
> generates the same output and same assembly
> for both casts. can anyone explain what this pragma
> is supposed to do?
it changes the rounding mode from the standard
truncate to integer (expensive on a 387) to
round to nearest (incorrect but cheap).
#pragma fpround on
print("%d\n", (int)d);
#pragma fpround 0
print("%d\n", (int)d);
your examples compiles to the same code in both
cases because the rounding mode is only consulted
during code generation, which happens at the
function's final }. you'd need to write two different
functions to demonstrate the difference.
russ
Re: [9fans] building plan9port: arch spec, arm vs armv5tel
+plan9port-dev bcc: 9fans I have just created a mailing list for these questions. It is not documented anywhere yet - yours is the first. I would have called the mailing list plan9port-help but apparently -help is not a valid mailing list suffix. plan9port-...@googlegroups.com There is also an issue tracker at http://bitbucket.org/rsc/plan9port/issues. There may be a nicer URL in a few days. Russ On Mon, Jul 13, 2009 at 6:43 PM, Ethan Grammatikidis wrote: > Building plan9port on an arm box I get this message several times: > > sh: cd: 4: can't cd to armv5tel > > > At the end of the build the only binary in plan9/bin is mk: > > $ file bin/* | grep ELF > bin/mk: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for > GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped > > > In src/lib9 I symlinked getcallerpc-arm.c to getcallerpc-armv5tel.c; this > made lib9 build but it's not enough to build the executables. How do I > specify the architecture to the build system? I guess the setarch command may > work, but I'd need to compile it too and I'd ideally like to work without > that particular hack. >
Re: [9fans] C compiler question
> Yes, but in my example - sorry - "NeverDefined" doesn't mean "declared and
> defined elsewhere (or not)" but "not declared .and. not defined".
no and yes.
union U
{
struct
{
struct NeverDefined nf; // Unknown, definition
not #included
} S1
};
declares a struct named NeverDefined just by mentioning it.
the compiler should reject the use because NeverDefined
is not defined. it's just a bug. i don't have a copy of the
compiler to play with but erik's patch seems fine.
russ
Re: [9fans] C compiler question
enough.
there was a bug, plain and simple.
struct T {
struct S s;
};
is not valid. never was, never will be.
fix the compiler already.
russ
[9fans] Fwd: p9p acme: incredibly slow typing in tag line for file.
moving to plan9port-dev. http://bitbucket.org/rsc/plan9port/issue/5/acme-typing-at-1-char-sec-on-ubuntu-904 Subject: [9fans] p9p acme: incredibly slow typing in tag line for file. From: ron minnich Date: Sun, Jun 28, 2009 at 1:04 AM To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> I am unable to type at more than about one char per second (I am not making this up) in p9p acme in the tag line for a file. Only for file tag lines, not other tag lines, and it's all fine in the actual file window. This is ubuntu 9.04. Any hints welcome. thanks ron -- From: Jason Catena Date: Sun, Jun 28, 2009 at 10:35 PM To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> I just pulled down the latest versions with hg, compiled, and don't see this problem on my Ubuntu 9.04 box. No appreciable difference in typing rate for tags for files, directories, or shell-output windows, or their bodies. I have seen this kind of response time, but for the whole interface, because I exported an X-display through VPN from Red Hat to Windows XP with Cygwin/X. Does the same delay occur if you write into the tag file under /mnt/acme? I don't actually know the source code base that well, but it seems like it would help narrow things down if writes to the tag file showed up faster than input from the display. Jason Catena -- From: Russ Cox Date: Mon, Jun 29, 2009 at 8:46 AM To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> The file tags tend to get redrawn in full after every change rather than incrementally like the body does. It has to do with the tag resize calculations, which I haven't gotten quite right. That said, you should be able to redraw the tag more than once per second. Is this with a remote X or some other high latency connection to the underlying graphics? Russ -- From: ron minnich Date: Mon, Jun 29, 2009 at 12:53 PM To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Right on my laptop. But ubuntu 9.04 is known to have "X issues" and I did not know if this was another one. ron -- From: Micah Stetson Date: Tue, Jul 14, 2009 at 12:46 PM To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Has anybody figured this one out? I just updated to Ubuntu 9.04 and I'm seeing exactly the behavior Ron describes. Typing in a file tag (not a column tag) takes a noticeable amount of time per character -- varying between maybe 200ms and 1000ms by my guess. Sometimes I get the same delay in win and directory window tags, sometimes not. In any case, typing in the window body is fast. Also, resizing the acme window takes far too long -- maybe a couple of seconds. I think the time is linear in the number of files I have open in acme. Somebody asked whether writing to acme/n/tag was slow as well -- it doesn't look like it. Acme's still usable, since most of my text entry is in window bodies, but it sure is a pain. Thanks for any help anybody has to offer, Micah
Re: [9fans] building plan9port: arch spec, arm vs armv5tel
> Should we put patches here, too? Yes. I'd like plan9port-dev to have all the discussion of plan9port development and problems. There's a different story for patches that is still not quite complete, but it's a start. Look for upload.py in http://groups.google.com/group/plan9port-dev/t/a1b7f0123e261012 Russ
Re: [9fans] naive acid debugging
>> print("f->mb=", f->mb\X," =? mb=",mb\X,"\n");
>> f=f->next;
Always use . (never ->) in acid.
If f is a pointer, then the acid expression f.mb
is like the C expression (*f).mb aka f->mb.
The acid expression f->mb is like the C expression (**f).mb.
By using -> here you are indirecting one level too far.
-> is one of those acid features that seems
to exist only to cause confusion.
Russ
Re: [9fans] Fonts
On Wed, Jul 15, 2009 at 2:01 PM, David Leimbach wrote: > Just tried this from the mercurial snapshot from last night. > fontsrv appears to work but complains about fuse not being set up properly. > Does this mean acme is not going to work? > Should I be asking this on the plan9port mailing list? No, yes, moved there. Russ
Re: [9fans] git on plan9
On Wed, Jul 15, 2009 at 3:38 PM, wrote: > Thats good to hear HG is working well, I am really hoping for git > as it is hosting my current repo of works. If git does not exist > and there is no plan to do it in the future I can migrate over my > stuff (i'd prefer to do actual new work than porting VCS!). > Thanks for the replies thus far. If the hg is new enough that it comes with the bookmarks extension, then you can install a separate extension that will make it handle git too. I have been using hg to manipulate git repositories and find it far more pleasant than using git directly. http://hg-git.github.com/ http://bitbucket.org/abderrahim/hg-git/ The code at the second URL, which is a newer fork of the first URL's code, makes it almost transparent: hg clone git://asdfkjasdfadsf hg commit hg push hg pull -u They all just work. Russ
Re: [9fans] git on plan9
> does the git extension *require* bookmarks? yes. and it wouldn't surprise me if the extension uses API functions new since 1.0.2. if you're going to bother bringing in a new version, you might as well pull in 1.3. but 1.2 would have worked. russ
Re: [9fans] git on plan9
You don't need mmap to implement this mmap. If it's just trying to map files into memory read-only, you could implement it by open, stat to find length, malloc, readn, and return the pointer. This is what the original linuxemu did (and still does?). Russ
Re: [9fans] i/o on a hangup channel asymmetry
The programs that know about the signal are not the programs that need to be worried about. I'm much more worried about making sure that commands like grep pattern /n/dump/slow/slow/sys/log/mail | sed 5q stop as early as possible. The note is nice precisely because it doesn't involve editing the source for every command. Russ
Re: [9fans] arenas00: indexing 1455 clumps...
On Tue, Jul 21, 2009 at 7:20 PM, Corey wrote: > I was booted into my cpu/auth server's terminal; then pressed ctrl-p by > accident in a rio window; which caused the machine to immediately reboot - > and now it gets to particular point and (seemingly) hangs at: > > sync...2009/0722 02:04:58 arenas00: indexing 1544 clumps... > > I imagine it's got something to do with the filesystem/fossil? yes. it will finish but may take a little while. > Did this occur because I rebooted ( -p ), without doing a fshalt first? yes. > If so, is there a way I can disable or reassign this -p keybinding? yes. echo ctlpoff >/dev/consctl russ
Re: [9fans] p9p threadpin() / threadunpin() ?
On Wed, Jul 22, 2009 at 9:04 PM, Venkatesh Srinivas wrote: > I noticed that p9p has threadpin() and threadunpin() in its thread > library... they claim to make the current thread the only one runnable > in this proc. I'm failing to see the purpose of these... a thread is > not subject to preemptive scheduling, it can achieve the same effect > by not calling yield(), right? > Also, these two functions aren't in p9's libthread... is there any > reason why not (assuming those two have a purpose)? Yes and yes. Unfortunately, it is sometimes impossible to avoid calling yield. On Plan 9, the graphics library uses writes to /dev/draw and the kernel manages simultaneous access by multiple threads. In Plan 9 port, everything happens in user space and there are qlocks to help make things thread safe. Unfortunately the fact that the qlocks can reschedule inside a proc makes them different from a write system call. Rather than rewrite all the draw code to remove the assumption that /dev/draw writes do not reschedule, I made the simulation of /dev/draw also not reschedule. It is not a good approach in general, which is why the functions are undocumented. http://code.swtch.com/plan9port/src/tip/src/libdraw/drawclient.c#cl-189 Russ
Re: [9fans] fun proto bug
On Sat, Jul 25, 2009 at 9:29 AM, erik quanstrom wrote: > i apologize for not hunting this down, but i don't want to > get diverted from hunting other bugs right now. > > ; cat /tmp/allproto > + > ; disk/mk9660 -9cj -b bootdisk.img -p /tmp/allproto /tmp/9atom2.iso > warning: proto lists rc/bin/kill twice You don't say where you are running this command, but I bet a case-insensitive file system or file system protocol is involved. There should be rc/bin/Kill and rc/bin/kill but it sounds like both are appearing as lowercase kill when proto reads the rc/bin directory. The same goes for the troff dups. Russ
Re: [9fans] p9p vac troubles, possible fix and questions?
Fixed in http://code.swtch.com/plan9port/changeset/c9f799b3ad09/ Thanks.
Re: [9fans] how to fix: 'arena arenas00 creation time after last write time'
On Sun, Jul 26, 2009 at 6:03 PM, Corey wrote: > The following is being printed to the console non-stop: > err 2: arena arenas00 creation time after last write time > arena arenas00: header is out-of-date > Apparently my clock/date was set a day ahead when I installed the terminal. > > How do I correct the situation? You could comment out the print in the venti server, or make it only print once and then shut up. Russ
Re: [9fans] Using Acme as an external Editor
On Mon, Jul 27, 2009 at 11:06 AM, Tim Newsham wrote: >> Is there some idiom or method for using Acme as an external editor to some >> other program? Say I want to use it as the editor that is spawned when I do >> a CVS commit to a system; how would I do this, or can this even be done? I'm >> using plan9ports, but I don't know how much of this question relates to >> what. > > I was playing with this exact problem recently. There's an easy way to send > a file to acme for editing -- the plumber. There's a downside, it doesn't > wait for the editor to save or complete. So.. you could plumb the file and > then wait for a save to happen, somehow, or you can write another program > that forces a new acme window with the contents of the file and waits for it > to either Put or Del. I wrote a small program to do this recently (see the > thread: http://9fans.net/archive/2009/06/290) which was a bit hacky, but > worked. I solicited some feedback on some questions and got some good > advice from Russ (http://9fans.net/archive/2009/06/292) but havent yet gone > back and applied it. I don't think you need to be that fancy. Lorenzo Bolla already pointed out E in this thread, and it exists exactly for this purpose. http://swtch.com/plan9port/man/man1/sam.html (description of E is at the end) Russ
Re: [9fans] how to fix: 'arena arenas00 creation time after last write time'
I don't think we need to debate the exact semantics of time on Plan 9 in order to figure this out. It's easy to believe that the installer and the main distribution end up with different time settings, no matter what the exact details are. The right fix is probably to comment out the print in venti and move on, which you have already done. If you are feeling particularly motivated, you could contribute back the patch commenting out the print so that other people don't have the same problem. Russ
Re: [9fans] how to fix: 'arena arenas00 creation time after last write time'
On Tue, Jul 28, 2009 at 3:16 PM, erik quanstrom wrote: > ignoring little bugs is the path to ruin. That's why the print should just go away entirely. The code assumes that the time from one boot to the next only ever increases, which has been demonstrated not to be true. Maybe during one boot your clock is screwed up for one reason or another and you don't notice for a few days. Then when you fix it, venti prints messages ad infinitum? That's just broken behavior. It's not a question of time zones. Time zones don't matter. It's just that the clock was wrong before and later is correct--there are many reasons this might happen-- and venti shouldn't care. The time stamps, like the ones in a file system, are informational. It's okay if they're wrong. There's no need to print. Or should we continue to discuss tangents? Russ
Re: [9fans] how to fix: 'arena arenas00 creation time after last write time'
> The problem isn't confined to unnecessary warning messages > being printed. > > What about the 'arena arenas00: header is out-of-date' error, > and the subsequent re-indexing (on every reboot) which occurs > as a result of the condition? Despite the mention of "date" in the message, the logic behind that print is not time-sensitive. It's a different issue. How many clumps does it say it is indexing? How long does that take? It shouldn't be too long. Venti writes data blocks (clumps) to an append-only log. Then it does two more bookkeeping steps so it can find the data later. The first step is to update the block count in the arena header. The second step is to record an index entry for the block in the index disk and then update the indexed block count in the arena header. The data is committed once it is written to the log: the bookkeeping is just an optimization. The fact that you are getting the "out-of-date" print means that the first step has not happened for at least one block: venti looked ahead and found more data blocks than the header led it to expect. That's fine, it just means that venti was behind in its bookkeeping when you shut it down. (fshalt makes sure that the data is on disk; it doesn't wait around for the bookkeeping.) The next message you saw--indexing %d clumps--means that the second step hadn't happened for a perhaps larger number of blocks. Indexing here means loading information about the blocks into venti's in-memory cache, so that lookups for the blocks will succeed. If you leave the machine up long enough, venti will update the on-disk index slowly, in the background. If the pause at boot time due to this bookkeeping is bothering you, you can flush the current venti state to disk by running hget http://localhost:8000/flushdcache hget http://localhost:8000/flushicache# can take a while hget http://localhost:8000/flushdcache but replace localhost:8000 with your venti server's HTTP address (maybe that's the right one; I don't know). The fact that this is happening repeatedly suggests that fossil is trying to do a dump to venti but you are not leaving the machine up long enough that it can complete, so every time you reboot, it starts writing blocks to venti again, causing new indexing work that doesn't finish before you reboot again. If you want to end this cycle, the thing to do is let fossil finish its archive and let venti finish indexing it. If you run hget http://localhost:8000/storage one if the numbers is the total number of clumps written to the entire venti server. If you wait a minute and run it again and the number is growing, then fossil is writing to venti. Let it run until the number stops growing, and then wait for the venti flush above. > What I do know is that I'm having real and present issues with > venti, that are in some direct or indirect way related to at least > one or more of the following actors: > > bios/rtc clock > /env/timezone > /dev/rtc > aux/timesync Again, if you've commented out the "creation time" print, then your remaining issues are not clock-related. I think you're just rebooting more often than usual. Russ
Re: [9fans] 9p question
On Thu, Jul 30, 2009 at 8:28 AM, Venkatesh Srinivas wrote: > How come you can't TWalk along an open Fid? In the original 9P protocol, that didn't make sense, because walk always updated the fid it was starting from. If you open a fid and then walk it elsewhere, is it still open? Is that an implicit close? And the operation isn't needed by the Plan 9 kernel anyway, so out it goes. In the current 9P protocol, I think it would be fine to allow a walk to start at an open fid as long as newfid was being used to create a new fid. This would make it easy to implement fchdir on Unix. Russ
Re: [9fans] 9p question
> it would surely make it easier for unix implementations. i have had > plenty of issues with that in o9fs. > > but as yourself pointed out, what would that walk mean? as i also pointed out, there's no problem if the walk is creating a new fid. it would be unopened. russ
Re: [9fans] Kernel crash bug
calling vmemchr assumes that the memory isn't being changed by some other proc mapping the same page. if you find the NUL in one pass and then call strcpy or strlen on the pointer later, the other proc might have pulled the NUL in the interim. there is a function in the kernel called validnamedup that both validates a string argument and at the same time makes an in-kernel-memory copy. it's the easiest safe way to handle strings passed to the kernel. namec uses it and luckily almost every string pointer passed to the kernel ends up being interpreted by namec. exec is an exception. when i was working on 9vx, i rewrote exec to remove crashes like this one as well as a handful of other bugs. the code is at http://code.swtch.com/vx32/src/tip/src/9vx/a/sysproc.c#cl-220 and could easily be dropped back into plan 9. russ
Re: [9fans] Kernel crash bug
validname0 looks like it is trying to be too clever.
A better version of the first if statement would be:
if((ulong)name < KZERO) {
validaddr((ulong)name, 1, 0);
if(!dup)
print("warning: validname called from %lux with user
pointer", pc);
ename = vmemchr(name, 0, 1<<16);
} else
ename = memchr(name, 0, 1<<16);
Russ
[9fans] Plan 9 from Outer Space, August 20
http://www.ncm.com/Fathom/Comedy/RiffTrax.aspx Russ
Re: [9fans] vmware snarf problem
There is a protocol writeup at http://chitchat.at.infoseek.co.jp/vmware/backdoor.html Russ
Re: [9fans] p9p acme freezes when ctrl-f inside its mounted directory
On Tue, Aug 4, 2009 at 10:33 AM, Rudolf Sykora wrote: > I noticed that when running acme in plan9port and having its > directories mounted say on /mnt/acme, then if I try from within a win > window in the acme to auto-complete a directory name---I am in /mnt, I > type 'a' and hit the 'insert' key or ctrl-f, or I am anywhere inside > the acme filesystem---the program freezes (though, if I write it > myself, I can cd to the acme directory). The problem is that acme is basically a single operating system thread, and that operating system thread is trying to look in /mnt/acme. To serve that request, the kernel has posted a FUSE message to acme to handle, which acme will get around to just as soon as the system call in /mnt/acme finishes. Deadlock. This is not a problem on Plan 9 because acme does not put itself in its own name space. On Linux, where there is just one big name space, more care is necessary (and not implemented). Russ
Re: [9fans] renaming to an existing file
> How can I achieve the same result with 9P? You can't. (Redefine 9P.) Russ
Re: [9fans] A note on using E
> #!/bin/sh > if 9p stat plumb > /dev/null 2>&1 > then > exit > else > plumber > fi > > to ensure that the plumber is running. This works nicely for me, as I > can exit and restart acme, and the plumber continues running. When I > log out of this linux system, however, it appears that the plumber is not > killed, and the next time I log in and start acme, the script sees that > the plumber is still running and doesn't start it. Unfortunately, that > running plumber doesn't seem to be work right because when I click on a > URL in acme it doesn't get opened in my web browser. I have to kill and > restart the plumber to get this to work. The problem is that the old plumber does not have access to your new X desktop, so it cannot start a new firefox nor can it tell one running on the new desktop to do anything. The solution is to restart plumber always, perhaps in your .xinitrc. Russ
Re: [9fans] searchfs
> you need to read and write the same file descriptor. (i'm > not sure why i would use this instead of grep, even for http > queries.) <>[fd] is rc syntax for opening a file for r/w. > here's an example of opening fd 3 rw, then sending the > query into that fd and reading the results back: for interactive playing, it is easier to use % aux/rdwr /n/search/search > search=eat& ... though maybe the trailing newline would cause trouble. see /sys/src/cmd/ip/httpd/netlib_find.c for a real client. russ
Re: [9fans] 9base-3
On Fri, Aug 7, 2009 at 6:13 PM, Uriel wrote:
> Always get p9p from hg, the tarballs have been partially broken for
> ages and
Excuse me?
Instead of keeping that to yourself why not tell me so I can fix it?
I know many people who install from the tar file, though,
so I expect you're just whining instead of checking the facts,
as usual.
> always have problems being untared in some environments
Again, details?
FreeBSD:
holo=; hget http://swtch.com/plan9port/plan9port.tgz | gunzip | tar xf -
holo=; ls -lR plan9 | awk '/^-/ {s+=$5} END{print s}'
49413465
holo=;
Linux:
c2=; gunzip < plan9port.tgz | tar xf -
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
c2=; ls -lR plan9 | awk '/^-/ {s+=$5} END{print s}'
49413465
c2=;
OS X:
mini=; gunzip < plan9port.tgz | tar xf -
mini=; ls -lR plan9 | awk '/^-/ {s+=$5} END{print s}'
49342685
mini=;
The GNU tar warnings about SCHILY extensions don't count as
a problem: it's an inconsequential warning message.
The missing 70780 bytes on OS X are the files HI, HX, LH, RC, lH, and rH
from troff/font/devutf/charlib, which have been overwritten with differently
cased versions of the same files. It doesn't matter since basically
no one uses those special characters, and you'd have the same problem
using Hg or any other file program: the bug is in the file system, not
the extractor.
I'm plenty happy for people to use hg instead of the tar files--
I think that's good advice for the people who enjoy using
version control systems--but please don't go spreading
misinformation.
Thanks.
Russ
Re: [9fans] 9base-3
Thanks, but I'm happy with the current tar files. They are a working CVS checkout, so that people who use them can then use the recipes in cvs(1) [9 man cvs] to update their trees. The one you linked to is not a working anything checkout. I haven't touched the tar file generation in over a year so "work and trouble" is quite the exaggeration. I have changed the script that generates the tar files to use the Plan 9 tar. Now there will be no SCHILY.* extensions for GNU tar to whine about. Maybe that will kill off this myth. Russ
Re: [9fans] Unexpected 8c warning message
you are smarter than 8c. just put sd = nil above your loop. 8c isn't smart enough to know that the body of for(i=0; i<2; i++) because it does not make two copies of the i<2 test, so it cannot determine that the very first one is guaranteed to succeed. russ
Re: [9fans] Unexpected 8c warning message
This problem is uncomputable, so trying to
handle every case that comes up is problematic.
There has to be a line somewhere. Saying that
the compiler could figure out does not imply
that it must.
I think it's perfectly reasonable that a compiler,
when presented with a program like
int x;
for(___; ___; ___) {
x = ___;
___;
}
if(!x)
___;
should complain about a possible used-but-not-set
of x. As a person reading that code, I can't look at
the overall structure of the code and see that x is
obviously initialized at the if statement, unless I analyze
the various abstracted-away ___ pieces. And if one of
those changes, then there is now a real error.
SET is hard to use correctly and not portable.
You are better off with a simple assignment,
simpler than the one you used in your example:
just zero the variable before the loop.
int x;
x = 0;
for(___; ___; ___) {
x = ___;
___;
}
if(!x)
___;
Now at least the people reading the code can see
that x is initialized, for sure. It's very hard for me to
see how "x = 0" is a medicine worse than the disease.
I do agree that the "SD = SDList[0];" you had is not
a good solution, because it makes it look like that
value is important, but "SD = nil;" avoids that issue.
Alternately, since the if(!x) is really the continuation
of the last iteration of the loop, you could move it
inside the loop:
int x;
for(___; ___; ___) {
x = ___;
___;
if(last iteration && !x)
___;
}
which makes it clear to both people and compilers
that x is set before it is used.
It is not the compiler's job to enable you to be as
clever as possible. If this really matters to you and
you don't want the compiler warnings, you can
always turn them off.
Russ
Re: [9fans] bind vs. 9660srv
This is a kernel bug.
sysfile.c:/^read says
dir = c->qid.type&QTDIR;
if(dir && mountrockread(c, p, n, &nn)){
/* do nothing: mountrockread filled buffer */
}else{
if(dir && c->umh)
nn = unionread(c, p, n);
else
nn = devtab[c->type]->read(c, p, n, off);
}
if(dir)
nnn = mountfix(c, p, nn, n);
else
nnn = nn;
but should say (untested)
if(c->qid.type&QTDIR) {
if(mountrockread(c, p, n, &nn)) {
/* do nothing: mountrockread filled buffer */
} else if(c->umh) {
nn = unionread(c, p, n);
} else {
if(off != c->offset)
error(Edirseek);
nn = devtab[c->type]->read(c, p, n, c->devoffset);
}
nnn = mountfix(c, p, nn, n);
} else {
nn = devtab[c->type]->read(c, p, n, off);
nnn = nn;
}
I have separated out the various if(dir) tests into
one block, but more importantly the new code passes
c->devoffset to the directory read.
No one noticed before because most 9P2000 servers
assume they are being used correctly and implement
a simpler check: if offset == 0, seek to beginning,
otherwise continue where the last read left off.
Russ
Re: [9fans] bind vs. 9660srv
On Mon, Aug 10, 2009 at 11:27 AM, erik quanstrom wrote:
>> but should say (untested)
>
> s/un(tested)/\1
>
>> No one noticed before because most 9P2000 servers
>> assume they are being used correctly and implement
>> a simpler check: if offset == 0, seek to beginning,
>> otherwise continue where the last read left off.
>
> ken fs does so i'm still a bit puzzled.
Not the code I'm looking at
(/sys/src/cmd/cwfs/9p2.c)
start += n;
if(start < offset)
continue;
if(count < n){
putbuf(p1);
goto out1;
}
There's no check that you get
to start == offset before copying data in.
So if you passed in an offset that was
off by a few bytes, it would get rounded
to a real directory entry boundary.
Russ
