Re: [9fans] Status of port of Go to Plan 9
> goos.c is meant to be in src/lib9, I need to start up my laptop to > check that in fact it is a module I added specially for Plan 9. Lucio, what is the difference between your purpose and the one I installed (plan9fron?). By your attention, I found Russ's repository of 'go for plan9', and the one I have installed is not shown there. According to your mail, you are going to submit your efforts to golang community, where Russ is one of the big members. Russ also has been contributed Plan 9 community for a long time. Then, I suppose anyone will send their patch to Russ... Many don't know his repository on google? I'm not a suitable person to develope language, I'll be a user of it. However, the sceen I'm now experiencing looks like strange to me. Any considerations? Kenji
[9fans] mail client; general question web vs command
> Robert Raschke coded a threaded version of Acme's News. > But that depends on the filesystem hierarchy of messages > in nntpfs. (n)upasfs does not thread messages at the level > of the fs. Indeed, it would be a better approach to thread at > the interface level, which should be possible all the same > and could apply to Acme's News interface as well (so we > can perhaps remove a lot of that code from nntpfs). upas/fs has all the information it needs to do the threading, and it's cached. the client, otoh will need to scan the entire mail box to determine threading. this can be pretty slow if your mailbox is not small. and threading's usefulness depends on your mailbox being not small. what upas/fs lacks is the ability to present the same mailbox many times. this would allow for a single store rather than moving messages around. nedmail is already equiped to handle threading, since it handles subfolders already. (for lack of threading, i use nedmail's g/subject/h or g/sender/h.) > If anyone does this, I also suggest using Russ' rc version > (ported to Plan 9) of Acme Mail, instead of adapting the C > code. this sounds tempting, but how are you going to thread efficiently in rc? (russ' upas/nfs is much different in presentation than upas/fs.) - erik
Re: [9fans] Status of port of Go to Plan 9
>> goos.c is meant to be in src/lib9, I need to start up my laptop to >> check that in fact it is a module I added specially for Plan 9. > > Lucio, what is the difference between your purpose and the one > I installed (plan9fron?). By your attention, I found Russ's repository > of 'go for plan9', and the one I have installed is not shown there. > I started with the objective of porting the improved development toolchain (8a, 8c, 8l) to Plan 9 so that I could use Plan 9 as my development platform of choice. Consider that the Go toolchain includes 6a, 6c and 6l for the x64 as well as tools for the arm, all there for the picking. Also, the target platforms are interesting and increasingly so: various Posix-like OSes, including Darwin, Windows and Native Client (NaCl). That was my original attraction, not least ELF output format, which I have shoehorned into an odish version of the Plan 9 kernel but was unable to test (who knows what good that might do!). I discovered that the Go release is quite a moving target and chose to feed back to the Go Authors as many of the changes to the Go release sources as they were willing to accept. We have made considerable progress as a result and both sides have hopefully benefitted from my efforts, which are continuing as we speak. The difference from the plan9front release of Go is that the latter is, as far as I understand, a one-off effort which will become more and more difficult to maintain over time. I have been there myself, although I have not been as successful; worse, it was hard for me to go forward after a pause of a few months, I do not envy the next person to follow that path. Please treat the above as opinion, I have not had the opportunity to investigate the plan9front port of Go and I am basing my opinions on what I have heard from others. > According to your mail, you are going to submit your efforts to > golang community, where Russ is one of the big members. > Russ also has been contributed Plan 9 community for a long time. > Then, I suppose anyone will send their patch to Russ... > Many don't know his repository on google? > Russ has been an extremely helpful reviewer of the stuff I have submitted to the Go Authors, he and I have successfully negotiated a number of differences of opinion and my efforts in future ought to be easier because of his assistance. Any stumbles at this stage are entirely of my own making. > I'm not a suitable person to develope language, I'll be a user of it. > However, the sceen I'm now experiencing looks like strange to me. > > Any considerations? > > Kenji The end product I envisage is a convergence of the Go release with its Plan 9 port, ideally by including all necessary elements in the Go distribution. But we're a long way from there, the current Go distribution is heavily oriented towards compiling using GCC which means that providing a parallel build using tools that are very closely related to the very tools that are being generated, is an ambitious objective. At this point this is also to some extent in conflict with the present approach. Nevermind that bash is also used extensively in the build, which creates another significant barrier between the two environments. So you'll need to forgive me if my approach is slow and seemingly unfruitful, the distant objectives are more important to me than immediate gratification. In my defence, progress is being made and there is room for contribution. The use of Code Review as set up specifically for purposes such as this is the key to my approach and others are welcome to participate. Note that I'm not a language developer either. Programming languages are a facet of my interest in Computer Science, but in this case my efforts are almost mechanical, a port to Plan 9 without much effort towards enhancing the code under consideration. This is one of the agreed compromises between me and Russ, he convinced me that changes to the code base at this point ought to be kept to a minimum. Eventually, I intend to break out of that jail, but right now I believe that Russ' approach is best for both parties. In passing, will you please post the URL for "his repository on google" you mention above? I may be one of those many who do not know about it (unless of course you're speaking of the official Mercurial repository). Feel free to ask for any additional explanations. ++L
Re: [9fans] mail client; general question web vs command
>> If anyone does this, I also suggest using Russ' rc version >> (ported to Plan 9) of Acme Mail, instead of adapting the C >> code. russ has an rc version of acme mail? russ
Re: [9fans] mail client; general question web vs command
>russ has an rc version of acme mail? > >russ you need to keep up!
Re: [9fans] Status of port of Go to Plan 9
> what's a good recipe for making goose? :) I omitted (src) (...) lib9 goos.c from /go/devproto. Please add goos.c and its containing directory. ++L
Re: [9fans] mail client; general question web vs command
On Tue, Aug 2, 2011 at 8:02 AM, Charles Forsyth wrote: > >russ has an rc version of acme mail? > > > >russ > > you need to keep up! > > Sorry, you weren't' meant to read that. That email was from the future. My bad... let me just plug this time stability thingy back into this food processor looking doodad. Dave
Re: [9fans] Status of port of Go to Plan 9
>> what's a good recipe for making goose? :) > > I omitted > > (src) > (...) > lib9 > goos.c > > from /go/devproto. Please add goos.c and its containing directory. > There are one or two gotchas. I have tidied up, but they may be lurking on your system from earlier instances: 1. src/cmd/gc/mkopnames.rc must have execute permissions, make sure it does. 2. src/cmd/gc/opnames.h may have been built with zero size if mkopnames.rc did not have execute permissions. Delete it if that is the case, it will be rebuilt. 3. src/cmd/gc/y.tab.[ch] may be wrong: the correct versions are much bigger than a few hundred bytes, get fresh copies if you have the smaller ones. These problems have tripped me, not only Skip. There is a remaining known problem. The yacc targets, src/cmd/gc/y.tab.[ch], have to be built using GNU Bison, at least until I get the nerve to add the error file to yacc or to use fgb's infrastructure to build GNU Bison on Plan 9. I recommed that you generate recent versions of these files on a Go target and copy them to a safe spot from where you can retrieve them as needed. The "mkone" clean target deletes them and changing that will create its own brand of problems. I'm waiting for the next set of problems I don't yet know about :-) ++L
[9fans] plan9port: cocoa programmer needed
I have updated plan9port to build and run on OS X Lion. Everything works except devdraw, the binary that handles putting windows on the screen and managing the mouse and keyboard. Devdraw was written 3 years ago, using the Carbon framework. Apple wants to retire that framework, so they have been slowly chipping away at its functionality. It is time to convert $PLAN9/src/cmd/devdraw/osx-screen-carbon.m to Cocoa. There is a previous attempt in osx-screen.m, but I would not start with that, because it has not kept up with recent changes (like Multitouch) and bug fixes. The Carbon source is a better starting point. Is there anyone out there who knows Cocoa and Objective C well enough that this would be very easy? I am sure I could figure it out given enough time, but enough here is likely quite large. It would also be nice to convert $PLAN9/src/cmd/fontsrv/osx.c, but that is much lower priority, as it appears to build okay still. Thanks. Russ
Re: [9fans] mail client; general question web vs command
> I've been using a gmail account with the usual access via a web > browser for quite a while. > Sometimes I get little angry when using it, for various reasons, often > due to the firefox's slowness to render the page (scrolling a longer > thread is often pain for me). > I'd like to ask you. Do you use some client like e.g. mutt / heirloom > mailx / some plan9 client, and find its utility superior to a > web-based way? At Flock we used Gmail as our corporate email service :-P I just pointed upas/fs at Google's IMAP servers and carried on using Acme Mail and nedmail as usual. htmlfmt(1) is a superior HTML mail reader, in my books. Using a small rc script it was trivial to run two distinct mail client instances on my terminal — one pointed at Google for work mail, the other pointed at my own IMAP server for personal mail. Like Eric, I used nedmail as a dumb threading tool. It was very useful as a brute force defence against all the cron spam our servers sent out. I would run a script that invoked nedmail to whack all the usual suspects based on subject, from, and to headers, then read the leftovers in Acme. Upas also made it very simple to write adhoc scripts to usefully process all that cron spam, something you'll never be able to do with a webmail client. --lyndon
[9fans] cheep ssds
i just got a 40gb intel ssd for building up a new file server. i really wasn't expecting 275 out of a theoretical 300mb/s. maybe i forgot how to count and it's actually 27.5. :-) blakely# time dd -if /dev/sdE0/data -of /dev/null -bs 512k -count 100 100+0 records in 100+0 records out 0.00u 0.01s 0.19rdd -if /dev/sdE0/data -of /dev/null ... blakely# hoc 512*1024*100/0.19 275941052.6316 - erik
Re: [9fans] plan9port: cocoa programmer needed
I was with you till the "very easy" part. Been following the updates today and noted that (earlier) the portion of INSTALL that detects the architecture on Darwin was not working. Had a patch for that and regrettably blew it away (accident), then had to turn my attention to something else. May try again tomorrow if it persists... As for the Cocoa bits ( cocoa bits) I might get some time to work that a bit this weekendif no other takers rise up. Dave On Tuesday, August 2, 2011, Russ Cox wrote: > I have updated plan9port to build and run on > OS X Lion. Everything works except devdraw, > the binary that handles putting windows on the > screen and managing the mouse and keyboard. > > Devdraw was written 3 years ago, using the > Carbon framework. Apple wants to retire > that framework, so they have been slowly > chipping away at its functionality. It is time to > convert $PLAN9/src/cmd/devdraw/osx-screen-carbon.m > to Cocoa. There is a previous attempt in osx-screen.m, > but I would not start with that, because it has not kept > up with recent changes (like Multitouch) and bug fixes. > The Carbon source is a better starting point. > > Is there anyone out there who knows Cocoa and > Objective C well enough that this would be very easy? > I am sure I could figure it out given enough time, > but enough here is likely quite large. > > It would also be nice to convert > $PLAN9/src/cmd/fontsrv/osx.c, but that is > much lower priority, as it appears to build > okay still. > > Thanks. > Russ >
Re: [9fans] cheep ssds
On Wednesday 03 of August 2011 05:53:51 erik quanstrom wrote: > i just got a 40gb intel ssd for building up a new file > server. i really wasn't expecting 275 out of a theoretical > 300mb/s. maybe i forgot how to count and it's actually > 27.5. :-) ah, marketing. megabits per second, rather than megabytes. nb., SATAII isn't twenty times faster than PATA, just two times. 3GBit minus 8/10 encoding. -- dexen deVries [[[↓][→]]] For example, if the first thing in the file is: an XML parser will recognize that the document is stored in the traditional ROT13 encoding. (( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))
