Re: [9fans] what features would you like in a shell?
> re not reinventing the wheel, you might want to look into the es
> shell. I think this is what erik alluded to earlier - I've never used
> it myself but I understand it is extremely programmable, to the point
> where you can redefine the pipe operator for example.
; %pipe {echo true} 1 0 cat
true
; fn %pipe {echo $* ; $&pipe $*}; echo fu | cat
{echo fu} 1 0 {cat}
fu
- erik
Re: [9fans] what features would you like in a shell?
2009/4/1 erik quanstrom : >> I've not run into many actual problems with rc so it's pretty near >> perfect :> > > pretty near. > > redirection has a few rough points. dealing with a device > that expects a write then a read like /net/dns is painful. > i can never get the syntax right the first try. > and (hopefully this isn't just my ignorance) i don't know how > to open a fd to a background shell as one would in bourne. I haven't sat down and understood the finer points of rc's redirection yet, but the precedence relationships between > < and | certainly confuse the hell out of me, coming from bourne ;) I'd like to see a shell that, when confronted with a pipeline that looks like "foo", realises input and output are headed for the same file, and does whatever it needs to do to avoid clobbering the file before reading it. re not reinventing the wheel, you might want to look into the es shell. I think this is what erik alluded to earlier - I've never used it myself but I understand it is extremely programmable, to the point where you can redefine the pipe operator for example. -sqweek
Re: [9fans] GSOC: Drawterm for the iPhone
On Mon, Mar 30, 2009 at 11:42 PM, Federico G. Benavento wrote: > I'm impressed by how the "it'd be nice" position is stronger than > "it'd be useful" one. > Some would argue plan 9 isn't useful at all. In fact, I bet most people would argue that, and that we're a minority. How big is the intersection of plan 9 users and iphone users? :-) I use both, but wouldn't use drawterm on the iPhone, so I think I just diminished the audience for this app to maybe 2 or 3 people if I had to take a wild guess :-) Dave > > -- > Federico G. Benavento > >
[9fans] Fwd: ***Very Important***: Get Your Students to Submit their Proposals via the 2009 site *now*
Sorry for forwarding this to 9fans; it seems we have a lot of people discussing GSoC stuff there too. Please don't reply to this on 9fans. Instead, please take GSoC to plan9-g...@googlegroups.con, and if you are considering submitting a proposal, as Leslie suggests, please *do so now*. We only have 3 more days for the proposal deadline, after which no new proposals will be accepted, and no new edits will be made. At that point it is up to the mentors to pick and choose. Thanks! --Devon -- Forwarded message -- From: LH (Leslie Hawthorn) Date: 2009/3/31 Subject: ***Very Important***: Get Your Students to Submit their Proposals via the 2009 site *now* To: Google Summer of Code Mentors List Hello everyone, Right now, we have about 2x the students registered on the site as we do number of proposals submitted. No doubt some of these student registrations are "spam" from folks who won't be submitting proposals. However, I am also hearing things like "We have six applications submitted to the GSoC 2009 site but we're discussing another 20 or so in our forums." I realize that many organizations are working with students to refine their proposal ideas on their mailing lists, wikis, etc. However, a proposal on a wiki, mailing list, etc. does not constitute an actual application for the program; the proposal must be submitted to the GSoC 2009 site. While doing review and refinement outside of http://socghop.appspot.com is a useful exercise, it doesn't allow us to accurately gauge the number of student proposals we're receiving for GSoC 2009. Please help us get an accurate sense of how many proposals will be submitted for GSoC 2009 by asking your students to submit their proposals to the GSoC 2009 site *now*. They are welcome to link to the wiki page, mailing list thread, forum topic, etc. where their proposals are under discussion and refinement as part of the proposal submission process.[0] In case folks are wondering, we want to get this data so we can decide if it's worthwhile to extend the student application deadline. We're pretty much set on "no, we won't be extending the deadline," but we need better data so we can assess if a deadline extension would be a good thing to do. We're still anticipating the usual "near to deadline application submission rush" that we see every year but we'd like to get a more accurate proposal count sooner rather than later. Cheers, LH [0] - http://socghop.appspot.com/document/show/program/google/gsoc2009/userguide#depth_studentapply --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-l...@googlegroups.com To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en -~--~~~~--~~--~--~---
Re: [9fans] what features would you like in a shell?
On Tue, 2009-03-31 at 15:29 +, noagbodjivictor wrote:
>
> so I'm writing to get your opinions. maybe there are thing that people
> implement themselves but want included in the shell itself? or just
> something they want implemented?
>
> thanks a lot in advance for your help.
>
A few features I'd like to see in a shell (though they may already
exist):
Simple redirection into jobs, i.e. some_bin & echo "data" >%1, though
really I don't see why job control should be part of the shell as
opposed to its own program, i.e. $id=`{job start some_bin}; echo "data"
| job $id
Open looped pipelines. This one is kind of weird (and full of potential
problems) a pipeline the which reads its input from its output AND
stdin, and outputs to its input AND stdout. But I think this one can
actually be done with cat, tee, and FIFO's.
Re: [9fans] what features would you like in a shell?
>> you think the idea of reloading a crashed program is not a good one? > > i don't like the idea. > >> for example, what if it's a web browser? > > how do you determine when to relaunch? how > do you decide that the program is not going to > relaunch? how do you stop an errant shell from > relaunching and consuming all your resources? you could just print out the commands to restart the program, and the user could select and send it only if they want to. that's the approach i usually take when i write an rc script to automate something, but i want to check what's going to happen before i let it run
Re: [9fans] what features would you like in a shell?
On Tue, Mar 31, 2009 at 11:29 AM, noagbodjivictor wrote: > hello, > > I'm a undergrade CS student doing a project for my introductory > operating systems class. my team wants to write a simple shell from > scratch. > > one idea we have found so far is the following. the shell will record > all the programs it has run. whenever a program goes awry and is > killed by the kernel. the shell will reload it. > > what do you think of it? Bad idea. What if I expect it to die and maybe want to debug it before running it again? What if the kernel killed it because it was hogging resources? Respawning something that constantly gets killed will probably render the machine unusable. What if the program dies really quickly? The shell could get caught in a very tight loop you can't interrupt, and the user winds up killing the shell itself and opening a new one (after getting really aggravated). I suppose you could make it optional, but then again, why can't the user just restart the process by hand? > > also, we know there are many many shells out there. and our professor > would not like us to write from scratch. we wanted because it provides > much exercise. but we certainly don't know about all the shells out > there. > > so I'm writing to get your opinions. maybe there are thing that people > implement themselves but want included in the shell itself? or just > something they want implemented? > > thanks a lot in advance for your help. > >
Re: [9fans] what features would you like in a shell?
> thanks a lot for the reply. i got my hand of the unix programming > environment by Kernighan and Pike. I don't think we have the > programming skills for implementing a regular expression engine, but i would recommend against reimplementing regular expressions. ken is hard to beat; the standard regexp library is what you want. the trick is going to be thinking hard about how you are going to deal with some of the mismatches between standard regular expressions and file names. for example, you might need to deal with the fact that '.' is common in file names, but means any character in a regular expression. i think this is going to be the cannonical problem: globregexp *.[ch] \.[ch]$ '*' \* (this problem is easy) i don't think this one is about writing lots of code. > you think the idea of reloading a crashed program is not a good one? i don't like the idea. > for example, what if it's a web browser? how do you determine when to relaunch? how do you decide that the program is not going to relaunch? how do you stop an errant shell from relaunching and consuming all your resources? - erik
Re: [9fans] what features would you like in a shell?
> it's done by rio, not the shell and you use the > insert key, not tab, as god intended. bash insert ≡ control-f. - erik
Re: [9fans] what features would you like in a shell?
> it would be interesting to use something closer to regular expressions > rather than standard shell globbing. the challenge would be > to avoid gratuitous breakage and yet allow the match operator > to be much more powerful. thanks a lot for the reply. i got my hand of the unix programming environment by Kernighan and Pike. I don't think we have the programming skills for implementing a regular expression engine, but there was a simple solution that measured the difference between the command the user entered and an existing command. maybe we should include that one. you think the idea of reloading a crashed program is not a good one? for example, what if it's a web browser?
Re: [9fans] what features would you like in a shell?
> I've not run into many actual problems with rc so it's pretty near
> perfect :>
pretty near.
redirection has a few rough points. dealing with a device
that expects a write then a read like /net/dns is painful.
i can never get the syntax right the first try.
and (hopefully this isn't just my ignorance) i don't know how
to open a fd to a background shell as one would in bourne.
quoting can get a little dicy when combined with here
docs.
> hash maps : a['name'] = 'glenda'
> arithmetic - though with the 80/20 rule, I don't think the bloat is worth it
the shell i worked on had regular lists, not flat
lists like rc. the problem with this is that suppose
you're in a directory with a.c b.c a.h b.h. does this
print 2 or 4?
fn x {
echo $#*
}
x *.c *.h
in rc, the answer is obvious. if you allow regular
lists, then * is either ((a.c b.c) (a.h b.h)) or
(a.c b.c a.h b.h).
perhaps i just missed the obvious.
- erik
Re: [9fans] drawterm crash
On Tue Mar 31 12:14:49 EDT 2009, uai...@gmail.com wrote: > Hi, > Just try to paste anything coming from X. (e.g. paint some text from > an xterm, then try to paste it on some terminal on drawterm, using the > menu or the 1-3 mouse chord, both crash anyway) you're using a 64-bit os, aren't you? if that's the case, i fixed this a week or so ago and pushed the patch to russ. i think he's got the fix. if not, just fix the compile warning and you'll be good-to-go. it's an int vs. long issue. unfortunately, i don't have yesterday for linux and don't remember what i fixed. - erik
Re: [9fans] what features would you like in a shell?
> I'd love to see tab completion at the command line. If there is a way to do > it in Plan 9, then I haven't figured it out yet. But then I'm a newby to the > OS. it's done by rio, not the shell and you use the insert key, not tab, as god intended. bash irritates the heck out of me when it won't let me type a tab. it's a gentle reminder that i should stop wasting time on linux. - erik
Re: [9fans] what features would you like in a shell?
Just Ctrl+F and you have completion for the current dir. I think it's a pretty easy hack to extend this to /bin On 31 Mar 2009, at 18:14, rapo...@catt.com wrote: I'd love to see tab completion at the command line. If there is a way to do it in Plan 9, then I haven't figured it out yet. But then I'm a newby to the OS. - Original Message - From: noagbodjivictor To: 9fans@9fans.net Sent: Tue, 31 Mar 2009 11:29:44 -0400 (EDT) Subject: [9fans] what features would you like in a shell? hello, I'm a undergrade CS student doing a project for my introductory operating systems class. my team wants to write a simple shell from scratch. one idea we have found so far is the following. the shell will record all the programs it has run. whenever a program goes awry and is killed by the kernel. the shell will reload it. what do you think of it? also, we know there are many many shells out there. and our professor would not like us to write from scratch. we wanted because it provides much exercise. but we certainly don't know about all the shells out there. so I'm writing to get your opinions. maybe there are thing that people implement themselves but want included in the shell itself? or just something they want implemented? thanks a lot in advance for your help.
Re: [9fans] what features would you like in a shell?
I'd love to see tab completion at the command line. If there is a way to do it in Plan 9, then I haven't figured it out yet. But then I'm a newby to the OS. - Original Message - From: noagbodjivictor To: 9fans@9fans.net Sent: Tue, 31 Mar 2009 11:29:44 -0400 (EDT) Subject: [9fans] what features would you like in a shell? hello, I'm a undergrade CS student doing a project for my introductory operating systems class. my team wants to write a simple shell from scratch. one idea we have found so far is the following. the shell will record all the programs it has run. whenever a program goes awry and is killed by the kernel. the shell will reload it. what do you think of it? also, we know there are many many shells out there. and our professor would not like us to write from scratch. we wanted because it provides much exercise. but we certainly don't know about all the shells out there. so I'm writing to get your opinions. maybe there are thing that people implement themselves but want included in the shell itself? or just something they want implemented? thanks a lot in advance for your help.
[9fans] drawterm crash
Hi, Just try to paste anything coming from X. (e.g. paint some text from an xterm, then try to paste it on some terminal on drawterm, using the menu or the 1-3 mouse chord, both crash anyway) Saludos -- Hugo
Re: [9fans] what features would you like in a shell?
I've not run into many actual problems with rc so it's pretty near perfect :> Though as Erik said - regex matches to compliment ~ matching hash maps : a['name'] = 'glenda' arithmetic - though with the 80/20 rule, I don't think the bloat is worth it I tried a write a couple of other ideas but each time it was better to spawn awk or some other better tool for the job!
Re: [9fans] what features would you like in a shell?
On Tue Mar 31 11:37:06 EDT 2009, noagbodjivic...@gmail.com wrote: > hello, > > I'm a undergrade CS student doing a project for my introductory > operating systems class. my team wants to write a simple shell from > scratch. > > one idea we have found so far is the following. the shell will record > all the programs it has run. whenever a program goes awry and is > killed by the kernel. the shell will reload it. unfortunately, the most common reason for a program to go arwy is that the program is broken and it will break again when reloated. it would be more interesting to explore how a shell in plan 9 could be used to build simple fs. rc has a very interesting virtual machine. it might be interesting to build a shell with some hooks into its vm. paul haahr and byron built a shell with scheme-y internals and exposed them. interesting, but complicated. it would be interesting to use something closer to regular expressions rather than standard shell globbing. the challenge would be to avoid gratuitous breakage and yet allow the match operator to be much more powerful. these are areas where rc might be improved upon. however, as per usual, it was hard to improve on bourne, and it's even harder to improve on duff. nevertheless, i learned quite a bit from failing to improve on rc. - erik
[9fans] what features would you like in a shell?
hello, I'm a undergrade CS student doing a project for my introductory operating systems class. my team wants to write a simple shell from scratch. one idea we have found so far is the following. the shell will record all the programs it has run. whenever a program goes awry and is killed by the kernel. the shell will reload it. what do you think of it? also, we know there are many many shells out there. and our professor would not like us to write from scratch. we wanted because it provides much exercise. but we certainly don't know about all the shells out there. so I'm writing to get your opinions. maybe there are thing that people implement themselves but want included in the shell itself? or just something they want implemented? thanks a lot in advance for your help.
Re: [9fans] GSOC: Drawterm for the iPhone
o/live assumes that in many cases you may have a mouse with just one button and some way to issue mouse-3 clicks. (eg., touch pads). The result was the circular menu implementation and a different interaction language. However, it does not consider multitouch at all. > From: eri...@gmail.com > To: 9fans@9fans.net > Reply-To: 9fans@9fans.net > Date: Tue Mar 31 17:00:43 CET 2009 > Subject: Re: [9fans] GSOC: Drawterm for the iPhone > > On Tue, Mar 31, 2009 at 9:36 AM, J.R. Mauro wrote: > > On Tue, Mar 31, 2009 at 8:01 AM, Eric Van Hensbergen > wrote: > >> The fact that rio and/or acme have a limited usage model with such a > device > >> and/or multitouch in general is a shame -- wouldn't it be nice to fix > that. > > > > This is a very good point. As much as I like rio, I can't help but be > > aggravated by it sometimes, and it would be nice to have someone take > > a fresh look at interacting with it and possibly solve some of the > > shortcomings. > > > > I think the key here is devices like the iPhone beg a different model > -- rio and ACME were developed for graphical, mouse/keyboard setups > (with relatively large screens I might add) -- smaller devices or > devices with different models (like set top boxes or game consoles) > really require a different set of tools/apps. I think this is one of > the things that was interesting about the Plan B approach -- different > front-ends for similar back ends. I doubt anyone wants to use the > iphone as a developer workstation, but it might be nice to make it an > additional screen for faces, or as the student points out and > additional user-interface to someone's work environment. > > As far as fixing rio and ACME, I would urge anyone looking at that to > come up with a complementary solution as opposed to messing with the > existing model. I don't see any reason why alternative interfaces > can't co-exist which support keyboard-only interaction (ron's smackme > comes to mind as well as wmii's model) as well as multitouch on > laptops (actually the iphone's new cut/paste model might work for > multitouch trackpads -- and while not as natural as the existing > chording method might make ACME useable when one finds oneself without > a three button mouse handy). Another avenue to pursue is looking at > using gestures to replace chords -- it seems like pinch and expand > might be natural replacements for cut and paste. I don't think the > community or the system benefits form limiting our options (but lets > keep them options -- I still prefer chording when possible ;) > > -eric
Re: [9fans] GSOC: Drawterm for the iPhone
On Tue, Mar 31, 2009 at 10:57 AM, Eric Van Hensbergen wrote: > On Tue, Mar 31, 2009 at 9:36 AM, J.R. Mauro wrote: >> On Tue, Mar 31, 2009 at 8:01 AM, Eric Van Hensbergen >> wrote: >>> The fact that rio and/or acme have a limited usage model with such a device >>> and/or multitouch in general is a shame -- wouldn't it be nice to fix that. >> >> This is a very good point. As much as I like rio, I can't help but be >> aggravated by it sometimes, and it would be nice to have someone take >> a fresh look at interacting with it and possibly solve some of the >> shortcomings. >> > > I think the key here is devices like the iPhone beg a different model > -- rio and ACME were developed for graphical, mouse/keyboard setups > (with relatively large screens I might add) -- smaller devices or > devices with different models (like set top boxes or game consoles) > really require a different set of tools/apps. I think this is one of > the things that was interesting about the Plan B approach -- different > front-ends for similar back ends. I doubt anyone wants to use the > iphone as a developer workstation, but it might be nice to make it an > additional screen for faces, or as the student points out and > additional user-interface to someone's work environment. > > As far as fixing rio and ACME, I would urge anyone looking at that to > come up with a complementary solution as opposed to messing with the > existing model. I don't see any reason why alternative interfaces > can't co-exist which support keyboard-only interaction (ron's smackme > comes to mind as well as wmii's model) as well as multitouch on > laptops (actually the iphone's new cut/paste model might work for > multitouch trackpads -- and while not as natural as the existing > chording method might make ACME useable when one finds oneself without > a three button mouse handy). Another avenue to pursue is looking at > using gestures to replace chords -- it seems like pinch and expand > might be natural replacements for cut and paste. I don't think the > community or the system benefits form limiting our options (but lets > keep them options -- I still prefer chording when possible ;) > > -eric > Yes, that's sane. The interaction model depends very much on context, and there is no one-size-fits-all interaction model. Being able to switch models on the fly would also be nice.
Re: [9fans] GSOC: Drawterm for the iPhone
On Tue, Mar 31, 2009 at 9:36 AM, J.R. Mauro wrote: > On Tue, Mar 31, 2009 at 8:01 AM, Eric Van Hensbergen wrote: >> The fact that rio and/or acme have a limited usage model with such a device >> and/or multitouch in general is a shame -- wouldn't it be nice to fix that. > > This is a very good point. As much as I like rio, I can't help but be > aggravated by it sometimes, and it would be nice to have someone take > a fresh look at interacting with it and possibly solve some of the > shortcomings. > I think the key here is devices like the iPhone beg a different model -- rio and ACME were developed for graphical, mouse/keyboard setups (with relatively large screens I might add) -- smaller devices or devices with different models (like set top boxes or game consoles) really require a different set of tools/apps. I think this is one of the things that was interesting about the Plan B approach -- different front-ends for similar back ends. I doubt anyone wants to use the iphone as a developer workstation, but it might be nice to make it an additional screen for faces, or as the student points out and additional user-interface to someone's work environment. As far as fixing rio and ACME, I would urge anyone looking at that to come up with a complementary solution as opposed to messing with the existing model. I don't see any reason why alternative interfaces can't co-exist which support keyboard-only interaction (ron's smackme comes to mind as well as wmii's model) as well as multitouch on laptops (actually the iphone's new cut/paste model might work for multitouch trackpads -- and while not as natural as the existing chording method might make ACME useable when one finds oneself without a three button mouse handy). Another avenue to pursue is looking at using gestures to replace chords -- it seems like pinch and expand might be natural replacements for cut and paste. I don't think the community or the system benefits form limiting our options (but lets keep them options -- I still prefer chording when possible ;) -eric
Re: [9fans] GSOC: Drawterm for the iPhone
On Tue, Mar 31, 2009 at 8:01 AM, Eric Van Hensbergen wrote: > The fact that rio and/or acme have a limited usage model with such a device > and/or multitouch in general is a shame -- wouldn't it be nice to fix that. This is a very good point. As much as I like rio, I can't help but be aggravated by it sometimes, and it would be nice to have someone take a fresh look at interacting with it and possibly solve some of the shortcomings. > Drawterm (or ports to devices like the DS) are not ends in themselves but a > means to exploring new interface models, ideas, and applications. Likewise > I hope the student reaches beyond simple drawterm support and implements an > example iPhone environment/app within Plan 9 that matches it's interface > model better than rio. > > As far as counting who would use this, that seems misdirected - GSoc is for > the students to learn and get interested in plan 9, not for the community to > get work done. > > -eric > > Sent from my iPhone > > On Mar 31, 2009, at 1:00 AM, Uriel wrote: > >> On Tue, Mar 31, 2009 at 6:57 AM, Tharaneedharan Vilwanathan >> wrote: >>> >>> hi, >>> >>> sorry if i have missed any prior discussion, but i would like to >>> mention that i am curious about this effort. >>> >>> to me, iphone (or similar device) seems to be an appropriate device >>> that is small enough to be a portable drawterm device (eventually it >>> could become cheaper too). one can quickly connect it to a TV or a >>> hybrid monitor and get a bigger display. >>> >>> i have tried this before in iphone with acme running in my mac: >>> >>> http://www.engadget.com/2007/07/12/modified-vnc-software-enables-remote-access-on-iphone/ >> >> So, was acme usable with a touch screen as input? And does this mean >> that VNC clients already provide the desired functionality? >> >>> so in my opinion, this is a good effort. >> >> I'm not sure how that conclusion follows from the rest of your email. >> Can you clarify? >> >> Assuming that there are no overwhelming user interface issues (which >> seems like a huge assumption to me), what actual useful functionality >> would a drawterm port provide that vnc/ssh doesn't? >> >> I would remind people too that Google is going to *pay good money* for >> this work, so I think it is reasonable to ask how worthy it is. >> >> Peace >> >> uriel >> > >
Re: [9fans] Managed/Automated IPv6 addresses via RA's
> Moreover, I'm sure that the Plan9 is receiving properIPv6RA's which > I have confirmed with help of snoopy also. ?!? Inferno IPv6 stacks works fine while Plan 9 one is no more understood I can't ping Plan9 IPv6 from MacOS nor Inferno and vice versa, while IPv6 Inferno and MacOS see each other. .498200 IP6 truncated-ip6 - 20 bytes missing!fe80::20c:29ff:feea:42a5 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2000::2, length 52 .498912 IP6 truncated-ip6 - 20 bytes missing!fe80::20c:29ff:feea:42a5 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2000::2, length 52 .577807 IP6 truncated-ip6 - 20 bytes missing!fe80::20c:29ff:feea:42a5 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2000::2, length 52 .577676 IP6 truncated-ip6 - 20 bytes missing!fe80::20c:29ff:feea:42a5 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2000::2, length 52 .617711 IP6 truncated-ip6 - 20 bytes missing!fe80::20c:29ff:feea:42a5 > ff02::1:ff00:2: ICMP6, neighbor solicitation, who has 2000::2, length 52 Is this bound to any IPv6 change within /sys/src/9/ip/ ? +F
Re: [9fans] Latest pull killed my server
/* compute log10(ether->mbps) into lg */
for(lg = 0, mb = ether->mbps; mb >= 10; lg++)
mb /= 10;
if (lg > 0)
lg--;
if (lg > 14)/* 2^(14+17) = 2ⁱ */
lg = 14;
/* allocate larger output queues for higher-speed interfaces */
bsz = 1UL << (lg + 17); /* 2ⁱ⁷ = 128K, bsz = 2ⁿ × 128K */
while (bsz > mainmem->maxsize / 8 && bsz > 128*1024)
bsz /= 2;
netifinit(ether, name, Ntypes, bsz);
>> while (ether->oq == nil && bsz > 128*1024) {
bsz /= 2;
ether->oq = qopen(bsz, Qmsg, 0, 0);
ether->limit = bsz;
}
if(ether->oq == nil)
panic("etherreset %s", name);
the simple fix would be to change the > on the marked
line to >=. but i think the while loop could be tossed
since malloc panics on failure and since qopen only allocates
sizeof(Queue) regardless of the limit argument. i had
this code when i wrote the myricom driver (qio sets q->limit itself).
j = ether->mbps;
if(j > 1000)
j *= 10;
for(i = 0; j >= 100; i++)
j /= 10;
i = (128oq = qopen(i, Qmsg, 0, 0);
if(ether->oq == nil)
panic("etherreset %s", name);
by the way, a quick scan shows
ether2114x
etherrhine
are capable of setting mbps to 0 on startup. this should
be legal, since ethernet can be connected after boot.
- erik
Re: [9fans] GSOC: Drawterm for the iPhone
The fact that rio and/or acme have a limited usage model with such a device and/or multitouch in general is a shame -- wouldn't it be nice to fix that. Drawterm (or ports to devices like the DS) are not ends in themselves but a means to exploring new interface models, ideas, and applications. Likewise I hope the student reaches beyond simple drawterm support and implements an example iPhone environment/app within Plan 9 that matches it's interface model better than rio. As far as counting who would use this, that seems misdirected - GSoc is for the students to learn and get interested in plan 9, not for the community to get work done. -eric Sent from my iPhone On Mar 31, 2009, at 1:00 AM, Uriel wrote: On Tue, Mar 31, 2009 at 6:57 AM, Tharaneedharan Vilwanathan wrote: hi, sorry if i have missed any prior discussion, but i would like to mention that i am curious about this effort. to me, iphone (or similar device) seems to be an appropriate device that is small enough to be a portable drawterm device (eventually it could become cheaper too). one can quickly connect it to a TV or a hybrid monitor and get a bigger display. i have tried this before in iphone with acme running in my mac: http://www.engadget.com/2007/07/12/modified-vnc-software-enables-remote-access-on-iphone/ So, was acme usable with a touch screen as input? And does this mean that VNC clients already provide the desired functionality? so in my opinion, this is a good effort. I'm not sure how that conclusion follows from the rest of your email. Can you clarify? Assuming that there are no overwhelming user interface issues (which seems like a huge assumption to me), what actual useful functionality would a drawterm port provide that vnc/ssh doesn't? I would remind people too that Google is going to *pay good money* for this work, so I think it is reasonable to ask how worthy it is. Peace uriel
Re: [9fans] GSOC: Drawterm for the iPhone
>Inferno plug-in for Safari? We had a go at a plug-in for Firefox in gsoc2007. These things (like drawterm, or a hosted Inferno port) are either very easy or very hard. "very easy" because if the environment is suitable, the portability interface for hosted Inferno is basically trivial: 513 FreeBSD/os.c 477 Irix/os.c 539 Linux/os.c 528 NetBSD/os.c 798 Nt/os.c 524 OpenBSD/os.c 422 Plan9/os.c 437 Solaris/os.c it needs a way to create shared-memory processes; a way for them to block, be made ready, and exit; a way for a process to allocate more shared memory; a way to interrupt a process when blocked or in a system call (Nt loses badly there); and some trivia. if graphics is needed to get a basic system running: 755 MacOSX/win.c 795 Nt/win.c 564 Plan9/win.c 1620 port/win-x11a.c (no prizes for spotting the outlier there) for the original IE plugin, it was more involved: 840 Nt/ie-os.c 224 Nt/ie-win.c although most of the code in ie-os.c is the same as os.c; the ie-win just connects to separate code that actually links to IE: 1242 emu.cpp 54 factory.cpp 697 inferno.cpp 59 main.cpp (a lot of that is automatically generated; and there are now easier ways to do it, by the way) next to MacOSX, that's probably the biggest example of "hard". the firefox plug-in was potentially "hard" (because the people that define browser plug-in interfaces aren't good at defining operating systems) and became "very hard" because its ways are not our ways, and by the time the gsoc student realised that, it was too late. several people had earlier bounced off a plug-in for netscape. (i don't know the details because i wasn't involved.) with both firefox and netscape (and no doubt with Safari) it could well be that more knowledge or more effort would have it end up in the "fairly easy" or "not to hard" category, but so far that hasn't happened. obviously i'm leading up to say that perhaps Safari is much nicer to us than all the other browsers, but given its environment, i wouldn't start out with that assumption, especially a second time for GSoC. with both the Safari and some other suggestions, i think i'd be a little happier if more of the ground work had been done during the last few months and GSoC were completing the tasks or even exploring their application, not setting out.
Re: [9fans] Latest pull killed my server
On 30 Mrz., 23:36, quans...@coraid.com (erik quanstrom) wrote: > On Mon Mar 30 17:28:36 EDT 2009, vmh...@verizon.net wrote: > > > All - > > I have been running an all-in-one server on a VMware server virtual > > machine on my Windows laptop. > > After executing a 'pull' this morning, the server crashed and I have not > > been able to revive it. Fortunately it was a playground so little of > > value is missing, but I thougt I should ask . . . > > > I pulled down a copy of today's ISO and had the same results. It seems > > to be panicking when hitting the (virtualized) Ethernet port. > > > Anyone else seeing this? > > i am not seeing this, but sources venti is down and explains why > pull stepped on important stuff. replica needs to be more defensive. > > regardless, that doesn't explain why the iso worked enough to > get you to a panic. what is the panic message? > > - erik I have the same problem with vmware. The message is: "panic: etherreset ether0" I downloaded the plan9 iso file on 2009-03-24. AZ.
Re: [9fans] GSOC: Drawterm for the iPhone
One of the principle reasons for the DS(and pending DSi port) was the novel interfaces the system provided. While we can't hack on the iPhone on an OS level directly(like we did with the DS) a drawterm that conformed to Apple's guidelines could provide a novel interface to experiment with new forms of input and ways of hooking into Plan 9. If the iPhone drawterm: 1. made the typescript style of plan 9 accessible on a mobile device. 2. connected to a default public cpu server(like tip9ug) 3. was available for free in the app store It would be a *great* way for new users to experiment with Plan 9 and learn about what makes Plan 9 interesting. Noah On Tue, Mar 31, 2009 at 4:36 PM, Uriel wrote: > While 'experimenting with multitouch' is a worthwhile goal (although > highly speculative, chording *and* text input are fundamnetal to the > Plan 9 user interface, both of which seem really hard with > multitouch); doing so by porting drawterm to the iPhone seems like an > incredibly rounabout way to do so. > > Adding new input interfaces to inferno, 9vx or even p9p; would be > infinitely simpler, and a much better long term platform for research > (which would require much simpler setup). > > As for exporting devices, I ask again: what is the practical > (including research) purpose of that? > > To me this whole project seems to be high-risk/low-reward, with > worthwhile goals that could be much more easily accomplished with much > less risk via other routes which don't share any of the technical and > legal risks and would have much more potential to be useful in the > future. > > Peace > > uriel > > On Tue, Mar 31, 2009 at 8:24 AM, André Günther wrote: >> I know it's difficult to argue with you, also because just about every email >> of you is repeating the same stuff. >> >> Now the "VNC might suffice" objection is new and i want to reply to it. >> Again I am repeating myself here, but obivously there's not other way >> telling you: >> >> The only thing I personally see to make remote access on devices such as the >> iPhone an useful and enjoyable experience is to work with the multitouch >> capabilities. Thus providing an easy way for mouse chording and also certain >> gesture support for managing the screen space (like zooming, maximizing a >> certain window, scrolling etc.) >> All these things are not possible with the VNC, because VNC doesn't know >> about content, drawterm can. >> >> Another reason is the exporting device functionality drawterm provides, >> again VNC can't give you that. >> >> In addition, you repeat the worthlessness of the project. Again look at the >> past conversation and you find two basic points of view, your one renders >> the effort useless. That doesn't make the other ones invalid. >> >> Even if you don't find anything remotely useful to the iPhone as a drawterm >> device whatsoever... you still might find the following ones interesting, >> which would be sideproducts of the process and available to every Plan 9 >> user: >> - gesture detection >> - a cpu bouncer >> >> And last but not least: You got the first opportunity to play with >> moultitouch on Plan 9. I know this is part of "science" and "research" you >> obviously don't like. >> But here I want to keep the spirit alive that Plan 9 somehow made possible. >> Plan 9 is and was a research project. >> >> Best wishes, >> André >> >> >> On 31 Mar 2009, at 08:00, Uriel wrote: >> >>> On Tue, Mar 31, 2009 at 6:57 AM, Tharaneedharan Vilwanathan >>> wrote: hi, sorry if i have missed any prior discussion, but i would like to mention that i am curious about this effort. to me, iphone (or similar device) seems to be an appropriate device that is small enough to be a portable drawterm device (eventually it could become cheaper too). one can quickly connect it to a TV or a hybrid monitor and get a bigger display. i have tried this before in iphone with acme running in my mac: http://www.engadget.com/2007/07/12/modified-vnc-software-enables-remote-access-on-iphone/ >>> >>> So, was acme usable with a touch screen as input? And does this mean >>> that VNC clients already provide the desired functionality? >>> so in my opinion, this is a good effort. >>> >>> I'm not sure how that conclusion follows from the rest of your email. >>> Can you clarify? >>> >>> Assuming that there are no overwhelming user interface issues (which >>> seems like a huge assumption to me), what actual useful functionality >>> would a drawterm port provide that vnc/ssh doesn't? >>> >>> I would remind people too that Google is going to *pay good money* for >>> this work, so I think it is reasonable to ask how worthy it is. >>> >>> Peace >>> >>> uriel >> >> >> > >
Re: [9fans] GSOC: Drawterm for the iPhone
While 'experimenting with multitouch' is a worthwhile goal (although highly speculative, chording *and* text input are fundamnetal to the Plan 9 user interface, both of which seem really hard with multitouch); doing so by porting drawterm to the iPhone seems like an incredibly rounabout way to do so. Adding new input interfaces to inferno, 9vx or even p9p; would be infinitely simpler, and a much better long term platform for research (which would require much simpler setup). As for exporting devices, I ask again: what is the practical (including research) purpose of that? To me this whole project seems to be high-risk/low-reward, with worthwhile goals that could be much more easily accomplished with much less risk via other routes which don't share any of the technical and legal risks and would have much more potential to be useful in the future. Peace uriel On Tue, Mar 31, 2009 at 8:24 AM, André Günther wrote: > I know it's difficult to argue with you, also because just about every email > of you is repeating the same stuff. > > Now the "VNC might suffice" objection is new and i want to reply to it. > Again I am repeating myself here, but obivously there's not other way > telling you: > > The only thing I personally see to make remote access on devices such as the > iPhone an useful and enjoyable experience is to work with the multitouch > capabilities. Thus providing an easy way for mouse chording and also certain > gesture support for managing the screen space (like zooming, maximizing a > certain window, scrolling etc.) > All these things are not possible with the VNC, because VNC doesn't know > about content, drawterm can. > > Another reason is the exporting device functionality drawterm provides, > again VNC can't give you that. > > In addition, you repeat the worthlessness of the project. Again look at the > past conversation and you find two basic points of view, your one renders > the effort useless. That doesn't make the other ones invalid. > > Even if you don't find anything remotely useful to the iPhone as a drawterm > device whatsoever... you still might find the following ones interesting, > which would be sideproducts of the process and available to every Plan 9 > user: > - gesture detection > - a cpu bouncer > > And last but not least: You got the first opportunity to play with > moultitouch on Plan 9. I know this is part of "science" and "research" you > obviously don't like. > But here I want to keep the spirit alive that Plan 9 somehow made possible. > Plan 9 is and was a research project. > > Best wishes, > André > > > On 31 Mar 2009, at 08:00, Uriel wrote: > >> On Tue, Mar 31, 2009 at 6:57 AM, Tharaneedharan Vilwanathan >> wrote: >>> >>> hi, >>> >>> sorry if i have missed any prior discussion, but i would like to >>> mention that i am curious about this effort. >>> >>> to me, iphone (or similar device) seems to be an appropriate device >>> that is small enough to be a portable drawterm device (eventually it >>> could become cheaper too). one can quickly connect it to a TV or a >>> hybrid monitor and get a bigger display. >>> >>> i have tried this before in iphone with acme running in my mac: >>> >>> http://www.engadget.com/2007/07/12/modified-vnc-software-enables-remote-access-on-iphone/ >> >> So, was acme usable with a touch screen as input? And does this mean >> that VNC clients already provide the desired functionality? >> >>> so in my opinion, this is a good effort. >> >> I'm not sure how that conclusion follows from the rest of your email. >> Can you clarify? >> >> Assuming that there are no overwhelming user interface issues (which >> seems like a huge assumption to me), what actual useful functionality >> would a drawterm port provide that vnc/ssh doesn't? >> >> I would remind people too that Google is going to *pay good money* for >> this work, so I think it is reasonable to ask how worthy it is. >> >> Peace >> >> uriel > > >
Re: [9fans] GSOC: Drawterm for the iPhone
2009/3/31 André Günther : > The only thing I personally see to make remote access on devices such as the > iPhone an useful and enjoyable experience is to work with the multitouch > capabilities. Thus providing an easy way for mouse chording and also certain > gesture support for managing the screen space (like zooming, maximizing a > certain window, scrolling etc.) > All these things are not possible with the VNC, because VNC doesn't know > about content, drawterm can. > Indeed, multitouch support in Plan9 would be *very _useful_*. Not only iPhone like devices, but also synaptics touchpads available in most laptops (Asus and all these new netbooks being the most obivious example) support multitouch. Being able to use these devices as a portable terminal without the need to carry around an extra mouse would be great. 2 and 3 fingers gestures as a button chording replacement looks like a natural and logical thing to me, YMMV. 3 mouse button are becoming more difficult to find every day, while synaptics devices are the new standard input device. OTOH, I don't really know how difficult would be to port iPhone multitouch to synaptics touchpads, but only the user interface research would be an advancement in this direction. hth, -- - yiyus || JGL .
Re: [9fans] P9P venti/copy bug?
On Mon, Feb 09, 2009 at 11:55:05AM -0500, Venkatesh Srinivas wrote: > On Mon, Feb 09, 2009 at 08:48:33AM -0800, Russ Cox wrote: >> On Mon, Feb 9, 2009 at 4:56 AM, Venkatesh Srinivas wrote: >>> vcopy: reading block (type 16): >>> read asked for got >>> da39a3ee5e6b4b0d3255bfef95601890afd80709 >> >> The real question is how you got an archive with an all zeros score in it. >> There are some programs that use that internally to mean "no block" >> but any time such a block is written to venti, the score should be the >> zero-byte sha1 da39...0709. >> > > When I use -V with Plan 9's vcopy, the zero score block isn't listed... > I suspect that the block with the zero score is not actually in the > archive? > > -- vs > I just tripped over this myself and found that apparently Plan 9 native vac sets root.prev to all zeros when there is no previous root. So I applied the diff below. I'm not sure this is a correct fix? --nwf; diff -r 74392a7c323c src/cmd/venti/copy.c --- a/src/cmd/venti/copy.c Wed Mar 11 13:37:29 2009 -0700 +++ b/src/cmd/venti/copy.c Tue Mar 31 03:12:53 2009 -0400 @@ -10,6 +10,8 @@ int fast; int verbose; VtConn *zsrc, *zdst; + +uchar allzeros[VtScoreSize]; void usage(void) @@ -54,7 +56,8 @@ break; } walk(root.score, VtDirType, 0); - walk(root.prev, VtRootType, 0); + if(memcmp(root.prev, allzeros, VtScoreSize)) + walk(root.prev, VtRootType, 0); if(rewrite) vtrootpack(&root, buf); /* walk might have changed score */ break; pgpurOjOaHTKl.pgp Description: PGP signature
