[9fans] new usb stack and implicit timeouts
from the manpage: For control, bulk, and isochronous transfers, there is an implicit timeout performed by the kernel and it is not nec- essary for applications to place their own timers. For interrupt transfers, the kernel will not time out any opera- tion. souldnt the application / userspace driver know better than some random choosen timeout in the kernel driver? also, this has not been taken into account for the new usb/ether. for now i'll just compare the errstr and try again, but this implicit timeout stuff just smells too smart for me. -- cinap
Re: [9fans] new usb stack and implicit timeouts
The only justification I can see is to disconnect to stuff that's been unplugged or misbehaves. In your case that's not true. brucee On Sun, Jul 19, 2009 at 5:16 PM, cinap_len...@gmx.de wrote: from the manpage: For control, bulk, and isochronous transfers, there is an implicit timeout performed by the kernel and it is not nec- essary for applications to place their own timers. For interrupt transfers, the kernel will not time out any opera- tion. souldnt the application / userspace driver know better than some random choosen timeout in the kernel driver? also, this has not been taken into account for the new usb/ether. for now i'll just compare the errstr and try again, but this implicit timeout stuff just smells too smart for me. -- cinap
Re: [9fans] new usb stack and implicit timeouts
pulling the device gets me a crc/timeout error, not a request timed out. but i'm not sure if this is always the case though. the driver should not artificially generate errors in my opinion even if it would be convinient for some userspace drivers to have it. those who need a timeout should choose ther own value depending on what they are doing. -- cinap ---BeginMessage--- The only justification I can see is to disconnect to stuff that's been unplugged or misbehaves. In your case that's not true. brucee On Sun, Jul 19, 2009 at 5:16 PM, cinap_len...@gmx.de wrote: from the manpage: For control, bulk, and isochronous transfers, there is an implicit timeout performed by the kernel and it is not nec- essary for applications to place their own timers. For interrupt transfers, the kernel will not time out any opera- tion. souldnt the application / userspace driver know better than some random choosen timeout in the kernel driver? also, this has not been taken into account for the new usb/ether. for now i'll just compare the errstr and try again, but this implicit timeout stuff just smells too smart for me. -- cinap ---End Message---
Re: [9fans] new usb stack and implicit timeouts
THere are some disks that do not respond to the controller after they crash. Also, RPCs carrying ctl requests to the devices may not respond either in some devices. I thought it was for sure an error when control and bulk requests took more than a while. Right now I´m not so sure regarding bulk transfers, but I still think it´s a good idea to timeout in the kernel control requests. pulling out is a different thing, as you say. ether requires more work, agree. On Sun, Jul 19, 2009 at 9:54 AM, cinap_len...@gmx.de wrote: pulling the device gets me a crc/timeout error, not a request timed out. but i'm not sure if this is always the case though. the driver should not artificially generate errors in my opinion even if it would be convinient for some userspace drivers to have it. those who need a timeout should choose ther own value depending on what they are doing. -- cinap -- Forwarded message -- From: Bruce Ellis bruce.el...@gmail.com To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net Date: Sun, 19 Jul 2009 17:21:16 +1000 Subject: Re: [9fans] new usb stack and implicit timeouts The only justification I can see is to disconnect to stuff that's been unplugged or misbehaves. In your case that's not true. brucee On Sun, Jul 19, 2009 at 5:16 PM, cinap_len...@gmx.de wrote: from the manpage: For control, bulk, and isochronous transfers, there is an implicit timeout performed by the kernel and it is not nec- essary for applications to place their own timers. For interrupt transfers, the kernel will not time out any opera- tion. souldnt the application / userspace driver know better than some random choosen timeout in the kernel driver? also, this has not been taken into account for the new usb/ether. for now i'll just compare the errstr and try again, but this implicit timeout stuff just smells too smart for me. -- cinap
Re: [9fans] i/o on a hangup channel asymmetry
perhaps i've been asleep at the swtch, but i don't recall seing writes on closed channels terminate programs with a note. sys: write on closed pipe mainly to kill off a pipeline when the thing at the end has finished. i think that might be the only instance where a note is used.
Re: [9fans] new usb stack and implicit timeouts
THere are some disks that do not respond to the controller after they crash. Also, RPCs carrying ctl requests to the devices may not respond either in some devices. I thought it was for sure an error when control and bulk requests took more than a while. Bulk pipes are not always used in a request-response manner -- they are just pipes. For many device classes (like ether or serial), a bulk read may need to wait an arbitrary amount of time until the other end has something to send. Have you seen anything in the USB spec which indicates a timeout for reading from a bulk pipe is appropriate?
Re: [9fans] new usb stack and implicit timeouts
disconnecting a usb device should result (eventually) in a suitable status on the relevant hub, and thus shouldn't require a timeout to get an error back to the user. devices that don't respond because they are in a bad state can be unplugged (if removeable). built-in devices on built-in hubs that get into a bad state probably need a usb or system reset, but some higher-level application (or human) timeout can interrupt a too-long delayed request. so far, i'd argue that a per-request timeout wasn't needed.
Re: [9fans] new usb stack and implicit timeouts
There's already a general way to time out any read/write operation alarm() and notify(). Why add a special case option for one particular type of file? I would say just remove it. You're right. I'll do so.
Re: [9fans] new usb stack and implicit timeouts
I think it's better to remove the timeout from bulk endpoints (perhaps by making it optional) There's already a general way to time out any read/write operation alarm() and notify(). Why add a special case option for one particular type of file? I would say just remove it. I strongly argue in favor of in-kernel ctl timeouts. Yes, the control endpoint has a well-defined RPC protocol and lack of response is always an error.
Re: [9fans] Question about Plan9 project
On Sat, 18 Jul 2009 22:40:14 +0200 Adriano Verardo a.vera...@tecmav.com wrote: Unbelievable but true, a driver (or a patch to a driver or whatever else) done by an italian is not considered as good as the stuff from the original site. It is a psychological problem I have often to face with. Open-source newbies often display the same problem, not just Italians at all. ;) It's a widely-promoted attitude that stuff which does not come from The Official Source can't be right. There are some facts behind the view, but overall it's a bad leap of logic. What it is is good for established business. -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] new usb stack and implicit timeouts
On Sun Jul 19 07:53:33 EDT 2009, 9f...@hamnavoe.com wrote: I think it's better to remove the timeout from bulk endpoints (perhaps by making it optional) There's already a general way to time out any read/write operation alarm() and notify(). Why add a special case option for one particular type of file? I would say just remove it. i'm confliced on this one. i want to agree with you, but have recient memory of uncooperative devices. and i would hate to limit the functionality of usb because we're trying to make things too simple. i'm not up-to-speed on usb. aren't there device types that take timeouts in their requests? isn't it easier to set up time timeout at the beginning? are there devices that if given a timeout will give their best available data when the timeout expires? sd doesn't deal with this problem. for example, currently most of the sd devices (orion is an exception) are uninterruptable. and you get whatever timeout you get. the sticky bit is that scsi and ata devices implement timeouts on the devices. these might not always be appropriate and you can't depend on anything. i have drives that vary from 53000s default timeouts to 2s default r/w timeouts. if you need a longer timeout than the disk or driver wants, you can't specify that with an alarm(2). and if you want a shorter one, aborting commands can take several seconds with sata devices. - erik
Re: [9fans] new usb stack and implicit timeouts
sd doesn't deal with this problem. for example, currently most of the sd devices (orion is an exception) are uninterruptable. and you get whatever timeout you get. the sticky bit is that scsi and ata devices implement timeouts on the devices. these might not always be appropriate and you can't depend on anything. i have drives that vary from 53000s default timeouts to 2s default r/w timeouts. if you need a longer timeout than the disk or driver wants, you can't specify that with an alarm(2). and if you want a shorter one, aborting commands can take several seconds with sata devices. sorry. that wasn't clear. i was talking about the raw file. - erik
Re: [9fans] new usb stack and implicit timeouts
aren't there device types that take timeouts in their requests? There might be, but if so, that's the business of the device's own driver, not the usb driver. isn't it easier to set up time timeout at the beginning? Not if you use normal read/write to talk to usb endpoints (which seems to me a Good Thing). Normal read/write system call doesn't have a timeout argument. are there devices that if given a timeout will give their best available data when the timeout expires? Again, if so, that's for the device's driver to set up and deal with, not the usb driver.
Re: [9fans] new usb stack and implicit timeouts
that's what I understood. In any case I'll run the code through all devices I have before sending any usb patch. I'm still not sure that some disks currently working won't cease working if they do their own timeouts. I just want to be sure. I placed timeouts there only when I found uncooperative devices, in practice. In theory, not even ctl timeouts are needed. (I should get crc/timeout errors even in those cases according to the std). but I have learned the hard way not to trust any usb std. On Sun, Jul 19, 2009 at 4:32 PM, erik quanstromquans...@quanstro.net wrote: isn't it easier to set up time timeout at the beginning? Not if you use normal read/write to talk to usb endpoints (which seems to me a Good Thing). Normal read/write system call doesn't have a timeout argument. do you mean normal read/write vs. an rpc protocol, say, like /dev/sdXX/raw? - erik
Re: [9fans] new usb stack and implicit timeouts
Normal read/write system call doesn't have a timeout argument. do you mean normal read/write vs. an rpc protocol, say, like /dev/sdXX/raw? No, I meant normal read/write vs more complicated things like select() in other operating systems.
Re: [9fans] new usb stack and implicit timeouts
On Sun, Jul 19, 2009 at 5:46 PM, cinap_len...@gmx.de wrote: http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket IIRC, I think the host controller is responsible for timing out requests sent to the device (I refer to setup packets), but my uchi does not. In any case, I don't think anyone wants to remove timeouts from ctl requests.
Re: [9fans] dcp - a deep copy script, better than dircp
On Sun Jul 19 12:26:24 EDT 2009, eeke...@fastmail.fm wrote: I was never satisfied with dircp. It's practice of copying the contents of one directory into another seemed limiting at best, obstructive at worst. The recursive copy options of Gnu cp seemed much more elegant(!), preserving the usual option syntax of cp and merely extending it slightly to include directories. see mkfs(8). i keep /tmp/allproto around with the contents of '+'. though i can't remember the last time i used it. - erik
Re: [9fans] dcp - a deep copy script, better than dircp
{echo +}
works just fine.
On Sun, Jul 19, 2009 at 8:16 PM, Richard Miller9f...@hamnavoe.com wrote:
i keep /tmp/allproto around with the contents of '+'.
There's also one in /sys/lib/sysconfig/proto/allproto,
but that takes longer to type.
Re: [9fans] i/o on a hangup channel asymmetry
On Jul 18, 2009, at 6:06 PM, erik quanstrom wrote:
On Sat Jul 18 14:41:02 EDT 2009, r...@sun.com wrote:
In the mom, why sky is blue department, here's a silly question:
is there any good reason that read(2) on a hangup channel returns
an error, while write(2) on a hangup channel terminates an
application
(by generating a note, of course, which can be ignored, but still)?
hmm. from a quick read of port/sysfile.c, i think the precise
behavior
might depend on the underlying device. if devtab[m-c-type]-bread/
bwrite
are (ultimately) based on qbread and qbwrite, i read qio as saying
that neither should
generate a note.
perhaps i've been asleep at the swtch, but i don't recall seing writes
on closed channels terminate programs with a note.
Observe:
cpu% cat test2.c
#include u.h
#include libc.h
#include stdio.h
void notary(void *v, char* s)
{
fprintf(stderr, NOTE: %s\n, s);
noted(NCONT);
}
int main()
{
notify(notary);
while (1) {
fprintf(stderr, %d\n, write(1, roman, 5));
sleep(5000);
}
return 0;
}
cpu% 8c test2.c
cpu% 8l test2.8
cpu% { ./8.out | cat } { sleep 10 ; slay cat | rc }
5
roman5
romanNOTE: sys: write on closed pipe pc=0x1525
-1
NOTE: sys: write on closed pipe pc=0x1525
-1
NOTE: sys: write on closed pipe pc=0x1525
-1
Thanks,
Roman.
Re: [9fans] i/o on a hangup channel asymmetry
Observe:
also observe (as ron noted) this happens mostly on
pipes. this would tend to cause pipes to shutdown
from right to left.
; 8c -FVTw roman.c 8l -o roman roman.8
; {roman | dd /dev/null} sleep 7; slay dd|rc
write good
write good
; note: sys: write on closed pipe pc=0x270a
write: i/o on hungup channel
; roman roman.out sleep 7; rm roman.out
write good
write good
; write: phase error -- directory entry not allocated
---
#include u.h
#include libc.h
void
notary(void*, char *s)
{
fprint(2, note: %s\n, s);
noted(NCONT);
}
void
main(void)
{
notify(notary);
for(;;){
if(write(1, roman, 5) != 5){
fprint(2, write: %r\n);
exits(write);
}
fprint(2, write good\n);
sleep(5000);
}
}
Re: [9fans] i/o on a hangup channel asymmetry
On Jul 19, 2009, at 2:30 AM, Charles Forsyth wrote: perhaps i've been asleep at the swtch, but i don't recall seing writes on closed channels terminate programs with a note. sys: write on closed pipe mainly to kill off a pipeline when the thing at the end has finished. i think that might be the only instance where a note is used. I had considered this theory. And it definitely explains why such a behavior would be beneficial for the pipelined jobs. What makes me unhappy, though, is that for things that are *not* connected to the pipe, but rather to a different kind of channel, it makes things more difficult without any clear benefit. Even for the pipelined case -- consider what happens when the thing at the beginning exits: the next consumer has to be aware of EOF condition first (and if it skips over EOF of the read returning -1). The consumers are offered a chance to shutting down gracefully, where the producers are not. Why inequality? Thanks, Roman.
Re: [9fans] i/o on a hangup channel asymmetry
On Sun, Jul 19, 2009 at 10:30:41AM +0100, Charles Forsyth wrote: perhaps i've been asleep at the swtch, but i don't recall seing writes on closed channels terminate programs with a note. sys: write on closed pipe mainly to kill off a pipeline when the thing at the end has finished. i think that might be the only instance where a note is used. not for network connections? that's what happens on unix at least, eg: A SIGPIPE signal is raised if a process sends on a broken stream; this causes naive processes, which do not handle the signal, to exit. and because of that, on hosted inferno an exception is raised on sigpipe. with the light use of threads, which are sometimes used to respond on a limbo channel after completion of a job, that can be tricky (if you're not aware of it; i usually forget to consider the case). mjl
[9fans] first timer - editing plan9.ini
Ok, so I have my fossil+venti and hopefully soon-to-be cpu and auth-server booted up for the first time, and I'm in rio as user glenda. I'm continuing to follow the docs, which is prompting me to edit plan9.ini for various things. sam is completely opaque to the uninitiated. (I'm a mere vi fanatic) Before I go into sitting down and learning sam, it would be nice to simply be able get the machine running in a minimally satisfactory way, i.e.: network online, display running at reasonable depth, venti finished, and auth-serv working. Can someone give me just the bare minimal sam command/info that I need to: edit a couple lines close and save properly ... better yet: is there a simple/minimal editor that doesn't require learning a command language to begin using it first? I began by beginning to read through sam_tut.pdf, and I look forward to gaining proficiency with it... but not at this moment - I just want to get my new plan9 box running so I can access it remotely. As it is, I'm guessing I'm just going to hose my plan9.ini if I try editing it before I'm well familiar with sam... THanks!
Re: [9fans] first timer - editing plan9.ini
acme
Re: [9fans] first timer - editing plan9.ini
The few minutes spent learning ed(1) will be well repaid. You'll be one of the smartest guys on your block. iPhone email On Jul 19, 2009, at 6:51 PM, Corey co...@bitworthy.net wrote: Ok, so I have my fossil+venti and hopefully soon-to-be cpu and auth- server booted up for the first time, and I'm in rio as user glenda. I'm continuing to follow the docs, which is prompting me to edit plan9.ini for various things. sam is completely opaque to the uninitiated. (I'm a mere vi fanatic) Before I go into sitting down and learning sam, it would be nice to simply be able get the machine running in a minimally satisfactory way, i.e.: network online, display running at reasonable depth, venti finished, and auth-serv working. Can someone give me just the bare minimal sam command/info that I need to: edit a couple lines close and save properly ... better yet: is there a simple/minimal editor that doesn't require learning a command language to begin using it first? I began by beginning to read through sam_tut.pdf, and I look forward to gaining proficiency with it... but not at this moment - I just want to get my new plan9 box running so I can access it remotely. As it is, I'm guessing I'm just going to hose my plan9.ini if I try editing it before I'm well familiar with sam... THanks!
Re: [9fans] first timer - editing plan9.ini
On Sun, Jul 19, 2009 at 3:51 PM, Coreyco...@bitworthy.net wrote: Ok, so I have my fossil+venti and hopefully soon-to-be cpu and auth-server booted up for the first time, and I'm in rio as user glenda. I'm continuing to follow the docs, which is prompting me to edit plan9.ini for various things. sam is completely opaque to the uninitiated. (I'm a mere vi fanatic) Before I go into sitting down and learning sam, it would be nice to simply be able get the machine running in a minimally satisfactory way, i.e.: network online, display running at reasonable depth, venti finished, and auth-serv working. Can someone give me just the bare minimal sam command/info that I need to: edit a couple lines close and save properly ... better yet: is there a simple/minimal editor that doesn't require learning a command language to begin using it first? I began by beginning to read through sam_tut.pdf, and I look forward to gaining proficiency with it... but not at this moment - I just want to get my new plan9 box running so I can access it remotely. As it is, I'm guessing I'm just going to hose my plan9.ini if I try editing it before I'm well familiar with sam... THanks! You can use acme if you want. Otherwise: % 9fat: % sam /n/9fat/plan9.ini right click and select the filename, then midclick in the white area of the sam window. This should bring up the file. Make your changes, then click in the light blue part of the sam window. Type 'w' and hit enter, then type 'q' and hit enter. This should write and quit. You can basically treat sam like ed with windows, but there are more complex commands available too. Myself, I usually use acme. John -- I've tried programming Ruby on Rails, following TechCrunch in my RSS reader, and drinking absinthe. It doesn't work. I'm going back to C, Hunter S. Thompson, and cheap whiskey. -- Ted Dziuba
Re: [9fans] first timer - editing plan9.ini
On Sunday 19 July 2009 16:04:05 Brantley Coile wrote: The few minutes spent learning ed(1) will be well repaid. You'll be one of the smartest guys on your block. Yes, however I simply want to put off that learning, from: _right_this_moment_, to: _after_my_box_is_online_.
Re: [9fans] first timer - editing plan9.ini
On Sunday 19 July 2009 16:02:20 John Floren wrote: On Sun, Jul 19, 2009 at 3:51 PM, Coreyco...@bitworthy.net wrote: snip Can someone give me just the bare minimal sam command/info that I need to: edit a couple lines close and save properly You can use acme if you want. That was my first effort (though it suffered similar issue: must acclimate to acme before you can configure your new installation) - however, when I tried to traverse /n/9fat/plan9.ini, acme complained that there was no such file; so, being completely new to plan 9, my progress at that point came to a complete standstill. Otherwise: % 9fat: % sam /n/9fat/plan9.ini right click and select the filename, then midclick in the white area of the sam window. This should bring up the file. Make your changes, then click in the light blue part of the sam window. Type 'w' and hit enter, then type 'q' and hit enter. This should write and quit. Thanks - I'll try this. Another quick question: Just to be safe, I would like to copy the org plan9.ini before I try to modify it; so if I hose it, I can move it back; how would I do this? Cheers
Re: [9fans] first timer - editing plan9.ini
On Sun, Jul 19, 2009 at 4:19 PM, Coreyco...@bitworthy.net wrote: On Sunday 19 July 2009 16:02:20 John Floren wrote: On Sun, Jul 19, 2009 at 3:51 PM, Coreyco...@bitworthy.net wrote: snip Can someone give me just the bare minimal sam command/info that I need to: edit a couple lines close and save properly You can use acme if you want. That was my first effort (though it suffered similar issue: must acclimate to acme before you can configure your new installation) - however, when I tried to traverse /n/9fat/plan9.ini, acme complained that there was no such file; so, being completely new to plan 9, my progress at that point came to a complete standstill. Run 9fat: first, then run acme in the same window. Or, run acme, then do the command Local 9fat: inside the editor. You need to learn about namespaces. And the task you're setting out to perform is not a difficult one, especially considering that a terminal boots with Acme already showing the readme file--so READ ME. The Local trick may be the only part that's not obvious. Otherwise: % 9fat: % sam /n/9fat/plan9.ini right click and select the filename, then midclick in the white area of the sam window. This should bring up the file. Make your changes, then click in the light blue part of the sam window. Type 'w' and hit enter, then type 'q' and hit enter. This should write and quit. Thanks - I'll try this. Another quick question: Just to be safe, I would like to copy the org plan9.ini before I try to modify it; so if I hose it, I can move it back; how would I do this? Cheers % 9fat:#do this if you haven't already % cp /n/9fat/plan9.ini /n/9fat/plan9.ini.bak John -- I've tried programming Ruby on Rails, following TechCrunch in my RSS reader, and drinking absinthe. It doesn't work. I'm going back to C, Hunter S. Thompson, and cheap whiskey. -- Ted Dziuba
Re: [9fans] first timer - editing plan9.ini
On Sun Jul 19 19:30:10 EDT 2009, benave...@gmail.com wrote: cp plan9.ini plan9.ini.old 8.3, remember. - erik
Re: [9fans] first timer - editing plan9.ini
cp plan9.ini plan9.ini.old acme didn't see /n/9fat/plan9.ini because the 9fat partition wasn't mounted in its namespace. On Sun, Jul 19, 2009 at 8:19 PM, Coreyco...@bitworthy.net wrote: On Sunday 19 July 2009 16:02:20 John Floren wrote: On Sun, Jul 19, 2009 at 3:51 PM, Coreyco...@bitworthy.net wrote: snip Can someone give me just the bare minimal sam command/info that I need to: edit a couple lines close and save properly You can use acme if you want. That was my first effort (though it suffered similar issue: must acclimate to acme before you can configure your new installation) - however, when I tried to traverse /n/9fat/plan9.ini, acme complained that there was no such file; so, being completely new to plan 9, my progress at that point came to a complete standstill. Otherwise: % 9fat: % sam /n/9fat/plan9.ini right click and select the filename, then midclick in the white area of the sam window. This should bring up the file. Make your changes, then click in the light blue part of the sam window. Type 'w' and hit enter, then type 'q' and hit enter. This should write and quit. Thanks - I'll try this. Another quick question: Just to be safe, I would like to copy the org plan9.ini before I try to modify it; so if I hose it, I can move it back; how would I do this? Cheers -- Federico G. Benavento
Re: [9fans] first timer - editing plan9.ini
Run 9fat: first, then run acme in the same window. Or, run acme, then do the command Local 9fat: inside the editor. in rio, i prefer to plumb the string Local 9fat:. this means that all new windows will inherit /n/9fat in their namespaces. - erik
Re: [9fans] first timer - editing plan9.ini
On Sunday 19 July 2009 16:25:18 John Floren wrote: Run 9fat: first, then run acme in the same window. Or, run acme, then do the command Local 9fat: inside the editor. On Sunday 19 July 2009 16:28:35 Federico G. Benavento wrote: cp plan9.ini plan9.ini.old acme didn't see /n/9fat/plan9.ini because the 9fat partition wasn't mounted in its namespace. Thanks all, much obliged. On Sunday 19 July 2009 16:25:18 John Floren wrote: You need to learn about namespaces. And the task you're setting out to perform is not a difficult one, especially considering that a terminal boots with Acme already showing the readme file--so READ ME. Yep, I like to read readme's. In fact I read that particular one several times before querying 9fans. The Local trick may be the only part that's not obvious. It was also a _key_ part.(c8= Anyhow, I'm back on track - thanks for the assist, guys. Also - the following proved useful to me, once I found it: http://www.covingtoninnovations.com/michael/blog/0807/newbie-guide.pdf Beers!
Re: [9fans] dcp - a deep copy script, better than dircp
On Sun, 19 Jul 2009 14:05:04 -0400 erik quanstrom quans...@quanstro.net wrote: On Sun Jul 19 12:26:24 EDT 2009, eeke...@fastmail.fm wrote: I was never satisfied with dircp. It's practice of copying the contents of one directory into another seemed limiting at best, obstructive at worst. The recursive copy options of Gnu cp seemed much more elegant(!), preserving the usual option syntax of cp and merely extending it slightly to include directories. see mkfs(8). i keep /tmp/allproto around with the contents of '+'. though i can't remember the last time i used it. Before I say anythign daft, what's '+'? It does not appear to be special on my system. -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] first timer - editing plan9.ini
The few minutes spent learning ed(1) will be well repaid. You'll be one of the smartest guys on your block. i second that. learning it has been one of the best investments of my time since 1982.
Re: [9fans] first timer - editing plan9.ini
On Sunday 19 July 2009 19:12:50 Skip Tavakkolian wrote: The few minutes spent learning ed(1) will be well repaid. You'll be one of the smartest guys on your block. i second that. learning it has been one of the best investments of my time since 1982. grin I would say the same thing about vi, which I practically live in, and feel hamstrung without. At anyrate, I do intend on sitting down and becoming at least comfortable with sam's ed. Though I'm guessing that I'll be installing Stefan's vim port asap - I'm _extremely_ happy that this exists. http://vmsplice.net/9vim.html Cheers
Re: [9fans] first timer - editing plan9.ini
The advantage of Acme is that there isn't much learning: all the commands are obvious (eg Put writes back to disk), but you do have to learn the mouse clicks to execute them. I use sed's language constantly, and look forward to expanding my bag of tricks with sam. Stream editors are without-a-doubt the most useful tool I have for editing files, because I can write scripts that edit them for me. I found that sam had a limiting command-line interface, so I wrote a script around it (ssam) that gives at a more sed-like stream-editing interface: -e accepts a (series of) sam commands; -f accepts the name of a file with sam commands; and you can pipe in the text you want to change, then use -e or -f to supply the commands. It puts all the text it changes on standard output. It's in code-review right now, so if you use it let me know (-G sends a gripe with mail) if it doesn't work well for you. http://codereview.appspot.com/95076/diff/1/2 Jason Catena
[9fans] Newsqueak command line arguments
Hi, Is there some way to access command line arguments with squint? The provided paper and squint/sq don't mention any method of passing options to scripts.
Re: [9fans] i/o on a hangup channel asymmetry
On Jul 19, 2009, at 2:55 PM, Charles Forsyth wrote: not for network connections? i think pipe is the only case, and even that is suppressed for pipes that carry 9p, after mounting. one last kick of a dead horse: see that's exactly what I'm talking about -- all these exceptions and for what? I'm pretty sure if we change the devpipe today not to send a note nobody would even notice... Thanks, Roman.
Re: [9fans] i/o on a hangup channel asymmetry
one last kick of a dead horse: see that's exactly what I'm talking about -- all these exceptions and for what? I'm pretty sure if we change the devpipe today not to send a note nobody would even notice... since you're confident that this exception is spurious, why don't you remove it from your kernel? your argument would be much more convincing if you had evidence that after a couple million pids, your cpu server has experienced no funnies. - erik
