Re: [9fans] acme Put doesn't save
It really seems that acme-sac does save in the described way (at least it saves). That makes me wonder. Do plan9 acme, p9p acme and acme-sac have more similar differences? Are the programs separate in their development? Thanks Ruda > personally, i think that Put should work on any non-application > window, and that re-columnation should only take place if > the textual content hasn't been modified by the user. (and > probably also that if you change the name of a window to a directory > name and do "Get", that it would get a directory listing). > > but YMMV as always. > >
Re: [9fans] acme Put doesn't save
On Fri, Mar 6, 2009 at 10:48 AM, Rudolf Sykora wrote: > It really seems that acme-sac does save in the described way (at least > it saves). That makes me wonder. Do plan9 acme, p9p acme and acme-sac > have more similar differences? Are the programs separate in their > development? Acme-sac is based on the Inferno Acme, which is written in limbo and has a few minor discrepancies to the P9 acme (for example, backspace with text selected only deletes the selected text, it doesn't delete the character prior to it). Acme-sac is a life saver on windows. I couldn't live without it. Big thank yous go out to caerwyn for this work. Robby
Re: [9fans] GSoC 2009
Great ! And how about mentors ??? Who wanna be mentor ? 2009/3/5 Uriel > As Sergey pointed out, there is a google groups for discussing this > topics (there is also one only for mentors if you like, where I think > both of you are members). > > http://groups.google.com/group/plan9-gsoc > > I have started to work on bringing http://gsoc.cat-v.org up to date... > > uriel > > On Thu, Mar 5, 2009 at 3:49 PM, Devon H. O'Dell > wrote: > > 2009/3/4 Anthony Sorace : > >> So, the web site's up, program is announced, and so on. > >> > >> Was anyone planning on doing a Plan 9 application? I'm willing to > >> help, if anyone was planning on it, or lead, if not. In the later > >> case, I'd appreciate help (any of advice, materials, or labor) from > >> people who were involved in our last two applications. > >> > >> Anthony > > > > Anthony, > > > > Let's catch up off-list to discuss this. There's a bunch of stuff to do. > > > > --dho > > > > > > -- С наилучшими пожеланиями Жилкин Сергей With best regards Zhilkin Sergey
[9fans] smart monitoring
i put a small program, disk/smart, on sources that does simple smart monitoring for scsi and ata disks. contrib/install quanstro/smart for ata disks, quanstro/sd is required. atapi devices could be monitored via ata or or scsi commands or both, but i don't have access to any devices that support either. for example, chula# disk/smart -at sdE0: normal sda2: normal sda1: normal sda0: normal one final note, i found last night that amd sb690 ahci has some bugs that cause smart to generate incorrect output. i'm testing some fixes. thanks to steve for putting up with earlier versions. bug report, comments, critique welcome. - erik
[9fans] C Programming in Plan 9 from Bell Labs
Hi, does anyone know of (or has) a pdf (ps) version of Pietro's C Programming in Plan 9 from Bell Labs? I was trying to print it from cat-v.org but for some reason I am not able to do so. Saludos -- Hugo
Re: [9fans] Google Summer of code 2009
> I heard that there will be a GSoC this year, are there > any plans to get plan 9 as a mentoring organization? There has been some discussion about this among the people who put together last year's application. For whatever mixture of factors, we ended up "below the line" last year. This year more groups are expected to apply, and Google has indicated they plan to support fewer groups and fewer students this year as compared to last year. Each of those trends seems likely to push us further "below the line" if we submit a similar application again this year. For that reason, the thinking is that this summer we should pursue alternative courses of action. Examples might include organizing some bug-fixing weekends or install fests, improving performance and usability of Plan 9 in various VM's (since this is probably the safest way to ensure that a new user's install works the *first* time)... Next year maybe we'll be different, and maybe GSoC will be different. Dave Eckhardt
Re: [9fans] Google Summer of code 2009
uh, sorry to hear that. Well, maybe next year... Saludos 2009/3/6, Dave Eckhardt : > > I heard that there will be a GSoC this year, are there > > any plans to get plan 9 as a mentoring organization? > > > There has been some discussion about this among the people who > put together last year's application. > > For whatever mixture of factors, we ended up "below the line" > last year. This year more groups are expected to apply, and > Google has indicated they plan to support fewer groups and > fewer students this year as compared to last year. Each of > those trends seems likely to push us further "below the line" > if we submit a similar application again this year. > > For that reason, the thinking is that this summer we should > pursue alternative courses of action. Examples might include > organizing some bug-fixing weekends or install fests, improving > performance and usability of Plan 9 in various VM's (since this > is probably the safest way to ensure that a new user's install > works the *first* time)... > > Next year maybe we'll be different, and maybe GSoC will be > different. > > > Dave Eckhardt > > -- Hugo
Re: [9fans] threads vs forks
Clojure is definitely something that I would like to play with extensively. Looks very promising from the outset, so the only question that I have is how does it feel when used for substantial things. Thanks, Roman. P.S. My belief in it was actually reaffirmed by a raving endorsement it got from an old LISP community. Those guys are a bit like 9fans, if you know what I mean ;-) On Tue, 2009-03-03 at 10:38 -0800, Bakul Shah wrote: > On Tue, 03 Mar 2009 10:11:10 PST "Roman V. Shaposhnik" wrote: > > On Tue, 2009-03-03 at 07:19 -0800, David Leimbach wrote: > > > > > My knowledge on this subject is about 8 or 9 years old, so check with > > > your > > local Python guru > > > > > > > > > The last I'd heard about Python's threading is that it was cooperative > > > only, and that you couldn't get real parallelism out of it. It serves > > > as a means to organize your program in a concurrent manner. > > > > > > > > > In other words no two threads run at the same time in Python, even if > > > you're on a multi-core system, due to something they call a "Global > > > Interpreter Lock". > > > > I believe GIL is as present in Python nowadays as ever. On a related > > note: does anybody know any sane interpreted languages with a decent > > threading model to go along? Stackless python is the only thing that > > I'm familiar with in that department. > > Depend on what you mean by "sane interpreted language with a > decent threading model" and what you want to do with it but > check out www.clojure.org. Then there is Erlang. Its > wikipedia entry has this to say: > Although Erlang was designed to fill a niche and has > remained an obscure language for most of its existence, > it is experiencing a rapid increase in popularity due to > increased demand for concurrent services, inferior models > of concurrency in most mainstream programming languages, > and its substantial libraries and documentation.[7][8] > Well-known applications include Amazon SimpleDB,[9] > Yahoo! Delicious,[10] and the Facebook Chat system.[11] >
Re: [9fans] Google Summer of code 2009
Uhu? Who 'decided' this? And where was this 'discussed'? Certainly not in any of the Plan 9 GSoC lists. It is total nonsense not to apply based on pure speculation, and you can be certain there will be an application, whatever it will be accepted or not, who knows, and what evidence there is that things will be any better a year from now? Hackathons, and other 'events' have been proposed in the past, and nobody has shown any interest in them other than to ridicule the concept. Five, four, and three years ago people were saying the same nonsense, and nobody ever did anything, until somebody got feed up and applied, some things went very wrong, but other useful stuff came out of it. I have yet to see anything useful come from the attitude reigning in other parts of the 'community' though, maybe ten years from now the new 64 bit kernel will be released... uriel P.S.: Also note that as far as I know Glendix and suckless.org will be applying, Inferno DS might, and Inferno OS should certainly apply too, but I'm not counting on it. On Fri, Mar 6, 2009 at 6:31 PM, hugo rivera wrote: > uh, sorry to hear that. > Well, maybe next year... > Saludos > > 2009/3/6, Dave Eckhardt : >> > I heard that there will be a GSoC this year, are there >> > any plans to get plan 9 as a mentoring organization? >> >> >> There has been some discussion about this among the people who >> put together last year's application. >> >> For whatever mixture of factors, we ended up "below the line" >> last year. This year more groups are expected to apply, and >> Google has indicated they plan to support fewer groups and >> fewer students this year as compared to last year. Each of >> those trends seems likely to push us further "below the line" >> if we submit a similar application again this year. >> >> For that reason, the thinking is that this summer we should >> pursue alternative courses of action. Examples might include >> organizing some bug-fixing weekends or install fests, improving >> performance and usability of Plan 9 in various VM's (since this >> is probably the safest way to ensure that a new user's install >> works the *first* time)... >> >> Next year maybe we'll be different, and maybe GSoC will be >> different. >> >> >> Dave Eckhardt >> >> > > > -- > Hugo > >
Re: [9fans] Google Summer of code 2009
* * organizing some bug-fixing weekends or install fests, improving performance and usability of Plan 9 in various VM's (since this is probably the safest way to ensure that a new user's install works the *first* time)... I sent a Plan9 Qemu qcow to the osZoo people a while ago but never eben got a reply. I just checked again now and they've got a different submissions system http://www.oszoo.org/wiki/index.php/FreeOsZoo:Submission_Guidelines So time to re-do it, I'll do it when I get a minute, unless someone beats me to it :) Matt
Re: [9fans] Google Summer of code 2009
uriel, remain calm. he said the discussion was among the people who ran last year's application. that's fine: they can have whatever conversations they like, wherever they like. if they've decided their time is better spent elsewhere, that's their decision. on the specific actions suggest, too, i'm all for them. it sounds like they're thinking about some very directed actions that could get good results. and those sorts of actions also, in my estimation, match with the sorts of "community" considerations Google uses for evaluation. there's certainly no conflict there. for myself, i still think a GSoC application is worth the time, and I still intend to do one.
Re: [9fans] Google Summer of code 2009
If anyone is looking for projects I am working on USB and it's for sure there will be many drivers that could be done once the controller drivers get finished, what shouldn't take much time now. I'm willing to help anyone willing to work on such "projects". Acpi is also needed asap. Probably it's better to get working and forget about gsoc before doing something. IMHO El 06/03/2009, a las 21:27, ano...@gmail.com escribió: uriel, remain calm. he said the discussion was among the people who ran last year's application. that's fine: they can have whatever conversations they like, wherever they like. if they've decided their time is better spent elsewhere, that's their decision. on the specific actions suggest, too, i'm all for them. it sounds like they're thinking about some very directed actions that could get good results. and those sorts of actions also, in my estimation, match with the sorts of "community" considerations Google uses for evaluation. there's certainly no conflict there. for myself, i still think a GSoC application is worth the time, and I still intend to do one. [/mail/box/nemo/msgs/200903/35660]
Re: [9fans] threads vs forks
Things like Clojure, or Scala become a bit more interesting when the VM is extended to allow tail recursion to happen in a nice way. On Fri, Mar 6, 2009 at 10:47 AM, Roman V Shaposhnik wrote: > Clojure is definitely something that I would like to play > with extensively. Looks very promising from the outset, > so the only question that I have is how does it feel > when used for substantial things. > > Thanks, > Roman. > > P.S. My belief in it was actually reaffirmed by a raving > endorsement it got from an old LISP community. Those > guys are a bit like 9fans, if you know what I mean ;-) > > > On Tue, 2009-03-03 at 10:38 -0800, Bakul Shah wrote: > > On Tue, 03 Mar 2009 10:11:10 PST "Roman V. Shaposhnik" > wrote: > > > On Tue, 2009-03-03 at 07:19 -0800, David Leimbach wrote: > > > > > > > My knowledge on this subject is about 8 or 9 years old, so check with > your > > > local Python guru > > > > > > > > > > > > The last I'd heard about Python's threading is that it was > cooperative > > > > only, and that you couldn't get real parallelism out of it. It > serves > > > > as a means to organize your program in a concurrent manner. > > > > > > > > > > > > In other words no two threads run at the same time in Python, even if > > > > you're on a multi-core system, due to something they call a "Global > > > > Interpreter Lock". > > > > > > I believe GIL is as present in Python nowadays as ever. On a related > > > note: does anybody know any sane interpreted languages with a decent > > > threading model to go along? Stackless python is the only thing that > > > I'm familiar with in that department. > > > > Depend on what you mean by "sane interpreted language with a > > decent threading model" and what you want to do with it but > > check out www.clojure.org. Then there is Erlang. Its > > wikipedia entry has this to say: > > Although Erlang was designed to fill a niche and has > > remained an obscure language for most of its existence, > > it is experiencing a rapid increase in popularity due to > > increased demand for concurrent services, inferior models > > of concurrency in most mainstream programming languages, > > and its substantial libraries and documentation.[7][8] > > Well-known applications include Amazon SimpleDB,[9] > > Yahoo! Delicious,[10] and the Facebook Chat system.[11] > > > > >
Re: [9fans] Porter-Duff alpha blending
Thanks for tracking this down and pointing out where the error is. There are actually a handful of errors in that code. Assume a source value sv, source alpha sa, mask alpha ma, destination value dv, and destination alpha da. The values sv and dv are stored premultiplied by their corresponding alphas (the one true way). Given those values, the correct new values for the destination pixel in an S over D op are: dv = (sv*ma + dv*(255-sa*ma)) / 255 da = (sa*ma + da*(255-sa*ma)) / 255 Bug #1: The current draw.c does the division separately on the two halves: dv = (sv*ma)/255 + (dv*(255-sa*ma))/255 This can be off by one if the remainders from the two divisions sum to >= 255. Bug #2: The MUL0123 macro assumes four values are packed into a 32-bit int and runs them in simultaneous pairs as 32-bit operations (MUL02 and MUL13) operating on 16-bit halves of the word. Those two don't use the right rounding for the bitwise op implementation of /255. On a single value, the implementation is x / 255 == (t = x+1, (t+(t>>8))>>8) (x+127) / 255 == (t = x+128, (t+(t>>8))>>8) These calculations only need 16 bits so you can run two of them in the two halves of a 32-bit word. The second implements round-to-nearest and is what the draw code tries to do in this case. But it only adds 128 (0x80), so it only rounds the bottom half correctly. It needs to add 0x00800080, which would round both of them. This explains: src rFF gFF bFF αFF mask kFF αFF dst r00 g00 b00 αFF dst after calc rFE gFE bFF αFF Bug #3: MUL0123 is enabled whenever the src and dst both have 32-bit pixel width, but there is no check that the sub-channels are in the same order. You don't say what the image chans were in your test, but this: src rFF g00 b00 αFF mask kFF αFF dst r00 g00 b00 αFF dst after calc rFE gFE b00 α00 would be explained by, say, src==ARGB and dst==RGBA. The A and R values in src became the R and G chans in dst. (In fact, since the dst R and G are FE not FF, that's almost certainly the scenario, modulo the little-endian draw names.) This one is similarly explained: src rCC g00 b00 αCC mask kFF αFF dst r00 g00 b00 αFF dst after calc rCB gCB b00 α33 The destination got scaled by 0x33/0xFF, leaving 00 00 00 33, and then the source, cc 00 00 cc, was added in the wrong place, using the incorrect rounding, to produce cb cb 00 33. I have corrected these bugs in the plan9port copy of src/libmemdraw/draw.c and finally get the right answer for Andrey's test (attached). I leave it as an exercise to the interested reader to port the changes to the other dozen copies of libmemdraw that are floating around, or to unify them all. Russ <>
Re: [9fans] Porter-Duff alpha blending
> Bug #3: MUL0123 is enabled whenever the src > and dst both have 32-bit pixel width, but there is > no check that the sub-channels are in the same > order. You don't say what the image chans were > in your test, but this: > > src rFF g00 b00 αFF > mask kFF αFF > dst r00 g00 b00 αFF > dst after calc rFE gFE b00 α00 > > would be explained by, say, src==ARGB and > dst==RGBA. The A and R values in src became > the R and G chans in dst. (In fact, since the dst > R and G are FE not FF, that's almost certainly > the scenario, modulo the little-endian draw names.) it was indeed ARGB/RGBA (or the other way around) as I had focused testing only on those two. thanks for the explanation!
Re: [9fans] Google Summer of code 2009
> Acpi is also needed asap. what's the pressure point here? - erik
Re: [9fans] Google Summer of code 2009
On Fri, Mar 6, 2009 at 3:59 PM, erik quanstrom wrote: >> Acpi is also needed asap. > > what's the pressure point here? > The number of mainboards that have incorrect PIR, MP, tables that are correct in ACPI. The fact that so many functions, for correct operation, need ACPI. It's a mess. ACPI sucks. But it's what we have to work with. ron
Re: [9fans] Google Summer of code 2009
> > what's the pressure point here? > > > > The number of mainboards that have incorrect PIR, MP, tables that are > correct in ACPI. The fact that so many functions, for correct > operation, need ACPI. > > It's a mess. ACPI sucks. But it's what we have to work with. this is just my perspective on the matter, but i find the mp tables often get fixed, and when they don't the results are mostly annoying. my core i7 motherboard, for example, doesn't see it's ht processors. i can live with that. i still have 4. (the biggest sticking point with the mp tables is the interrupts. this can also be fixed by using msi interrupts. i think that would offer a bigger bang/buck factor. the performance of 8259 or even mp interrupts is pretty poor.) on the other hand, nvidia graphics drive me bats. it would make a bigger difference to me to have good amd or intel gma graphics support. just my own perspective. maybe i'm out of touch and have just been lucky picking motherboards. that's not to say acpi isn't a good thing to get done. it's just that personally i'd rank it lower than a few other things. ymmv. - erik
Re: [9fans] threads vs forks
On Fri, 06 Mar 2009 10:47:20 PST Roman V Shaposhnik wrote: > Clojure is definitely something that I would like to play > with extensively. Looks very promising from the outset, > so the only question that I have is how does it feel > when used for substantial things. You can browse various Clojure related google groups but there is only one way to find out if it is for you! > P.S. My belief in it was actually reaffirmed by a raving > endorsement it got from an old LISP community. Those > guys are a bit like 9fans, if you know what I mean ;-) No comment :-)
[9fans] amd sb690 ahci bug with atapi
there is a hardware errata with the amd 690 southbridge that has been causing some funny results on my terminal's dvd drive for some time now. i finally hunted it down last night. my contrib sd package has the fix. unfortunately, i also happen to own a dvd drive that loves to set check condition: no media present sense codes in response to "test unit ready" and other commands most dvd drives just are happy to let pass. i believe this is the same problem that led to this comment in sdata.c /* used to test as&Chk as failure too, but some CD readers use that for media change */ unfortunately, i found that it was pretty hard to just ignore the sense code with scuzz, so i submitted a scuzz patch that ignores no media errors, too. (cdfs is impervious to these errors.) - erik
Re: [9fans] threads vs forks
> P.S. My belief in it was actually reaffirmed by a raving > endorsement it got from an old LISP community. Those > guys are a bit like 9fans, if you know what I mean ;-) You mean intelligent people who appreciate elegance? :) Sorry. Couldn't resist. BLS
Re: [9fans] Google Summer of code 2009
> For whatever mixture of factors, we ended up "below the line" > last year. This year more groups are expected to apply, and > Google has indicated they plan to support fewer groups and > fewer students this year as compared to last year. Each of > those trends seems likely to push us further "below the line" > if we submit a similar application again this year. As it turns out, I was in a presentation today given by the key SOC people from Google. The thing that really caught my attention was that they made a point of saying that they gave particular preference to projects/groups that would put forward mentors that they could be confident would have a successful project completion. That's not to say that they don't have confidence in the mentors from Plan9 and Inferno, but that does seems to be a lot of what goes into the placement of that line. As to how many groups and students, they didn't say anything about that other than to show that each year the numbers had increased. They also said the money pool was planned to be the same as last year. BLS
Re: [9fans] threads vs forks
> To be less flippant, what makes high performance flash difficult > is the slow erasure time and large erasure blocks relative to > the size of individual flash pages. Being full hurts since the > flash is typically managed by a log structured storage system > with a garbage collector. Small random writes require updating > the logical->physical mapping efficiently and crash recoverably. > You also need to do copy-on-write which leads to what is commonly > called write amplification, which reduces the usuable number of > writes. Small writes tend to exacerbate a lot of these problems. > > Where does all this fancy stuff belong? In the storage medium, > in the HBA, in the device driver, in the file system, or in the > application? it's interesting to note that the quoted mtbf numbers for ssds is within a factor of 2 of enterprise hard drives. if one considers that one needs ~4 ssds to cover the capacity of 1 hard drive, the quoted mtbf/byte is worse for ssd. the obvious conclusion is that if you think you need raid for hard drives, then you also need raid for ssds. at least if you believe the mtbf numbers. i think that it's a real good question where the fancy flash tricks belong. the naive guess would be that for backwards compatability reasons, the media will get much of the smarts. - erik
Re: [9fans] Google Summer of code 2009
> It's a mess. ACPI sucks. But it's what we have to work with. I don't know about ACPI, but it struck me that Plan 9 was in a far batter position to deal with the foibles of USB than any other OS I am familiar with (IMO, PCI was similar, but the opportunity was missed), I'm pleased Nemo is able to provide help there. ++L
Re: [9fans] threads vs forks
> Where does all this fancy stuff belong? In the storage medium, > in the HBA, in the device driver, in the file system, or in the > application? In a very intelligent cache? Or did you mention that above and in my ignorance I missed it? OK, let's try this: . Storage medium: only the hardware developers have access to that and they have never seemed interested in matching anyone else's requirements or suggestions. . The HBA (?). If that's the device adapter, the same applies as above. . The device driver should not be very complex and the block handling should hopefully be shared by more than one device driver, which with the effective demise of Streams is not a very easy thing to implement without resorting to jumping through flaming hoops. . The application? That's being facetious, surely? . A cache? As quanstro pointed out, flash makes a wonderful WORM. Now to get Fossil to work as originally intended, or a more suitable design and implementation to take its place in this role and we have a winner. ++L
Re: [9fans] Google Summer of code 2009
> I don't know about ACPI, but it struck me that Plan 9 was in a far > batter position to deal with the foibles of USB than any other OS I > am familiar with (IMO, PCI was similar, but the opportunity was > missed), I'm pleased Nemo is able to provide help there. what was missed with pci? plan 9 doesn't do pcie extended configuration space, but that's mostly a waste of 256mb. what am i missing? - erik
Re: [9fans] threads vs forks
> Much of the intelligence > actually resides in the device driver. It is that secret sauce > that gets you good performance. In theory it could be pushed > down, but it takes CPU, memory, and memory bandwidth that may > not be cost effective there. That would entail a really intelligent controller, which brings us back to a cache, does it not, this time hidden inside a black box. I have been thinking that the obsession with SMP has a negative impact on diverse engineering where intelligent peripherals take over operations that are too slow or too demanding on the generic CPU. Smacks of AoE to me, with a lot more packed into the A. But I'm just an old software developer with a hobbyist interest in electronic engineering and my opinions are not backed by much research. ++L
Re: [9fans] threads vs forks
> Sadly, if a WORM is your only application, then no one cares. > At least not enough to pony up for real peformance. The folks > at places like Sandia are interested in running HPC applications > and there are a lot of people in other industries such as big oil > and finance that are willing to pay for performance for running > HPC applications, VMs which tend to have high I/O requirements when > an OS patch comes out, etc. ask not what a technology can do for the world, ask what a technology can do for you! - erik
