Re: [9fans] a bit OT, programming style question
2009/4/7 Corey : > Keyboard > bindings for example; why couldn't they be handled by a program that > just does keyboard bindings + line editing, and writes finalized lines > to the shell. Congratulations, you've perceived the difference between shell and terminal. A lot of people stuck in modern unix fail to notice this one... which is not that surprising considering the state of modern unix terminals (9term excepted - quiet Anothy :P). -sqweek
Re: [9fans] way OT but shocking none the less
Not really. Rackable Systems has for long been one of those things that were there but you never saw. And SGI's end was coming. When did they decommission IRIX? Wasn't it some years ago? I think Rackable Systems is going to focus on SGI's supercomputing background and boost their line with parallel supercomputers. Just wild guessing for fun. --On Monday, April 06, 2009 7:37 AM -0700 Benjamin Huntsman wrote: ...SGI... was purchased for just $25M by Rackable Systems I saw that. It's a sad day when such an icon of the computer industry gets bought by some company I've never heard of for a (relatively) piddly little sum...
Re: [9fans] a bit OT, programming style question
Keyboard bindings for example; why couldn't they be handled by a program that just does keyboard bindings + line editing, and writes finalized lines to the shell. Like... readline(3)? SEE ALSO The Gnu Readline Library, Brian Fox and Chet Ramey The Gnu History Library, Brian Fox and Chet Ramey bash(1) -- man readline --On Tuesday, April 07, 2009 3:53 PM +0800 sqweek wrote: 2009/4/7 Corey : Keyboard bindings for example; why couldn't they be handled by a program that just does keyboard bindings + line editing, and writes finalized lines to the shell. Congratulations, you've perceived the difference between shell and terminal. A lot of people stuck in modern unix fail to notice this one... which is not that surprising considering the state of modern unix terminals (9term excepted - quiet Anothy :P). -sqweek
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
On Mon, Apr 6, 2009 at 7:00 PM, maht wrote: > > SeaForth is dead already > > http://colorforth.com/vTPL.htm > > http://colorforth.com/S40.htm > These docs aren't dated. And I remember a lot of discussion about 1 - 2 years ago about the patent issues surrounding Chuck Moore's work. So I'm wondering if this info is outdated. The Forth Usernet group seems to indicate that these chips are fine and dandy. Robby
Re: [9fans] unvac bug
Well, I've checking out the code and I am really unable to fix the bug. It turns out that for some reason, VacDirEnum *vde inside unvac gets the wrong permissions for 2009/0311, since it writes it with 0555 instead of 0755, when starts to walk the file tree. I hope someone can fix this. Saludos 2009/3/11, hugo rivera : > hi there, > there is a strange bug in unvac from p9p. When you vac a file tree > with the -a option, to have something like 2009/0311/yourtree, and > then you unvac it with "unvac vacfile > 2009/0311/yourtree/thefileyouwant", unvac dies with a segmentation > fault. Apparently unvac creates the 2009 directory, but with r-xr-xr-x > permissions, so it is not able to write to it. You have to manually > create the 2009/0311 directory, with the right permissions, so unvac > is able to put your files there. Note that if you do not create the > 0311 directory inside 2009, then you have your segfault again, for the > same reason as before. But when you have both directories, you can > extract whatever you want without problems ;-) (really neat stuff, > venti and its friends). > Maybe I can send a patch for this, but I am not sure if my programming > skills are good enough to start sending code to plan 9. > Saludos > > -- > > Hugo > -- Hugo
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
Robert Raschke wrote: > On Mon, Apr 6, 2009 at 7:00 PM, maht wrote: >> >> SeaForth is dead already >> >> http://colorforth.com/vTPL.htm >> >> http://colorforth.com/S40.htm >> > > These docs aren't dated. And I remember a lot of discussion about 1 - > 2 years ago about the patent issues surrounding Chuck Moore's work. So > I'm wondering if this info is outdated. The Forth Usernet group seems > to indicate that these chips are fine and dandy. > For whatever it's worth: a...@berk:~$ wget -S --spider http://colorforth.com/S40.htm Spider mode enabled. Check if remote file exists. --2009-04-07 11:47:19-- http://colorforth.com/S40.htm Resolving colorforth.com... 207.217.125.50 Connecting to colorforth.com|207.217.125.50|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Tue, 07 Apr 2009 10:47:20 GMT Server: Apache Last-Modified: Mon, 06 Apr 2009 19:52:50 GMT < ETag: "2e6982-849-49da5d92" Accept-Ranges: bytes Content-Length: 2121 Keep-Alive: timeout=10, max=100 Connection: Keep-Alive Content-Type: text/html Length: 2121 (2.1K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. a...@berk:~$ wget -S --spider http://colorforth.com/vTPL.htm Spider mode enabled. Check if remote file exists. --2009-04-07 11:47:21-- http://colorforth.com/vTPL.htm Resolving colorforth.com... 207.217.125.50 Connecting to colorforth.com|207.217.125.50|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Tue, 07 Apr 2009 10:47:21 GMT Server: Apache Last-Modified: Mon, 06 Apr 2009 19:48:29 GMT <--- ETag: "172cd95-688-49da5c8d" Accept-Ranges: bytes Content-Length: 1672 Keep-Alive: timeout=10, max=100 Connection: Keep-Alive Content-Type: text/html Length: 1672 (1.6K) [text/html] Remote file exists and could contain further links, but recursion is disabled -- not retrieving. Cheers -- Alexander Clouter .sigmonster says: You will receive a legacy which will place you above want.
[9fans] self inflicted gunshot wound
like kutner, the plumber decided to off itself for seemingly inscrutable reasons this morning. the abort condition does not appear to hold: if(t > s+n) abort(); since 0x3a497 < 0x3a430+0x93 and also a!= nil, as would be required. 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. ideas? - erik 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 plumbpack(m=0x3c710,np=0x3e7c4)+0x31 /sys/src/libplumb/mesg.c:148 ndata=0x10 attr=0x6523 n=0x1430 buf=0x0 p=0x3a330 drainqueue(d=0x1b288)+0x84 /sys/src/cmd/plumb/fsys.c:393 prevs=0x0 nexts=0x3eb30 prevr=0x0 i=0x0 r=0x3a330 s=0x3e7b0 n=0x103cb fsysread(buf=0x28f50,f=0x3c210,t=0x3a1f0)+0x1ed /sys/src/cmd/plumb/fsys.c:811 o=0x17 e=0x0 clock=0x3a1f0 b=0x3c210 i=0x13 d=0x1a7f n=0x1f494 fsysproc()+0x186 /sys/src/cmd/plumb/fsys.c:262 t=0x3a1f0 buf=0x28f50 n=0x17 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 acid: stacks() p=(Proc)0x3f090pid 4505 Sched t=(Thread)0x40f10Rendez /sys/src/cmd/plumb/fsys.c:295 newfid _threadrendezvous(tag=0x1939c,val=0x1)+0x11d /sys/src/libthread/rendez.c:56 qlock(q=0x1f448)+0x6f /sys/src/libc/9sys/qlock.c:74 newfid(fid=0x30d)+0x10 /sys/src/cmd/plumb/fsys.c:295 fsysproc()+0x165 /sys/src/cmd/plumb/fsys.c:261 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 p=(Proc)0x3c750pid 4506 Sched t=(Thread)0x3be30Rendez /sys/src/cmd/plumb/fsys.c:529 dispose _threadrendezvous(tag=0x19390,val=0x1)+0x11d /sys/src/libthread/rendez.c:56 qlock(q=0x1f448)+0x6f /sys/src/libc/9sys/qlock.c:74 dispose(rs=0x0,m=0x39a70,e=0x0,t=0x28bc0,buf=0x68ff0)+0x10 /sys/src/cmd/plumb/fsys.c:529 fsyswrite(buf=0x68ff0,f=0x3c270,t=0x28bc0)+0x1ef /sys/src/cmd/plumb/fsys.c:898 fsysproc()+0x186 /sys/src/cmd/plumb/fsys.c:262 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 p=(Proc)0x39010pid 16359 Running t=(Thread)0x287a0Running/sys/src/libplumb/mesg.c:125 plumbpackattr abort()+0x0 /sys/src/libc/9sys/abort.c:6 plumbpackattr(attr=0x28b00)+0x126 /sys/src/libplumb/mesg.c:125 plumbpack(m=0x3c710,np=0x3e7c4)+0x31 /sys/src/libplumb/mesg.c:148 drainqueue(d=0x1b288)+0x84 /sys/src/cmd/plumb/fsys.c:393 fsysread(buf=0x28f50,f=0x3c210,t=0x3a1f0)+0x1ed /sys/src/cmd/plumb/fsys.c:811 fsysproc()+0x186 /sys/src/cmd/plumb/fsys.c:262 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0 p=(Proc)0x6b030pid 83108 Running t=(Thread)0x39f50Running/sys/src/cmd/plumb/fsys.c:241 fsysproc pread()+0x7 /sys/src/libc/9syscall/pread.s:5 read(fd=0x6,buf=0x6d9f0,n=0x4)+0x2f /sys/src/libc/9sys/read.c:7 readn(n=0x4,av=0x6d9f0,f=0x6)+0x3a /sys/src/libc/port/readn.c:13 read9pmsg(abuf=0x6d9f0,fd=0x6,n=0x2018)+0x24 /sys/src/libc/9sys/read9pmsg.c:14 fsysproc()+0x74 /sys/src/cmd/plumb/fsys.c:241 launcher386(arg=0x0,f=0x17f6)+0x10 /sys/src/libthread/386.c:10 0xfefefefe ?file?:0
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
These docs aren't dated. they appeared in the last week or so, before that was a page saying TPL pulled funding and sacked Moore
Re: [9fans] a bit OT, programming style question
2009/4/7 Eris Discordia : >>> Keyboard >>> bindings for example; why couldn't they be handled by a program that >>> just does keyboard bindings + line editing, and writes finalized lines >>> to the shell. > > Like... readline(3)? No. -sqweek
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
On Tue, Apr 7, 2009 at 3:24 PM, maht wrote: > >> These docs aren't dated. > > they appeared in the last week or so, before that was a page saying TPL > pulled funding and sacked Moore > Catching up with my online reading and the Forth group is indeed full of this since the weekend. It is just weird, all very deja vu. The previous generation of Moore's designs went through a similar quagmire to nowhere. Robby
Re: [9fans] Fwd: New Chip (SEAforth 40C18) - New Challenge
It is just weird, all very deja vu. The previous generation of Moore's designs went through a similar quagmire to nowhere. Robby poor man, how stressful is that !
Re: [9fans] a bit OT, programming style question
On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia wrote: > > Like... readline(3)? one hopes not. ron
Re: [9fans] a bit OT, programming style question
you could break out re expansion into a separate program :-) ron
Re: [9fans] a bit OT, programming style question
On Tue, 2009-04-07 at 08:08 -0700, ron minnich wrote: > you could break out re expansion into a separate program :-) > > ron > Exactly, and the end user can choose to have a re or glob expansion program, rather than having to muck up the shell code with different flags or whatever.
Re: [9fans] a bit OT, programming style question
On Tue, Apr 7, 2009 at 9:05 AM, Corey wrote: > On Tue, 2009-04-07 at 08:08 -0700, ron minnich wrote: >> you could break out re expansion into a separate program :-) >> >> ron >> > > Exactly, and the end user can choose to have a re or glob expansion > program, rather than having to muck up the shell code with different > flags or whatever. somebody is going to jump in very soon and tell us why this is funny :-) ron
Re: [9fans] a bit OT, programming style question
I see. But seriously, readline does handle bindings and line editing for bash. Except it's a function instead of a program and you think it's a bad idea. --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek wrote: 2009/4/7 Eris Discordia : Keyboard bindings for example; why couldn't they be handled by a program that just does keyboard bindings + line editing, and writes finalized lines to the shell. Like... readline(3)? No. -sqweek --On Tuesday, April 07, 2009 8:09 AM -0700 ron minnich wrote: On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia wrote: Like... readline(3)? one hopes not. ron
Re: [9fans] double click selects a word
In omero double click does the same, and triple is more hungry. You could try that modifying your local system El 06/04/2009, a las 16:55, fors...@terzarima.net escribió: Double clicking e.g. on 'text.txt' only selects 'text' or 'txt', while one usually wants the whole. The same with absolute paths like '/usr/ruda/lib/profile', etc. In linux a double-click usually highlights the whole and usually this is what I want. one man's `usually' is another man's `never'. it's one reason i use 9term on linux. we probably both say ``what were they thinking??'' about contrary effects. [/mail/box/nemo/msgs/200904/37680]
Re: [9fans] a bit OT, programming style question
> > Exactly, and the end user can choose to have a re or glob expansion > > program, rather than having to muck up the shell code with different > > flags or whatever. > > somebody is going to jump in very soon and tell us why this is funny :-) i promised i wouldn't, - erik
Re: [9fans] a bit OT, programming style question
On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia wrote: > I see. But seriously, readline does handle bindings and line editing for > bash. Except it's a function instead of a program and you think it's a bad > idea. The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. > > --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek wrote: > >> 2009/4/7 Eris Discordia : > > Keyboard > bindings for example; why couldn't they be handled by a program that > just does keyboard bindings + line editing, and writes finalized lines > to the shell. >>> >>> Like... readline(3)? >> >> No. >> -sqweek >> > > > > --On Tuesday, April 07, 2009 8:09 AM -0700 ron minnich > wrote: > >> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia >> wrote: >> >>> >>> Like... readline(3)? >> >> one hopes not. >> >> ron >> > > > > > >
[9fans] yet another cheapo mips board
Can't remember if this one came up: $59. http://www.ubnt.com/products/rs.php ron
Re: [9fans] yet another cheapo mips board
2009/4/7 ron minnich : > Can't remember if this one came up: > $59. http://www.ubnt.com/products/rs.php Where do you find it for $59? Cheapest I can find from their page is $69. --dho
Re: [9fans] a bit OT, programming style question
Exactly, and the end user can choose to have a re or glob expansion program, rather than having to muck up the shell code with different flags or whatever. somebody is going to jump in very soon and tell us why this is funny :-) i promised i wouldn't, Well someone's gotta tell these prepubescents ... "Because the V6 shell did it, that's why.".
Re: [9fans] a bit OT, programming style question
> Well someone's gotta tell these prepubescents ... > > "Because the V6 shell did it, that's why.". ooh. ooh. i know what you're going to say next: if should be an external program. - erik
Re: [9fans] yet another cheapo mips board
On Tue, Apr 7, 2009 at 2:07 PM, Devon H. O'Dell wrote: > 2009/4/7 ron minnich : >> Can't remember if this one came up: >> $59. http://www.ubnt.com/products/rs.php > > Where do you find it for $59? Cheapest I can find from their page is $69. > yeah. I can't find that page again. Well, with this price going up at this rate ($10 in just a few hours) better order now! ron
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] a bit OT, programming style question
The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. A bad implementation is not a bad design. And, in fact, the badness of the implementation is even questionable in the light of bash's normal behavior or the working .inputrc files I've been using for some time. Anyway, thanks for the info. --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro" wrote: On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia wrote: I see. But seriously, readline does handle bindings and line editing for bash. Except it's a function instead of a program and you think it's a bad idea. The man page *does* say it's too big and slow. So does the bash manpage. And getting readline to do anything sane is about as fun as screwing around with a terminfo file. --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek wrote: 2009/4/7 Eris Discordia : Keyboard bindings for example; why couldn't they be handled by a program that just does keyboard bindings + line editing, and writes finalized lines to the shell. Like... readline(3)? No. -sqweek --On Tuesday, April 07, 2009 8:09 AM -0700 ron minnich wrote: On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia wrote: Like... readline(3)? one hopes not. ron
Re: [9fans] a bit OT, programming style question
> A bad implementation is not a bad design. neither is stink an outhouse, but often they keep company. - erik
Re: [9fans] self inflicted gunshot wound
On Tue Apr 7 21:50:14 EDT 2009, r...@swtch.com wrote: > > 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. acid: *(*plumbpackattr:s\s) filetype=mail sender=x...@.xxx length=8749 mailtype=delete date='Sun Mar4de7153cecd4a9b45aead1clfs digest=aff98fb56526d94ab768adbc93d12d989a11ed53 hmmm. i think you might be on to something after all. maybe it was fratricide. > 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. 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. > 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. unfortunately, i was not writing the rules file, that i know of. - erik
Re: [9fans] a bit OT, programming style question
On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia wrote: >> The man page *does* say it's too big and slow. So does the bash >> manpage. And getting readline to do anything sane is about as fun as >> screwing around with a terminfo file. > > A bad implementation is not a bad design. And, in fact, the badness of the > implementation is even questionable in the light of bash's normal behavior > or the working .inputrc files I've been using for some time. Behavior is not indicative of good design. It just means that the bandaids heaped upon bash (and X11, and...) make it work acceptably. Try env | wc -l in bash. Now tell me why that value is so big. > > Anyway, thanks for the info. > > --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro" > wrote: > >> On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia >> wrote: >>> >>> I see. But seriously, readline does handle bindings and line editing for >>> bash. Except it's a function instead of a program and you think it's a >>> bad idea. >> >> The man page *does* say it's too big and slow. So does the bash >> manpage. And getting readline to do anything sane is about as fun as >> screwing around with a terminfo file. >> >>> >>> --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek >>> wrote: >>> 2009/4/7 Eris Discordia : >>> >>> Keyboard >>> bindings for example; why couldn't they be handled by a program that >>> just does keyboard bindings + line editing, and writes finalized >>> lines to the shell. > > Like... readline(3)? No. -sqweek >>> >>> >>> >>> --On Tuesday, April 07, 2009 8:09 AM -0700 ron minnich >>> wrote: >>> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia wrote: > > Like... readline(3)? one hopes not. ron >>> >>> >>> >>> >>> >>> >> > > > > > >
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] self inflicted gunshot wound
> i would put a lock around the use of attrbuf > in both plumbpackattr and plumbunpackattr. > > russ why not just use malloc? - erik
[9fans] for rsc -- mail failure. sorry.
Your request ``smtp /net.alt/tcp!swtch.com rsc '' failed (code smtp 89792: Permanent Failure). The symptom was: Tue Apr 7 23:47:42 EDT 2009 connect to /net.alt/tcp!swtch.com: 550 relaying denied - erik
