Re: [9fans] where does drawterm get bufimage?
On Wed, Dec 30, 2009 at 5:23 PM, kokam...@hera.eonet.ne.jp wrote: gcc -o drawterm main.o cpu.o readcons.o secstore.o latin1.o That fails on OS X 10.6, You need to add -m32 option to gcc for OXS 10.6. Oh, boy, I'm just a newbie to OSX world.☺ Kenji Depends actually. If you're on a 32bit Intel, I think without -m32 you're probably ok, but it's best to be safe. Note you don't need to be running the 64bit kernel to get the 64bit binaries to work either. In fact, I'm not sure I'd recommend the 64bit kernel unless your machine boots to it on it's own. Dave
Re: [9fans] Broken Hardware List
On Wed, Dec 30, 2009 at 6:44 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) lyn...@orthanc.ca wrote: i believe that richard miller has the intel D945GCLF2 working via some careful hacking. (i.e. a hand-coded mp table.) It was easier to buy something that actually worked. As for that Intel piece of shit, I'm going to blend it during the transition to 2010. --lyndon Blendtech?
Re: [9fans] Sheevaplug
On Mon, Dec 14, 2009 at 10:33 AM, ron minnich rminn...@gmail.com wrote: On Mon, Dec 14, 2009 at 10:12 AM, erik quanstrom quans...@coraid.com wrote: what's the replacement for pxe? Why not 9p? BOOTP + 9p? ron
Re: [9fans] SheevaPlug
i wonder if there's a complicated volume pricing thing going on where these companies take orders, accumulating volume so they increase their margins before they ship. I can't imagine why else they'd drag their feet on it except that they want to get a good price as a reseller, and don't want to be sitting on a lot of inventory. Dave On Sat, Dec 5, 2009 at 4:17 AM, Lluís Batlle virik...@gmail.com wrote: Mine I bougth some months ago, also from globalscale. They took more than one month to ship it, but after their notice about the shipment, it came in two days. It came in a nice packaging box, with all the cables, and a CD with the source code. 2009/12/5 Francisco J Ballesteros n...@lsub.org: ours is still on its way, from globalscale tech. They took at least 3 weeks to ship our order. Finally they did, but as I said, still on the way, despite choosing a good delivery. But that may be only when you buy from europe. On Sat, Dec 5, 2009 at 7:29 AM, Don Bailey don.bai...@gmail.com wrote: So, what is everyone's preferred plug vendor? Out of the three, is there a preference for people out there hacking on the Sheeva? Thanks, D
Re: [9fans] OT concurrent C
libdispatch is in FreeBSD now, and people are using it to write concurrent C code. I think they even have blocks, and the clang compiler front end working too. I believe the earliest, least-experimental branch of code is FreeBSD-STABLE for the 8 series, but I'll double check. Dave On Thu, Dec 3, 2009 at 3:14 AM, kokam...@hera.eonet.ne.jp wrote: distant ancestor of alef? and alef's descent may be Go.☺ Kenji
Re: [9fans] grëp (rhymes with creep) and cptmp
On Mon, Nov 30, 2009 at 6:48 AM, roger peppe rogpe...@gmail.com wrote: 2009/11/30 erik quanstrom quans...@quanstro.net: i used unfold (/n/sources/contrib/quanstro/runetype/unfold.c. % 8c -I ../grepfold unfold.c unfold.c:5 8c: 'utfunfold.h' file does not exist: utfunfold.h % du -a /n/sources/contrib/quanstro | grep utfunfold.h % forgive me for not reading the source code, but what does unfold do? Also didn't read the source... sounds functionally delicious. :-)
Re: [9fans] 9P libraries for Go
I think they might just be with their families as it's a national holiday here in the USA. :-) Might not hear from them again till Monday. Dave On Wed, Nov 25, 2009 at 8:18 AM, Latchesar Ionkov lu...@ionkov.net wrote: I did four days ago. No comments yet. I am sure the go team is pretty busy at the moment. Lucho On Wed, Nov 25, 2009 at 9:05 AM, Devon H. O'Dell devon.od...@gmail.com wrote: 2009/11/25 Latchesar Ionkov lu...@ionkov.net: I added a Makefile in the repository that builds the packages outside of the go tree. Any plans for filing a CL to add those to Go's src/pkg repo? I'm sure it would be welcomed. --dho Thanks, Lucho On Mon, Nov 23, 2009 at 7:04 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Sun, Nov 22, 2009 at 8:38 PM, Latchesar Ionkov lu...@ionkov.net wrote: Hi, Andrey Mirtchovski and I wrote 9P server and client libraries/packages for Go. Perfect The hg repository with the code is available at http://bitbucket.org/f2f/go9p/. Once downloaded the code should be moved to $GOROOT/src/pkg and $GOROOT/src/pkg/Makefile should be modified so DIRS includes plan9/p, plan9/p/clnt and plan9/p/srv directories. These directories should also be added to the NOTEST variable. Could this be added to README, or better yet automated somehow? Thanks, Roman.
Re: [9fans] Where can i get teh code of the Paln 9
For those of us who didn't see TVX, what's TVX? :-) On Mon, Nov 23, 2009 at 2:06 PM, ron minnich rminn...@gmail.com wrote: And, if your hardware won't work, i really strongly recommend you look at 9vx. http://swtch.com/9vx/ Those of you who say TVX at IWP9 last month: on a recent trip to tahiti I took a diskless laptop (T23, disk removed) and TVX was really very usable on that 8-year-old, small machine, where ubuntu was quite unusable. The more I use TVX the more I find it quite nice as a Plan 9 on a hardware platform that is unfriendly to Plan 9 system. ron
Re: [9fans] Where can i get teh code of the Paln 9
On Mon, Nov 23, 2009 at 5:10 PM, ron minnich rminn...@gmail.com wrote: On Mon, Nov 23, 2009 at 5:02 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) lyn...@orthanc.ca wrote: I'll put up a youtube movie in the next while, but there is a video of iwp9 I think on the subject. And for those of us using only Plan9 to troll the Interweeb, isn't there a one paragraph text summary someplace? Sorry. It is a tinycorelinux USB stick somewhat (but not much!) customized with a 9vx installation. It runs really well on old, small systems and really fast on new ones. I included 9vx, the vx32 mercurial tree, and mercurial and gcc toolchain so you can update 9vx, hack the source, and build a new 9vx kernel. Thus, you've got a small (well, 1G anyway; a cheap USB stick nowadays) image that gives you a full Plan 9 environment but works on almost any hardware. ron Excellent! :-) I've had some odd troubles in the past getting 9vx to behave in all the same ways as a regular Plan 9 machine, but then I think most of those had been addressed on 9fans at some point. Seemed like some of them were around networking and such.
Re: [9fans] sheevaplug port available
Awesome! Thanks Geoff!
On Tue, Nov 17, 2009 at 1:37 PM, ge...@plan9.bell-labs.com wrote:
If you run replica/pull (or have done so recently), you'll find a new
kernel subtree, /sys/src/9/kw, which contains a basic port of Plan 9
to the Sheevaplug, derived from the port of native Inferno. 9plug is
a diskless cpu server supporting a serial console and gigabit
ethernet. booting(8) and /sys/doc/port.* have been updated to match.
`kw' stands for Kirkwood, the Marvell system-on-a-chip that the
Sheevaplug is based upon. There are more Kirkwood systems on the way.
What's not yet in this port: access to flash memory, USB devices,
memory cards and possibly more. The documentation for Kirkwood flash
and USB is some combination of vague, obscure, incomplete,
unavailable, contradictory and tediously voluminous. If you configure
in the USB drivers, you'll find that there appears to be an
unpopulated root hub, but that may be a figment of the usb driver's
imagination. The EHCI registers do seem to be present and we probably
just need to tweak some undocumented register to make it all go.
If you only been building 386 binaries to date, you'll want to edit
/sys/src/mkfile.proto to at least include the arm architecture:
OS=58
CPUS=arm 386
and make sure all your /386/bin compiler binaries are up to date:
cd /sys/src/cmd
for(i in ?c)
if(! ~ $i cc rc) @{
cd $i
mk clean
objtype=$cputype mk install
mk clean
}
and populate your /arm tree:
cd /sys/src
objtype=arm mk install
You should then be able to build a sheeva kernel:
cd /sys/src/9/kw
mk 'CONF=plug' install # `mk install' will work too
This should create /arm/9plug; see booting(8) to get started.
Enjoy!
Re: [9fans] Practical issue on using rc shell
On Fri, Nov 13, 2009 at 10:54 AM, Tim Newsham news...@lava.net wrote: Hi, I'm new to plan9 from user space. I've started using rc shell for scripts and, for daily use, I would like to solve a problem. I see that rc isn't built with readline or similar. So, do you use some alternative? Or do you think I can live without it? For scripting it shouldn't be an issue. For interactive use it can be a pain if you are using a normal terminal environment. In plan9 you'd usually run rc in a rio window or in acme where the environment lets you edit and reuse commands from the scrollback. If you've already got plan9 from user space, try using rc with 9term, or inside an Acme win session. Plan 9 is very mouse driven and you should use a terminal window that lets you take advantage of that interactivity. Dave Thanks, Maurício Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Re: [9fans] Google Go (off topic, but maybe it could be ported to Plan 9)
I'd love to have this anywhere, including plan 9! I was just reading over the ideas this morning, and quite frankly, I'm excited! I've been writing concurrent code in a multi-paradigm system including approaches from Haskell, Erlang, and C at my day job, so I've got my head down in a lot of this mess daily. Dave On Tue, Nov 10, 2009 at 11:28 PM, Sergey Zhilkin szhil...@gmail.com wrote: Ask Russ about Plan9 port :) 2009/11/11 Rodrigo Miranda rodrigo.mira...@acm.org: 6g, 8g, looks like a winner to me. http://arstechnica.com/open-source/news/2009/11/go-new-open-source-programming-language-from-google.ars?utm_source=rssutm_medium=rssutm_campaign=rss http://golang.org/ -- Rodrigo Miranda There is nothing like looking, if you want to find something... You certainly usually find something, if you look, but it is not always quite the something you were after. - J.R.R Tolkien -- С наилучшими пожеланиями Жилкин Сергей With best regards Zhilkin Sergey
Re: [9fans] Is this the same Russ Cox we know here?
On Tue, Nov 10, 2009 at 7:56 PM, hiro 23h...@googlemail.com wrote: have you also seen this vid? http://www.youtube.com/watch?v=rKnDgT73v8s It's amazing. I have the source right now!
Re: [9fans] Issue 9 ;-)
issue9 would be a funny name for a programming language. On Wed, Nov 11, 2009 at 5:04 PM, andrey mirtchovski mirtchov...@gmail.comwrote: i was perusing the Go Nuts mailing list briefly, boy that makes 9fans ca. 2000 look like a sensible and clever list ;) On Wed, Nov 11, 2009 at 5:54 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: http://code.google.com/p/go/issues/detail?id=9
Re: [9fans] Announcing ninefs for win32
You're a sick man! That's awesome. On Thu, Nov 5, 2009 at 1:53 PM, Tim Newsham news...@lava.net wrote: I'd like to announce ninefs for win32. This is a Dokan based 9p filesystem driver for win32 systems built with npfs. This is an early release intended for the bolder user. I've set up a mailing list for the project so please direct feedback there. http://code.google.com/p/ninefs/ http://ninefs.googlecode.com/files/README.txt http://groups.google.com/group/ninefs Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Re: [9fans] dtrace for plan 9
On Sun, Nov 1, 2009 at 9:03 PM, erik quanstrom quans...@quanstro.netwrote: Some people find the idea of writing their own kernel code scary. To those who don't I imagine d-trace has less appeal. sure thing. plan 9, by being simple, makes the kernel a much less scary place to be. by the way, many of the same people have now decided that library code is scary. :-) - erik Sometimes I find that any code at all is scary. I'm usually right too, and as a result try to minimize it.
Re: [9fans] go to this site
On Tue, Oct 27, 2009 at 8:19 AM, Wes Kussmaul w...@authentrus.com wrote: ron minnich wrote: How is it that companies that want you to buy their IT expertise outsource their own? It makes no sense. Equally true story. We used to run our own servers. A (name withheld) sysadmin always felt he knew better than management how servers should be configured and managed even when in fact he did not. So we went to Rackspace, where we are treated as customers and where sysadmins manage the resource as directed. And they're available 24/7/365. There are two sides to this. You have a point, but so does Nicholas Carr. Also distributing security patches across many islands of IT is more difficult than updating it in one place and beating the snot out of it to make sure it's right isn't it? I mean, say your company has 25 satellite offices... why should they all have to do redundant work to update all the systems across the board. Isn't the repetition going to cause a higher chance of someone missing something? Then again, you're left with the trade off of a all eggs in one basket to some extent when you outsource. How much worse is it really? I once worked for redacted company name in the late 90s. They still used a mainframe system, even though everyone connected to it with a PC on their desk, including the temps they hired (me) to do inventory stuff. This system would sometimes get a little, what I'd call, fucking slow, and yet I'd still see the logic in only maintaining that mainframe one time instead of having Nick Burns, you're company's computer guy, have to come around and fix everyone else's windows workstation when they screwed up their ability to work. My guess is productivity was up, despite the slowdowns in the network, due to the use of a centralized system. Can sticking everything in the cloud give the same benefits? I'm not 100% convinced, but to say there were no advantages to the old model is probably not realistic, though it's fun to complain about stuff instead of working, which is what I'm going to do now :-) Dave
Re: [9fans] go to this site
On Tue, Oct 27, 2009 at 8:33 AM, erik quanstrom quans...@quanstro.netwrote: I mean, say your company has 25 satellite offices... why should they all have to do redundant work to update all the systems across the board. Isn't the repetition going to cause a higher chance of someone missing something? absent the plan 9 terminal model, who updates users' machines? Right, that was the big illogical hole in the plan they had. I couldn't figure out why anyone who had everything the company needed for business production and work, would want to use a PC with local storage for a terminal system to a mainframe that basically couldn't do too much more. I guess PCs were a cheap way to go, or Dell (or whomever it was) gave them a great deal or something to make it seem it was worth their while. Even all the email was on the mainframe, but it wasn't called email, it was something else. I suppose a few people may have needed word processing or spreadsheets or whatever, but that was only because there was no way developed to do word processing or spreadsheets on the mainframe. Old stuff becoming new again shouldn't be surprising to anyone at this point though I guess. Dave - erik
Re: [9fans] So quiet!
on the contrary... I have always equated the plan 9 crowd as the most punkrock of the alternative OS crowd. On 10/23/09, W B Hacker w...@conducive.org wrote: erik quanstrom wrote: On Thu Oct 22 22:54:41 EDT 2009, eri...@gmail.com wrote: Everyone is busy drinking and debating protocol semantics. I think we've managed to empty the coraid fridge of beer. skip, sorry about that. we drank all your beer. - erik Tsk, Tsk, ..and here some of us thought that Plan9 team were all pointy-haired ivory-tower types who drank only white wine... ;-) ..ducks and waddles offstage... Bill
Re: [9fans] So quiet!
That basically encompasses what I meant by punkrock :-). On Fri, Oct 23, 2009 at 3:31 PM, dav...@mac.com wrote: I would suggest that we're the most eclectic. Try having a conversation with a bunch of 9fans that doesn't encompass several millennia of culture, technology etc. Also I'm fairly certain that a disproportionately large number of 9fans aren't CS grads. As with Un*x, it's the people who recognise the power and simplicity who are the fans, not the academic dogmatists and fashionistas. D On 23 Oct 2009, at 15:06, David Leimbach wrote: on the contrary... I have always equated the plan 9 crowd as the most punkrock of the alternative OS crowd. On 10/23/09, W B Hacker w...@conducive.org wrote: erik quanstrom wrote: On Thu Oct 22 22:54:41 EDT 2009, eri...@gmail.com wrote: Everyone is busy drinking and debating protocol semantics. I think we've managed to empty the coraid fridge of beer. skip, sorry about that. we drank all your beer. - erik Tsk, Tsk, ..and here some of us thought that Plan9 team were all pointy-haired ivory-tower types who drank only white wine... ;-) ..ducks and waddles offstage... Bill
Re: [9fans] Barrelfish
On Thu, Oct 15, 2009 at 6:11 AM, hiro 23h...@googlemail.com wrote: There is a vast range of applications that cannot be managed in real time using existing single-core technology. I'm sorry to interrupt your discussion, but what is real time? Real time just means fast enough to work properly. You can throw all kinds of other crap on top of that and say things about scheduling requirements and timeslices within which a process must complete, and duty cycles, but those are just things to look at to figure out if your system is fast enough to work properly Dave
Re: [9fans] Barrelfish
On Thu, Oct 15, 2009 at 6:52 AM, erik quanstrom quans...@quanstro.netwrote: On Thu Oct 15 09:41:29 EDT 2009, 9f...@hamnavoe.com wrote: in fact, i believe i used an apple ][ around that time that had ~744k. Are you sure that was an apple II? When I bought mine I remember wrestling with the decision over whether to get the standard 48k of RAM or upgrade to the full 64k. This was long before the IBM PC. iirc, it had an odd add in card that accounted for almost all the memory in the system. it wasn't emabled by default. - erik Was this an Apple ][ GS? I had one with an add on board with I think 1 MB of RAM. People still have those things on the internet... there's ethernet adapters for em and a TCP/IP stack. http://www.apple2.org/marinetti/index.html Dave
Re: [9fans] Barrelfish
Did you find any ideas there particularly engaging? I'm still digesting it. My first thoughts were that if my pc is a distributed heterogeneous computer, what lessons it can borrow from earlier work on distributed heterogeneous computing (ie. plan9). I found the discussion on cache coherency, message passing and optimization to be enlightening. The fact that you may want to organize your core OS quite a bit differently depending on which model cpus in the same family you use is kind of scary. The mention that ... the overhead of cache coherence restricts the ability to scale up to even 80 cores is also eye openeing. If we're at aprox 8 cores today, thats only 5 yrs away (if we double cores every 1.5 yrs). I personally thought the use of DSLs built on Haskell was rather clever, but the other discoveries are the sort of feedback I suspect our CPU vendors aren't going to think about on their own somehow :-) Roman. Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] inferno from hg does not build out of the box
On Fri, Oct 2, 2009 at 1:44 AM, roger peppe rogpe...@gmail.com wrote: 2009/10/2 Sam Watkins s...@nipl.net: could be removed if anyone fixes hg. from the way the mercurial guys go on about it, it sounds like the fix might not be trivial. it does seem like a ridiculous thing, but it seems to be something of a religious issue with them. hg doesn't do permissions (other than execute) either AFAIK. it's no substitute for tar. Wait, Hg can't deal with a directory with a file like .keepme and keep the directory!?! That's pretty silly. Or do the directories have to be 100% empty for this to work?
Re: [9fans] kencc, inferno hg, v9fs is big?, porting
On Thu, Oct 1, 2009 at 11:19 AM, ron minnich rminn...@gmail.com wrote: On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins s...@nipl.net wrote: I tried to check out v9fs, but the compressed git repo without checkout is over 300Mb. That's git for you. When you go to git it, you git ALL of it. Kind of like deciding to download sources and getting the entire venti arena. ron Wouldn't Mercurial do the same? Darcs (a haskell source control system) let's you get a subset of all the history, and if a patch refers to a really old revision you don't have, will go get that and its dependencies. It's like a lazy-repository. At least I think that's how it works, or that's how it's been explained to me. Is there a way to git a partial repository or hg a partial repository? Dave
Re: [9fans] kencc, inferno hg, v9fs is big?, porting
On Thu, Oct 1, 2009 at 11:23 AM, David Leimbach leim...@gmail.com wrote: On Thu, Oct 1, 2009 at 11:19 AM, ron minnich rminn...@gmail.com wrote: On Thu, Oct 1, 2009 at 6:23 AM, Sam Watkins s...@nipl.net wrote: I tried to check out v9fs, but the compressed git repo without checkout is over 300Mb. That's git for you. When you go to git it, you git ALL of it. Kind of like deciding to download sources and getting the entire venti arena. ron Wouldn't Mercurial do the same? Darcs (a haskell source control system) let's you get a subset of all the history, and if a patch refers to a really old revision you don't have, will go get that and its dependencies. It's like a lazy-repository. At least I think that's how it works, or that's how it's been explained to me. Is there a way to git a partial repository or hg a partial repository? Dave Darcs 2 replaces the concept of partial repositories with lazy ones. There has always been a desire to allow lightweight checkouts that don't include the complete repo history. The darcs 1 solution to this was partial repositories that only checked out history up to a point. This approach worked to some extent, but didn't play with well with darcs commands that expected the whole history to be present. The new lazy concept offers similar benefits, and will pull down older remote patches on demand if some command needs them. Lazy repositories are a great comprise between features and performance. There we go. So I guess you just need Darcs2. Dave
Re: [9fans] 9vx is really excellent, link it on the bell-labs pages?
I think it's officially a port of Plan 9's kernel to the vx32 stuff, so it's not precisely the same as running a Plan 9 box natively, or in another emulator, but it is indeed quite a feat, and close enough that most people won't notice. Personally, I'd love to be able to completely replace drawterm with 9vx, but for some reason I still have a little trouble with that setup (in fact I've not finished setting up my CPUFSAUTH server yet, so really I'm the reason for that). Another interesting project would be an Inferno based drawterm :-)... but I'd be lying if I said I had any time for that kind of fun. Dave On Wed, Sep 30, 2009 at 1:23 AM, Sam Watkins s...@nipl.net wrote: I just installed 9vx under Linux on my eee pc, it's a delight to be able to run 2 or 3 instances of plan 9 with no bother under Linux! I can't really run Plan 9 as my main OS at the moment, but it seems there's not a big performance hit to run it in 9vx. I want to say thanks! to Russ for packaging this up (and to the plan 9 devs of course), and I want to suggest that there should be a link to 9vx on the main plan 9 website. I suppose most of the people who are interested in Plan 9 would be Unix / Linux users like me, it's a very good way to try or use it for those people. Sam
Re: [9fans] linux stats in last year from linuxcon
On Mon, Sep 21, 2009 at 7:33 PM, erik quanstrom quans...@quanstro.netwrote: We're getting bloated and huge. Yes, it's a problem, said Torvalds. So may be Tanenbaum was right, after all, there's a reason we make things modular. rob, presotto, ken and phil did not agree with tanenbaum's ideas about modular kernels. this was a direct response to ast many years ago. it was hard to dig up when i did so in 2006. perhaps someone has a better link: - Microkernels are the way to go False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance. This does not mean they were saying microkernels can't be done well :-). At least I hope not, because there's a few counterexamples out there. L4 based systems are quite impressive, though their idea of a microkernel is a bit more like an advanced hypervisor, but more for something along the lines of paravirtualization. QNX is another good example of a microkernel that works quite well in practice. If by microkernel you mean Mach, and hopefully no one does anymore, then you're pretty much dead on ;-). Even the latest versions of Minix really aren't too shabby and still microkernel based. (small memory footprint, decent functionality, lots of Unix stuff work on it, and they have an interesting choice of compilers.) Are these systems more complex to reason about though? Probably :-). But when you've only got 7 system calls (per the original L4 specifications I've read over) you don't really have a lot to debug. Just gotta make sure you chose the correct primitives to compose all the software you need to write on the system. I think, in that sense, Plan 9 and some microkernels are pretty similar. Dave - erik
Re: [9fans] linux stats in last year from linuxcon
On Tue, Sep 22, 2009 at 6:48 AM, Eric Van Hensbergen eri...@gmail.comwrote: On Sep 21, 2009, at 9:33 PM, erik quanstrom wrote: We're getting bloated and huge. Yes, it's a problem, said Torvalds. So may be Tanenbaum was right, after all, there's a reason we make things modular. rob, presotto, ken and phil did not agree with tanenbaum's ideas about modular kernels. this was a direct response to ast many years ago. it was hard to dig up when i did so in 2006. perhaps someone has a better link: - Microkernels are the way to go False unless your only goal is to get papers published. Plan 9's kernel is a fraction of the size of any microkernel we know and offers more functionality and comparable or often better performance. IMHO, that statement applies to existing microkernel implementations (at the time? perhaps still?) -- its not clear to me that they inherently must be that way. Likely their use as fuel for papers and PhD's contributed to their bloat. -eric At that time, and even today, microkernels are academically bloated. However some of the more practical academics (yeah I know it's like jumbo shrimp or military intelligence) have spun very interesting things off like OKL4, which is running in several cellular telephones, and on Qualcomm equipment, possibly with a Linux personality ported to it.
Re: [9fans] linux stats in last year from linuxcon
On Tue, Sep 22, 2009 at 7:47 AM, erik quanstrom quans...@quanstro.netwrote: Are these systems more complex to reason about though? Probably :-). But when you've only got 7 system calls (per the original L4 specifications I've read over) you don't really have a lot to debug. Just gotta make sure you chose the correct primitives to compose all the software you need to write on the system. that functionality doesn't disappear, does it? where ever it goes, the bugs will follow. That's absolutely correct. However, if you can test a piece in isolation from other noise, you can rule out certain areas as being suspect in the process of diagnosing issues. if the argument is that it's easier to debug if it's not in the kernel, i think that argument requires some proof. The argument is that if something is logically separable from a larger system, and independently testable, then once you've verified it is correct, and that the glue is correct that is used to compose a larger system, that you can more readily decide where to look for problem sources. This is actually the basis of pure functional programming. Pure functions can not deviate in the values they produce because they have a property called referential transparency. Not all code can be written this way obviously, but if you can build a small system, test that it works, then compose with another small system to do more processing, you can glue those things together to build something more complex. Think Unix/Plan 9 pipelines of small commands and you get the point. I believe this concept took a little mind-bending to get to as well, but seems almost obvious now. You can think of sort, uniq, and grep as pure functional routines, which you run some I/O through. If the inputs are the same, the outputs (damn well better) be the same. Back in the old days (20 years ago?) Microkernels were going to make it so that all software was organized this way. It's just not practical to do so though. They wanted servers for disk access, servers for network etc. Basically it looked like what GNU Hurd was after... and we see how well that's done. You'll find systems based on the L4 microkernels today that implement a single address space (like Inferno I suppose? or Singularity) and you'll find stuff like L4-Linux, mostly being used as a way to bridge other OSes to Linux's drivers, or just to run multiple instances of Linux as in a virtualization like system like VMWare's high end products provide (they're basically using a microkernel too for their high-end hypervisors). However some of the more practical academics (yeah I know it's like jumbo shrimp or military intelligence) have spun very interesting things off like we used to call these people research fellows at corporate labs. sadly, their astroid has landed. Yeah :-(. It's a sad time. Microsoft, for as much as they've been bashed, is keeping that dream alive for some. They seem to understand that RD is actually important to keeping on top of things. I feel a little icky to admit it but I really like Visual Studio and F#. I was amazed at how quickly I was able to learn C# and write GUI programs compared to say, Xcode and Cocoa. Dave - erik
Re: [9fans] linux stats in last year from linuxcon
On Tue, Sep 22, 2009 at 8:14 AM, erik quanstrom quans...@quanstro.netwrote: On Tue Sep 22 11:06:37 EDT 2009, leim...@gmail.com wrote: The argument is that if something is logically separable from a larger system, and independently testable, then once you've verified it is correct, and that the glue is correct that is used to compose a larger system, that you can more readily decide where to look for problem sources. This is actually the basis of pure functional programming. i thought that was called unit testing, and i don't think unit testing is the exclusive domain of functional programming or microkernels. I never claimed exclusivity. I simply said we've seen this before and why it's good, in response to you're this remains to be proven that isolation is a good thing. I gave examples. I don't understand why we're arguing and in agreement at the same time. I guess it's fun, but I've got better things to do right now that I've got to get back to :-) Peace! Dave - erik
Re: [9fans] linux stats in last year from linuxcon
On Tue, Sep 22, 2009 at 10:13 AM, erik quanstrom quans...@quanstro.netwrote: btw, there's even been one ukernel recently that has a formal proof of correctness (against its specification and some containment properties). Roughly a 10 man-year effort for about 7.5kloc. Not something you'd likely be able to do yet against something linux- sized. the other way of looking at this is all the complex and error prone stuff is not prooved. i'm not clear on what all functional correctness entails. can a functionally correct program suffer from deadlock or livelock? I'm not sure... I can tell you when I spawn threads in haskell that, while testing, the runtime seems to detect certain deadlock states, tells me about them, and then the program crashes. I like that a little better than deadlock :-) How that all works is a lit Dave - erik
Re: [9fans] linux stats in last year from linuxcon
On Mon, Sep 21, 2009 at 10:53 AM, Patrick Kelly kameo76...@gmail.comwrote: On Sep 21, 2009, at 1:41 PM, Jack Norton wrote: ron minnich wrote: 2.7M lines last year 10K lines added a day. 5K lines deleted per day. I keep thinking this can't be sustained. What happens next? At the same time, well, as pointed out, we all use it all the time. I'm sending this from gmail. Or you can use Linux by googling these stats :-) ron Here is a little related tidbit: http://lwn.net/Articles/222773/ It shows employer/company vs. changed lines/contributions etc... I think this has as much to do with the state of the linux kernel as the overall design and ideal therein. It defines the 'new' open source. I don't think something this large can benifit anymore from open source (as in open 'all the time' to anyone, everywhere -- as opposed to let's say apple's version of open source dev). The development scheme just doesn't scale. In any event, I'm still waiting for the damn thing to fork... Fork... That's true, everything under the sun has forked, except the Linux kernel... Except for the times when the linux kernel was forked for PPC support :-). Or the fork for running linux on L4. or -Jack
Re: [9fans] Blocks in C
On Thu, Sep 17, 2009 at 1:43 AM, Charles Forsyth fors...@terzarima.netwrote: we'd have been much better off if Apple had instead spent the time and effort writing a decent iTunes, or opening their platform interfaces enough that someone else could do it (and on Linux, not just Mac or Windows). What's your gripe on iTunes? I've had a few issues with it, but it does seem to get the job done somehow. Honestly just curious.
Re: [9fans] fun quote
On Thu, Sep 17, 2009 at 5:52 AM, erik quanstrom quans...@quanstro.netwrote: Now, Plan 9's kernel is pretty old too, isn't it? that's the point. age is a red herring. What has saved other 'popular' kernels from this? For instance, no body ever complains about FreeBSD being a complex cluster, but it has pretty wide adoption (even as a 'desktop'). What about OS X? Has Apple's arrogance and secrecy saved it from open source development? It seems like they release code only after they are damn sure they've gotten all they can out of it. so you're saying that osx is not complicated? I think Mach makes me go cross-eyed. It's not at all what it was meant to be. Wedging that stuff in with IOKit and BSD stuff makes me feel lost, and yes I've hacked on XNU, the hybrid beast that it is, and run Mac OS X on my own kernels. - erik
Re: [9fans] fun quote
On Thu, Sep 17, 2009 at 8:30 AM, Jack Norton j...@0x6a.com wrote: erik quanstrom wrote: Now, Plan 9's kernel is pretty old too, isn't it? that's the point. age is a red herring. What has saved other 'popular' kernels from this? For instance, no body ever complains about FreeBSD being a complex cluster, but it has pretty wide adoption (even as a 'desktop'). What about OS X? Has Apple's arrogance and secrecy saved it from open source development? It seems like they release code only after they are damn sure they've gotten all they can out of it. so you're saying that osx is not complicated? - erik No, no, it is, what I mean is that I haven't heard similar sentiments towards the open source released by Apple. Apple's 'open source' is software that is developed in a closed source fashion, then released as open source when the time is right, as opposed to Linux and related software, which are developed, almost from the ground up, as open source. This is the impression I get anyway. -Jack As a former member of the OpenDarwin project, I can tell you your impression of Apple's open source is pretty correct. They like to share the source, and people are allowed to port things they do to other platforms, and submit patches and stuff gets into the mainline (like FreeBSD support for libdispatch and such seems like it's going to). Or you can just fork it and make your own thing, but they're goal is probably the wider code review that the community offers more so than sharing and being a nice open source community member. It is nice that they've started licensing some stuff under Apache instead of some of their other licenses of the past, however I really feel Apple's open source is more of a one-way street. Dave
Re: [9fans] Blocks in C
On Sat, Sep 12, 2009 at 4:08 AM, Anant Narayanan an...@kix.in wrote: On Sep 11, 2009, at 10:36 PM, Roman V Shaposhnik wrote: I still do care very much (and in fact, I've been meaning to provide some of the answers on this mailing list, but apparently one can't upgrade to Snow Leopard over the net so I have to physically drive to the Mac store :-(). Anyway, for a non Mac person, can somebody please clarify whether macosforge.org has the very same bits that go into the Mac OS itself, or do I still have to get the real thing? The source as put on macosforge has been generalized (apparently to make it easy to port to other platforms), but AFAIK the code that actually runs in Snow Leopard has a few performance optimizations that takes advantage of a similar low-level API that is supported by the new xnu kernel. My understanding is it's the same source on macosforge, it can just be built with or without the kernel hints. (They're part of the kqueues stuff, and that's being ported to FreeBSD as well). The xnu kernel itself is also open-source, http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/ is the version with GCD primitives. -- Anant
Re: [9fans] Blocks in C
On Fri, Sep 11, 2009 at 11:15 AM, Iruata Souza iru.mu...@gmail.com wrote:
On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah
bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com
wrote:
On Tue, 08 Sep 2009 08:31:28 PDT David Leimbach leim...@gmail.com
wrote:
Having wrestled with this stuff a little bit, and written something.
I
can immediately see how one can get away from needing to select in
code so
much, and fire off blocks to handle client server interactions etc.
It's
kind of neat.
alt(3) is a nicer way to avoid select().
I still say CSP is the way to go. In plan9/limbo channels
work across coroutines in one process. Seems to me extending
channels to work across preemptive threads (running on
multiple cores) or across processes or machines is might lead
to a more elegant and no less performant model. It seems
to be a more natural model when you have zillions of
processors on a chip (like TileraPro64, with zillion = 64).
They can't all go to shared external memory without paying a
substantial cost but neighbor to neighbor communication is
far faster (tilera claims 37Tbps onchip interconnect b/w and
50Gbps of I/O bw).
It is nice that a Apple C block treats all non local
variables (except __block ones) as read only variables. But
every time I look at blocks I see new problems. What if a
block calls a function that modifies a global like in the
example below? If this works, what is the point of treating
globals as readonly? If this doesn't work, how do ensure
trash_x() causes a seg fault, particularly when it is defined
in another file?
int x;
void trash_x() { x = -42; }
... ^{ trash_x(); } ...
My view: if you can't solve a problem cleanly and in a
general way with a feature, it does not belong in a language
(but may belong in a library).
for those who still care
http://libdispatch.macosforge.org/
And the FreeBSD port is underway too. It's going to have the kernel
scheduling hints too it seems.
Dave
Re: [9fans] Blocks in C
On Fri, Sep 11, 2009 at 1:36 PM, Roman V Shaposhnik r...@sun.com wrote:
On Fri, 2009-09-11 at 15:15 -0300, Iruata Souza wrote:
On Tue, Sep 8, 2009 at 1:40 PM, Bakul Shah
bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com
wrote:
int x;
void trash_x() { x = -42; }
... ^{ trash_x(); } ...
My view: if you can't solve a problem cleanly and in a
general way with a feature, it does not belong in a language
(but may belong in a library).
for those who still care
http://libdispatch.macosforge.org/
I still do care very much (and in fact, I've been meaning
to provide some of the answers on this mailing list, but
apparently one can't upgrade to Snow Leopard over the
net so I have to physically drive to the Mac store :-().
Anyway, for a non Mac person, can somebody please clarify
whether macosforge.org has the very same bits that go into
the Mac OS itself, or do I still have to get the real thing?
This is the exported open source stuff from Apple. So, yes it's the same.
Of course they could have forks inside apple you don't get to see, but
it's the same source base.
Dave
Thanks,
Roman.
Re: [9fans] nice quote
On Wed, Sep 9, 2009 at 8:48 AM, Charles Forsyth fors...@terzarima.netwrote: if people would leave off moaning about moaning, we'd clear the space for more moaning about lisp although the former did have the advantage that the messages were shorter and didn't quote the bulk of all previous messages. anyone written any software recently? at this point it probably doesn't matter whether it was for plan 9 or not. I wrote a concurrent prime sieve using GCD from Snow Leopard :-) It's just a demonstration but I wrote that all the same. I started in on a Haskell 9p library as well, but haven't gotten very far, due to mostly the time I have to invest in it. I managed to get it to successfully version message Inferno's styxlisten though. The code is butt ugly too and I'm going to start over. Dave
Re: [9fans] Blocks in C
On Mon, Sep 7, 2009 at 2:40 AM, Uriel urie...@gmail.com wrote: On Mon, Sep 7, 2009 at 11:05 AM, Greg Comeaucom...@panix.com wrote: In article 25cf9336-c071-44a5-ab04-6bb042bc5...@kix.in, Anant Narayanan an...@kix.in wrote: I understand the argument that blocks don't feel C-like, but the argument that you can do everything with just using function pointers is BS. Even one step further, even if we all agree blocks are BS, As I was reading this thread I kept hearing inside my head boyd's voice screaming this at frequent intervals: Blocks are bollocks! uriel In case anyone is interested, I've got my concurrent prime sieve working just fine now (with help from Kevin Van Vechten at apple) using libdispatch, simulating the actor model by hooking up blocks to pipe fds. http://paste.lisp.org/display/86549#3 It turns out I don't need the semaphore and the counter either, because I can dynamically add stuff to groups, and then wait on that stuff to leave the group for synchronizing the program. Again this advice came from my buddy Kevin at apple. Having wrestled with this stuff a little bit, and written something. I can immediately see how one can get away from needing to select in code so much, and fire off blocks to handle client server interactions etc. It's kind of neat. My understanding is that Apple is going through the process to open up the source to all of this stuff soon, and another friend of mine has already done his own version of blocks that works for the iPhone and Leopard, and another person is looking to make an API compatible with libdispatch readily available. I guess we'll see what happens. Dave
Re: [9fans] nice quote
On Sun, Sep 6, 2009 at 10:08 AM, Eris Discordia eris.discor...@gmail.comwrote: In this respect rating the expressive power of C versus LISP depends very much on the problem domain under discussion. Of course. I pointed out in my first post on the thread that [...] for a person of my (low) caliber, LISP is neither suited to the family of problems I encounter nor suited to the machines I solve them on. I cannot exclude other machines and other problems but can talk from what little I have personally experienced. I would like to see Haskell fill C's niche [...] Is it as readily comprehensible to newcomers as C? Are there texts out there that can welcome a real beginner in programming and help him become productive, on a personal level at least, as rapidly as good C textbooks--you know the classic example--do? Is there a coherent mental model of small computers--not necessarily what you or I deem to be a small computer--that Haskell fits well and can be taught to learners? I imagine those will be indispensable for any language to replace existing languages, much more so in case of C. According to the designer of F# (another functional programming language that takes it's syntax from O'Caml as well as Haskell and even Python), one of the best experiences he'd had was working with a high school student who was able to modify a solar system simulation written in F# with no prior programming experience. (from http://www.computerworld.com.au/article/271034/) There's books on F# out there, and F# for Scientists. http://www.ffconsultancy.com/products/fsharp_for_scientists/index.html There's books on multimedia programming in Haskell out there that also attempt to show programming to newcomers, but I'm not sure any of them really assume no prior programming experience. I think people learning C get one view of the computer that folks learning assembly really learn to appreciate :-). Folks learning Haskell learn another mental model of programming as well. My personal belief is that learning new languages makes one think about the languages they are used to in a new light, and can make them better programmers overall.
Re: [9fans] nice quote
On Sun, Sep 6, 2009 at 11:26 AM, Tim Newsham news...@lava.net wrote: I would like to see Haskell fill C's niche: it's close to C's execution speed now, and pure functions and a terse style gives real advantages in coding speed (higher-order functions abstract common patterns without tedious framework implementations), maintainability (typeclasses of parameters in utility functions means you don't write different implementations of the same function for different types, yet preserve type compatibility and checking), and reliability (pure functions don't depend on state, so have fewer moving parts to go wrong). Do you know of any garbage collectors written in Haskell? Do you know of any thread/process schedulers written in Haskell that can schedule arbitrary code (ie. not just code that is written in a continuation monad)? I would like to see a language that lets you write low level code (like memcpy) efficiently, in a style that makes reasoning about the code easy, and which doesnt require (but can coexist and support) garbage collection. Hmmm, pre-scheme perhaps? http://en.wikipedia.org/wiki/PreScheme It doesn't do garbage collection, and is meant for low level code, but provides scheme's macros. Scheme48 is written in it. while(n--) *p++ = *q++; is still quite elegant compared to many other expressive langauges. setjmp and longjmp are still quite powerful. Jason Catena Tim Newsham http://www.thenewsh.com/~newsham/
Re: [9fans] nice quote
On Sat, Sep 5, 2009 at 6:58 PM, Jason Catena jason.cat...@gmail.com wrote: Hailed Eris: I was alluding to the expressive power of C versus LISP considered with respect to the primitives available on one's computing platform and primitives in which solutions to one's problems are best expressed. I think one of the reasons there exists little languages, and cliches such as the right tool for the job, is that the primitives available on one's computing platform are very often not the primitives in which solutions to one's problems are best expressed. In this respect rating the expressive power of C versus LISP depends very much on the problem domain under discussion. For systems programming, C has the advantage in both practice (use in running systems) and theory: processes which take a lot of system resources to execute also tend to take a lot of C code, whereas in most higher-order languages, things which represent high-level runtime-consuming abstractions tend look little different than simple bit-level operations. The difference is one of approach, I guess: whether you want to write optimal code yourself, and see what the machine is doing, or trust the compiler to find a good way to translate to machine language and run (in real-time) your efficient-to-code higher-order functions. The better the translation from the higher-level language, the more this difference becomes a matter of taste, programming style, availability of programmers, and the body of domain knowledge already represented in language libraries. I would like to see Haskell fill C's niche: it's close to C's execution speed now, and pure functions and a terse style gives real advantages in coding speed (higher-order functions abstract common patterns without tedious framework implementations), maintainability (typeclasses of parameters in utility functions means you don't write different implementations of the same function for different types, yet preserve type compatibility and checking), and reliability (pure functions don't depend on state, so have fewer moving parts to go wrong). Well I can think of 3 operating systems written in Haskell now. One was an executable specification for validating a secure L4 implementation. One is hOp, and then there's also House, based on hOp. There's also Kinetic, written primarily in Haskell. http://www.ninj4.net/kinetic/ The newest fork of House has TCP/IP networking uhm working. http://web.cecs.pdx.edu/~kennyg/house/ There is a haskell file system in development too now http://www.haskell.org/halfs/, but a lot of links don't work :-). I've been writing a good bit of Haskell these days at work as well, mainly due to the fact that it's possible to write some fairly sophisticated code quickly, and even get pretty darned good performance out of it. Jason Catena
Re: [9fans] Blocks in C
On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah
bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com
wrote:
On Thu, 03 Sep 2009 22:35:35 PDT David Leimbach leim...@gmail.com
wrote:
Actually, reading on a bit more they deal with the variable capture
talking about const copies.
Automatic storage variables not marked with __block are imported as
const copies.
The simplest example is that of importing a variable of type int.
int x = 10;
void (^vv)(void) = ^{ printf(x is %d\n, x); }
x = 11;
vv();
would be compiled
struct __block_literal_2 {
void *isa;
int flags;
int reserved;
void (*invoke)(struct __block_literal_2 *);
struct __block_descriptor_2 *descriptor;
const int x;
};
void __block_invoke_2(struct __block_literal_2 *_block) {
printf(x is %d\n, _block-x);
}
static struct __block_descriptor_2 {
unsigned long int reserved;
unsigned long int Block_size;
} __block_descriptor_2 = { 0, sizeof(struct __block_literal_2) };
and
struct __block_literal_2 __block_literal_2 = {
_NSConcreteStackBlock,
(129), uninitialized,
__block_invoke_2,
__block_descriptor_2,
x
};
In summary, scalars, structures, unions, and function pointers are
generally imported as const copies with no need for helper functions.
Just read this after posting my last message.
But this has no more to do with parallelism than any other
feature of C. If you used __block vars in a block, you'd
still need to lock them when the block is called from
different threads.
I just wrote a prime sieve with terrible shutdown synchronization you can
look at here:
http://paste.lisp.org/display/86549
Dave
Re: [9fans] Blocks in C
On Fri, Sep 4, 2009 at 5:14 AM, erik quanstrom quans...@quanstro.netwrote: But this has no more to do with parallelism than any other feature of C. If you used __block vars in a block, you'd still need to lock them when the block is called from different threads. that's a lot worse than a function pointer. with a function pointer your going to get unique space on the stack for each invocation. Unless the variable is static right? And not automatic? So __block is the block's static local data? I could be wrong, but I feel like you're not really interested in entertaining that this idea could be useful, but more interested in shooting it down. That's fine, people do that all the time. People are *constantly* saying Plan 9 is a huge waste of time too. And if you count the number of actual users, they're probably right. I happen to like Plan 9, so I do some stuff with it. I don't know if I like libdispatch, GCD or these new C closures yet. I am finding myself wanting to try to like them, but I can't decide yet how bad or good they really are. Deep down inside, I want people to stop trying to code stuff like this in C and try the massively scaled parallelism/concurrency stuff in other languages better suited to the problem space. the variable capture thing seems to me to just confuse the issue. c doesn't otherwise work like that. And now you've arrived at the conclusion apple probably arrived at for changing the language the way they did. C doesn't otherwise work like that :-) Note I've written a concurrent prime sieve with these facilities. http://paste.lisp.org/display/86549 I should also note that once I crank max up a little over 700 it all seems to fall apart. This might be my bug, or apple's bug. But I've been really good at finding bugs in apple's new features for years now. I totally froze up a system playing with kernel queues when they added them at first too, and they contacted me personally to retry my code when they thought they had it fixed. They may come off as pompous, but I know people in apple looking for people to examine this stuff in a serious way, and give feedback. Dave - erik
Re: [9fans] Blocks in C
On Fri, Sep 4, 2009 at 7:41 AM, Bakul Shah bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com wrote: On Fri, 04 Sep 2009 00:47:18 PDT David Leimbach leim...@gmail.com wrote: On Fri, Sep 4, 2009 at 12:11 AM, Bakul Shah bakul+pl...@bitblocks.com bakul%2bpl...@bitblocks.com bakul%2bpl...@bitblocks.com bakul%252bpl...@bitblocks.com wrote: But this has no more to do with parallelism than any other feature of C. If you used __block vars in a block, you'd still need to lock them when the block is called from different threads. I just wrote a prime sieve with terrible shutdown synchronization you can look at here: http://paste.lisp.org/display/86549 Not sure how your program invalidates what I said. Blocks do provide more syntactic sugar but that benefit is independent of GCD (grand central dispatch) or what have you. Given that __block vars are shared, I don't see how you can avoid locking if blocks get used in parallel. You've said it yourself. if blocks get used in parallel. If the blocks are scheduled to the same non-concurrent queue, there shouldn't be a problem, unless you've got blocks scheduled and running on multiple serial queues. There are 3 concurrent queues, each with different priorities in GCD, and you can't create any more concurrent queues to the best of my knowledge, the rest are serial queues, and they schedule blocks in FIFO order. Given that you can arrange your code such that no two blocks sharing the same state can execute at the same time now, why would you lock it? What I did was allocate context data for the actual read end of a pipe fd on the heap, such that when an associated block was launched by the runtime (when something was written to the write fd of a pipe) it would get it's context pointer in it's block struct, which I could access by get_context. I should note that for some reason my code falls apart in terms of actually working as I expected it after MAX is set to something over 700, so I'm probably *still* not doing something correctly, or I did something Apple didn't expect. Dave
Re: [9fans] nice quote
On Thu, Sep 3, 2009 at 8:02 AM, Uriel urie...@gmail.com wrote: On Wed, Sep 2, 2009 at 8:46 PM, David Leimbachleim...@gmail.com wrote: I mean HTTP has a small protocol, but if you count all the things you can do with REST, then it looks like a lot more. HTTP might be many things, small is not one of them. That said, your overall point is correct. Well I meant small compared to all the APIs you can call with REST through it :-) Peace uriel
Re: [9fans] nice quote
On Thu, Sep 3, 2009 at 2:52 AM, Greg Comeau com...@panix.com wrote: In article 3096bd910909020751o12086713m4291e2f1b77da...@mail.gmail.com, Rodolfo kix k...@kix.es wrote: On Wed, Sep 2, 2009 at 4:29 PM, ron minnichrminn...@gmail.com wrote: Q: Will C continue to be important into the future? (Dave Kirk, Nvidia)A: No, I think C will die like Fortran has I believe OS/2 is destined to be the most important operating system, and possibly program, of all time. (Bill Gates, OS/2 Programmers Guide, November 1987) ... we are all human ... :-) When push comes the shove, these are probably both said in the same spirit (I doubt Kirk feels C will die, nor Gates that OS/2 was such (nor that MS products have no bugs)) If I recall correctly, conspiracy theorists might even claim that Microsoft was singing the praises of OS/2 while simultaneously putting more effort into NT. Note that Microsoft was working on OS/2 for IBM at the time, and probably consciously chose to make NT win that battle. I'm not saying that's what happened, I'm saying others *have* said so. -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 8:15 AM, Uriel urie...@gmail.com wrote: On Wed, Sep 2, 2009 at 4:20 PM, Devon H. O'Delldevon.od...@gmail.com wrote: 2009/9/2 Uriel urie...@gmail.com: On Wed, Sep 2, 2009 at 10:04 AM, Anant Narayananan...@kix.in wrote: Mac OS 10.6 introduced a new C compiler frontend (clang), which added support for blocks in C [1]. Blocks basically add closures and anonymous functions to C (and it's derivatives). Full details with examples are in the linked article. I think the feature is quite elegant and might be useful in cases where you want map/reduce like functionality in C. Er., I might be more dumb than usual, but why on earth would you need/want this garbage to get map/reduce functionality in C? To me it seems the typical lets come up with some cute 'feature' and then we will figure out how to hype ourselves all the way to hell. I don't see why you'd particularly need / want this in C, but the argument here seems silly given that you've stressed your affinity to other languages that implement closures / anonymous functions. My affinity is to language that display *conceptual integrity*. In any case, implementing closures in C isn't too difficult, and if you want to return a function, just return a pointer to it. Exactly, I still fail to understand the point of this feature, function points have worked fine for ages, but then I never understood any religion, and that is what Apple seems to be all about. The blocks aren't interesting at all by themselves, I totally agree with that. However what they do to let you write a function inline, that can be pushed to another function, to be executed on a concurrent FIFO, is where the real power comes out. I'm not 100% sure why the heck they did it this way, which is totally different from any other version of concurrent programming setup I've seen, except maybe that Apple likes to think different? I'm not sure I think this stuff is insanely great though. I'm planning to try using it before judging it further though. Dave Peace uriel
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 9:02 AM, erik quanstrom quans...@quanstro.netwrote: The blocks aren't interesting at all by themselves, I totally agree with that. However what they do to let you write a function inline, that can be pushed to another function, to be executed on a concurrent FIFO, is where the real power comes out. this reminds me of paul and byron's shell, es which had anonymous blocks. in fact, that's how the if statement worked. in c, i don't see why such a bolt-on would be useful in c, especially since your concurrent fifo would be limited to one shared-memory node unless you're going to add a runtime compiler. Apple's using it all over the place in Snow Leopard, in all their native apps to write cleaner, less manual-lock code. At least, that's the claim :-). If by node you mean single machine then I suppose I agree, but this is not a distributed computing solution in the world of multi-node programming. Dave - erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 11:58 AM, erik quanstrom quans...@quanstro.netwrote: Apple's using it all over the place in Snow Leopard, in all their native apps to write cleaner, less manual-lock code. At least, that's the claim :-). could someone explain this to me? i'm just missing how naming a block of code could change its locking properties. The explanation is in the manual I linked to earlier in this discussion. If you want to see examples there's two I can think of available for download. One is called DispatchLife the other is DispatchFractal. I've looked at DispatchLife, and there's no explicit locking of state for every cell being concurrently update in Conway's game of life. Dave - erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom quans...@quanstro.netwrote: Apple's using it all over the place in Snow Leopard, in all their native apps to write cleaner, less manual-lock code. At least, that's the claim :-). could someone explain this to me? i'm just missing how naming a block of code could change its locking properties. The explanation is in the manual I linked to earlier in this discussion. If you want to see examples there's two I can think of available for download. One is called DispatchLife the other is DispatchFractal. I've looked at DispatchLife, and there's no explicit locking of state for every cell being concurrently update in Conway's game of life. i can't find DispatchLife after a few minutes of googling. i've read the manual, and it looks like csp to me. clearly i am a reprobate outside the apple reality distortion field. Google doesn't have all the answers, I actually had to use Bing today, and it worked... anyway here's the link to DispatchLife. http://developer.apple.com/mac/library/samplecode/DispatchLife/ could you explain why this isn't csp and why this can't be done with regular c (that is why we need the concept of an unnamed function pointer) and the thread library? I'm actually planning to figure this stuff out a bit more and blog about it, hopefully by Friday sometime (tomorrow). I don't agree that any of this stuff is strictly needed. One can plod along with pthreads and do it wrong all day. One doesn't *need* C either, I've seen whole OSes for x86 written in assembly. It all depends on how much crap you want to keep track of. Dave - erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 2:49 PM, David Leimbach leim...@gmail.com wrote:
On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach leim...@gmail.com wrote:
On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom quans...@quanstro.netwrote:
On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
Anything can be done using regular C and threads. The trick here
is to make everything *scalable* and *painless* enough so that
mere mortals can start benefiting from parallelism in their code.
The other trick here is to find a model that makes things *natural*,
and
that means practically no explicit locking, less shared state, etc.
The search for the model is meaningless unless it is used for
solving *practical* challenges. In that respect, one of my
favorite article is how implementation of a chess engine
influenced Cilk framework (which almost has the notion of a block)
http://supertech.csail.mit.edu/papers/icca99.pdf
Read it, I don't think we can be on the same page (and escape the
armchair philosophy trap) unless we are talking about practical
applications of the framework.
Look at the chess example -- can the same be done with pure C? Sure!
Did Cilk make it less painful? Absolutely!
my question was, what's naming your function pointers
or not got to do with locking? i'm asking about the language
construct, not the library er i mean framework and maybe runtime
that goes with it.
Maybe if you see the block implementation you wouldn't think it was merely
naming a function pointer?
http://clang.llvm.org/docs/BlockImplementation.txt
also
{
int X;
call_a_block(^(int y) {print (X+y); });
}
The block has a snapshot of that stack variable X.
It really does work a bit more like a closure than a function pointer.
Dave
Also this doc is the spec: http://clang.llvm.org/docs/BlockLanguageSpec.txt
Dave
- erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom quans...@quanstro.netwrote: On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote: Anything can be done using regular C and threads. The trick here is to make everything *scalable* and *painless* enough so that mere mortals can start benefiting from parallelism in their code. The other trick here is to find a model that makes things *natural*, and that means practically no explicit locking, less shared state, etc. The search for the model is meaningless unless it is used for solving *practical* challenges. In that respect, one of my favorite article is how implementation of a chess engine influenced Cilk framework (which almost has the notion of a block) http://supertech.csail.mit.edu/papers/icca99.pdf Read it, I don't think we can be on the same page (and escape the armchair philosophy trap) unless we are talking about practical applications of the framework. Look at the chess example -- can the same be done with pure C? Sure! Did Cilk make it less painful? Absolutely! my question was, what's naming your function pointers or not got to do with locking? i'm asking about the language construct, not the library er i mean framework and maybe runtime that goes with it. Maybe if you see the block implementation you wouldn't think it was merely naming a function pointer? http://clang.llvm.org/docs/BlockImplementation.txt Dave - erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach leim...@gmail.com wrote:
On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom quans...@quanstro.netwrote:
On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote:
Anything can be done using regular C and threads. The trick here
is to make everything *scalable* and *painless* enough so that
mere mortals can start benefiting from parallelism in their code.
The other trick here is to find a model that makes things *natural*, and
that means practically no explicit locking, less shared state, etc.
The search for the model is meaningless unless it is used for
solving *practical* challenges. In that respect, one of my
favorite article is how implementation of a chess engine
influenced Cilk framework (which almost has the notion of a block)
http://supertech.csail.mit.edu/papers/icca99.pdf
Read it, I don't think we can be on the same page (and escape the
armchair philosophy trap) unless we are talking about practical
applications of the framework.
Look at the chess example -- can the same be done with pure C? Sure!
Did Cilk make it less painful? Absolutely!
my question was, what's naming your function pointers
or not got to do with locking? i'm asking about the language
construct, not the library er i mean framework and maybe runtime
that goes with it.
Maybe if you see the block implementation you wouldn't think it was merely
naming a function pointer?
http://clang.llvm.org/docs/BlockImplementation.txt
also
{
int X;
call_a_block(^(int y) {print (X+y); });
}
The block has a snapshot of that stack variable X.
It really does work a bit more like a closure than a function pointer.
Dave
Dave
- erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 8:52 PM, erik quanstrom quans...@quanstro.netwrote:
Did you even read the article or any of the examples? There are plenty
of things that you can do with blocks that you can't with just
function pointers. That's besides the fact that some of them are more
elegantly expressed with blocks that look sort of ugly with function
pointers.
on the other hand, apple says this is illegal
dispatch_block_t p;
if(cond){
p =^ { print(cond\n); };
}else{
p =^ { print(cond\n); };
}
p();
since the first part is equivalent to
if(cond){
struct Block _t = ...;
p = _t;
}
intuitive? easy to read? pretty?
also, if this from david's example is allowed (i'll assume
that the original examples' print(X+y) for int X and y
was a bit of a typo --- i hope!)
block =^ (int x){ print(%d\n, x ); };
Wasn't my example... came off an email I cut and pasted from another email
after googling around a bit for block stuff. Also I think you mean printf
since we're being pedantic? :-)
that sucker is on the stack. by-by no-execute stack.
how does it get to the stack? is it just copied from
the text segment or is it compiled at run time?
I don't think I posted the whole code, so that's my bad. The X was on the
stack to begin with as the first X was an automatic variable in a function.
I'd be a little surprised to find an automatic variable in the text
segment, but perhaps that's just my not remembering things properly.
(didn't mean that tongue in cheek, I don't think about that stuff much
these days, as I've spent the last year or so doing Erlang and Haskell.)
- erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 9:44 PM, erik quanstrom quans...@quanstro.netwrote: that sucker is on the stack. by-by no-execute stack. how does it get to the stack? is it just copied from the text segment or is it compiled at run time? I don't think I posted the whole code, so that's my bad. The X was on the stack to begin with as the first X was an automatic variable in a function. I'd be a little surprised to find an automatic variable in the text segment, but perhaps that's just my not remembering things properly. (didn't mean that tongue in cheek, I don't think about that stuff much these days, as I've spent the last year or so doing Erlang and Haskell.) it is the block itself that apple claims is on the stacp (your grand centeral reference, p. 38). and i wonder how it gets there. is it just copied from the text segment? that seems kind of pointless. why not just execute it from the text segment? or is it modified (compiled?) at run time? Right, my understanding is that blocks live on the stack, however it appears that they get copied to a particular queue before being run, either explicitly or implicitly depending on how it gets submitted. If you use dispatch_after, it gets copied and released automatically after a certain amount of time. The whole thing is very eventy. Some of the documentation is not terribly explicit about how things get copied if they do at all. Example is the dispatch_async call, which behaves based on the queue to which it is submitted, but whether or not a copy occurs is not mentioned. This document goes into more detail: http://clang.llvm.org/docs/BlockImplementation.txt Block literals may occur within functions where the structure is created in stack local memory. They may also appear as initialization expressions for Block variables of global or static local variables. When a Block literal expression is evaluated the stack based structure is initialized as follows: 1) static descriptor structure is declared and initialized as follows: 1a) the invoke function pointer is set to a function that takes the Block structure as its first argument and the rest of the arguments (if any) to the Block and executes the Block compound statement. 1b) the size field is set to the size of the following Block literal structure. 1c) the copy_helper and dispose_helper function pointers are set to respective helper functions if they are required by the Block literal 2) a stack (or global) Block literal data structure is created and initialized as follows: 2a) the isa field is set to the address of the external _NSConcreteStackBlock, which is a block of uninitialized memory supplied in libSystem, or _NSConcreteGlobalBlock if this is a static or file level block literal. 2) The flags field is set to zero unless there are variables imported into the block that need helper functions for program level Block_copy() and Block_release() operations, in which case the (125) flags bit is set. I'm still left feeling somewhat not understanding how it all works :-) - erik
Re: [9fans] Blocks in C
On Thu, Sep 3, 2009 at 10:31 PM, David Leimbach leim...@gmail.com wrote:
On Thu, Sep 3, 2009 at 9:44 PM, erik quanstrom quans...@quanstro.netwrote:
that sucker is on the stack. by-by no-execute stack.
how does it get to the stack? is it just copied from
the text segment or is it compiled at run time?
I don't think I posted the whole code, so that's my bad. The X was on
the
stack to begin with as the first X was an automatic variable in a
function.
I'd be a little surprised to find an automatic variable in the text
segment, but perhaps that's just my not remembering things properly.
(didn't mean that tongue in cheek, I don't think about that stuff much
these days, as I've spent the last year or so doing Erlang and Haskell.)
it is the block itself that apple claims is on the stacp
(your grand centeral reference, p. 38). and i wonder
how it gets there. is it just copied from the text segment?
that seems kind of pointless. why not just execute it
from the text segment? or is it modified (compiled?)
at run time?
Right, my understanding is that blocks live on the stack, however it
appears that they get copied to a particular queue before being run, either
explicitly or implicitly depending on how it gets submitted. If you use
dispatch_after, it gets copied and released automatically after a certain
amount of time.
The whole thing is very eventy.
Some of the documentation is not terribly explicit about how things get
copied if they do at all. Example is the dispatch_async call, which behaves
based on the queue to which it is submitted, but whether or not a copy
occurs is not mentioned.
This document goes into more detail:
http://clang.llvm.org/docs/BlockImplementation.txt
Block literals may occur within functions where the structure is created
in stack local memory. They may also appear as initialization expressions
for Block variables of global or static local variables.
When a Block literal expression is evaluated the stack based structure is
initialized as follows:
1) static descriptor structure is declared and initialized as follows:
1a) the invoke function pointer is set to a function that takes the Block
structure as its first argument and the rest of the arguments (if any) to the
Block and executes the Block compound statement.
1b) the size field is set to the size of the following Block literal
structure.
1c) the copy_helper and dispose_helper function pointers are set to
respective helper functions if they are required by the Block literal
2) a stack (or global) Block literal data structure is created and
initialized as follows:
2a) the isa field is set to the address of the external
_NSConcreteStackBlock, which is a block of uninitialized memory supplied in
libSystem, or _NSConcreteGlobalBlock if this is a static or file level block
literal.
2) The flags field is set to zero unless there are variables imported into
the block that need helper functions for program level Block_copy() and
Block_release() operations, in which case the (125) flags bit is set.
I'm still left feeling somewhat not understanding how it all works :-)
Actually, reading on a bit more they deal with the variable capture
talking about const copies.
Automatic storage variables not marked with __block are imported as
const copies.
The simplest example is that of importing a variable of type int.
int x = 10;
void (^vv)(void) = ^{ printf(x is %d\n, x); }
x = 11;
vv();
would be compiled
struct __block_literal_2 {
void *isa;
int flags;
int reserved;
void (*invoke)(struct __block_literal_2 *);
struct __block_descriptor_2 *descriptor;
const int x;
};
void __block_invoke_2(struct __block_literal_2 *_block) {
printf(x is %d\n, _block-x);
}
static struct __block_descriptor_2 {
unsigned long int reserved;
unsigned long int Block_size;
} __block_descriptor_2 = { 0, sizeof(struct __block_literal_2) };
and
struct __block_literal_2 __block_literal_2 = {
_NSConcreteStackBlock,
(129), uninitialized,
__block_invoke_2,
__block_descriptor_2,
x
};
In summary, scalars, structures, unions, and function pointers are
generally imported as const copies with no need for helper functions.
- erik
Re: [9fans] Blocks in C
Has anyone actually looked at the spec or is this just armchair philosophy? I've actually looked at these, and used em a little bit. They're not at all as bad as I once thought they could be, and the reason they're there is to work with a concurrency framework onto which blocks can be scheduled to run on various queues, to do concurrent programming. If you're running Snow Leopard, they're being used all over the place for thread management. Here's my objective and actually informed review: Can something go horribly wrong with these blocks if you don't use them properly? You bet! Imagine many concurrently running blocks playing with shared global pointers... Luckily the serial queues are able to prevent that exact thing from happening. :-) Does it make the code easier to read? So far my answer is no, not at all. Does it succeed in the goal of making it possible to do lockless programming of concurrent applications? Yes, there's several rather interesting examples showing the concurrent computation of all the cells in Conway's Life for example. I'd say this beats the snot out of coding with pthreads. However, if I want real concurrency programming, I would NEVER use C over Erlang or Haskell by choice (or Limbo if it's available). Blocks themselves are really not terribly useful, you need the libdispatch library to make the real value in them come out, which does all the queue management by talking to the subsystem of Snow Leopard called Grand Central Dispatch. Dave On Wed, Sep 2, 2009 at 4:40 AM, Eris Discordia eris.discor...@gmail.comwrote: Perl people love closures. It's one of their common programming techniques. Closures in C? Way to screw its clarity and closeness to the real (or virtual) machine. And in the end closure or no closure doesn't change how the binary looks but allows programmers to pepper source with brain-teasers (now, what does _that_ evaluate to?). Not good at all. --On Wednesday, September 02, 2009 10:04 +0200 Anant Narayanan an...@kix.in wrote: Mac OS 10.6 introduced a new C compiler frontend (clang), which added support for blocks in C [1]. Blocks basically add closures and anonymous functions to C (and it's derivatives). Full details with examples are in the linked article. I think the feature is quite elegant and might be useful in cases where you want map/reduce like functionality in C. How much effort would it be to support a feature similar to blocks in 8c (and family)? What are your thoughts on the idea in general? -- Anant [1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
Re: [9fans] scheme plan 9
On Wed, Sep 2, 2009 at 7:30 AM, Iruata Souza iru.mu...@gmail.com wrote: On Wed, Sep 2, 2009 at 8:32 AM, Eris Discordiaeris.discor...@gmail.com wrote: Although, you may be better off reading SICP as intended, and use MIT Scheme on either Windows or a *NIX. The book (and the freaking language) is already hard/unusual enough for one to not want to get confused by implementation quirks. (Kill the paren!) for the most part of the book Plan 9 is as good as the mentioned options, except if you want a more lispy editor. iru Check out chibi-schemehttp://code.google.com/p/chibi-scheme/ foof on freenode in #scheme is working on it, and it's got Plan 9 support as well as others. Well last I heard from a friend who's been using and working with it. Dave
Re: [9fans] Blocks in C
One again, have you tried Cilk for exactly this kind of thing? I'd be curious to know your opinion on how what you see in SL compares to it. Nope, but it sounds interesting. Blocks themselves are really not terribly useful, you need the libdispatch library to make the real value in them come out, which does all the queue management by talking to the subsystem of Snow Leopard called Grand Central Dispatch. Could you, please, send me a pointer to the API docs? Off list, perhaps? http://developer.apple.com/mac/library/documentation/Performance/Reference/GCD_libdispatch_Ref/GCD_libdispatch_Ref.pdf Thanks, Roman.
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 9:38 AM, erik quanstrom quans...@quanstro.netwrote: On Wed Sep 2 10:33:07 EDT 2009, rminn...@gmail.com wrote: Q: Will C continue to be important into the future? (Dave Kirk, Nvidia)A: No, I think C will die like Fortran has isn't this the same company that claims that the cpu is dead? it may be true, but given nvidia's propensity to make claims that stretch credulity a wee bit that all just so happen to lead one to the conclusion — that nvidia will dominate the computer world in the near future with massive gpus, directx, and a tiny cpu. I know people claiming the GPU is dead. (The folks who make the Unreal gaming engine to start). - erik
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 9:58 AM, Robert Raschke rtrli...@googlemail.comwrote: On Wed, Sep 2, 2009 at 5:38 PM, erik quanstrom quans...@quanstro.netwrote: On Wed Sep 2 10:33:07 EDT 2009, rminn...@gmail.com wrote: Q: Will C continue to be important into the future? (Dave Kirk, Nvidia)A: No, I think C will die like Fortran has isn't this the same company that claims that the cpu is dead? it may be true, but given nvidia's propensity to make claims that stretch credulity a wee bit that all just so happen to lead one to the conclusion — that nvidia will dominate the computer world in the near future with massive gpus, directx, and a tiny cpu. - erik Gamers have a lot to answer for. Not just social decline ... ;-) Robby Found the reference: http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 10:31 AM, Eric Van Hensbergen eri...@gmail.comwrote: Clarifying context: this was at a hpc clusters conference -- their view of fortran is not your view of fortran. Having supported Fortran for MPI implementations before, I know what you mean :-) Sent from my iPhone On Sep 2, 2009, at 9:29 AM, ron minnich rminn...@gmail.com wrote: Q: Will C continue to be important into the future? (Dave Kirk, Nvidia)A: No, I think C will die like Fortran has ron
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller 9f...@hamnavoe.com wrote: http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf on p. 43/44 i believe it is claimed that one cannot do CSP without pure functional programming. (p ⇒ q) ⇏ (¬p ⇒ ¬q) That's interesting because pure functional programming doesn't exist at all in the strictest sense on a computer. One MUST be able to cause side effects during computation or your CPU will just get hot... if even that. Dave
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 11:35 AM, erik quanstrom quans...@coraid.com wrote: on p. 43/44 i believe it is claimed that one cannot do CSP without pure functional programming. (p ⇒ q) ⇏ (¬p ⇒ ¬q) That's interesting because pure functional programming doesn't exist at all in the strictest sense on a computer. One MUST be able to cause side effects during computation or your CPU will just get hot... if even that. i read the slides as contrasts, not as logical conjunctions. i still don't understand the claim that message passing requires thousands of message protocols and can't do syncronization. I also don't get that. What was meant by his usage of protocol. Erlang uses only a handful of patterns that work really well for interaction in each subsystem. If they think of messaging and protocols in a smalltalky way, then each class has a protocol of messages (methods) that must be implemented, but I don't get why that's bad. It's called an API. I mean HTTP has a small protocol, but if you count all the things you can do with REST, then it looks like a lot more. Dave - erik
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 12:11 PM, Brian L. Stuart blstu...@bellsouth.netwrote: Q: Will C continue to be important into the future? (Dave Kirk, Nvidia)A: No, I think C will die like Fortran has let me explain the joke. In HPC circles, people have been predicting the death of fortran for 30 years. Fortran has continued to grow and thrive. The predictions continue, but the latest fortran standard includes objects. So, what Dave is saying, tongue in cheek, is that C will die in the way fortran has -- i.e., not at all. I just hope standards committees don't enhance C into Frankenstein's monster. I actually think they might enhance C in this way in the ISO standard one day. The only nice bit is this is like C + a taped on block thingy. You don't have to use it, and your other C is not affected by this change. (I think) It's not like they're changing the semantics of the ; or anything. (or did they?)
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 12:10 PM, Jonathan Cast jonathancc...@fastmail.fmwrote: On Wed, 2009-09-02 at 11:27 -0700, David Leimbach wrote: On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller 9f...@hamnavoe.com wrote: http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf on p. 43/44 i believe it is claimed that one cannot do CSP without pure functional programming. (p ⇒ q) ⇏ (¬p ⇒ ¬q) That's interesting because pure functional programming doesn't exist at all in the strictest sense on a computer. One MUST be able to cause side effects during computation or your CPU will just get hot... if even that. *delurk* That's an excessively strict view. You need *output* for a program to be useful, but producing that output doesn't need to be intermixed with the program's algorithm to be useful; you can compute first, then output the results. Compute what first? You compute input, to produce output. You have no choice really. In haskell the entry point is main :: IO (). I rest my case. Note that I didn't say some code can't be pure, that's for the most part false (some would argue that even floating point math must be done in an impure way because one can set up the representation of floats differently, and that changes the purity of what would have been a pure function). Some code certainly can be executed in a pure sense, but at some point those values came in via a very dirty input process. The best part about Haskell is you can know by a functions type that no impure actions took place in a subset of your code. This does not falsify my claim that even pure functional programming languages require impure code. And if you prefer a plea to authority over logic, I haven't said anything that Simon Peyton Jones hasn't himself said about Haskell. Dave
Re: [9fans] nice quote
On Wed, Sep 2, 2009 at 1:23 PM, Jonathan Cast jonathancc...@fastmail.fmwrote: On Wed, 2009-09-02 at 13:02 -0700, David Leimbach wrote: And if you prefer a plea to authority over logic, I haven't said anything that Simon Peyton Jones hasn't himself said about Haskell. Well, I disagree quite strongly about Simon Peyton Jones about a number of things. Which I think I indicated by contradicting his stated positions on several of those points in my original post. My original message still stands as a reply to the rest of your post, so I won't repeat it. Fair enough! :-) jcc
Re: [9fans] nupas update
On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom quans...@quanstro.netwrote: i've pushed an update of my nupas contrib package to sources. imap successful in use with apple mail (snow leper, too), iphone, outlook, opera, ff, upas/fs. note on installing: as devon pointed out, installation is still a big pain. 1. move /sys/src/nupas - onupas 2. contrib/install quanstro/nupas if you want to go cold turkey nupas, then a. mv /386/bin/upas /386/bin/oupas b. mv /386/bin/nupas /386/bin/upas c. (opt)edit top-level mkfile to install in /386/bin/nupas. if you want to hedge your bets a. add usenupas to your profile b. edit cpurc as you see fit to use nupas binaries. cavet: i have not had a chance to retest the contrib package. as always, feedback welcome. So when you say that it works with Snow Leopard too, are you meaning that this works *on* snow leopard with something like FUSE 9p via plan 9 from user space? Just curious. - erik
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 9:23 AM, David Leimbach leim...@gmail.com wrote: On Fri, Aug 28, 2009 at 8:46 AM, erik quanstrom quans...@quanstro.netwrote: Also, Eric, the 9atom.iso works on my older AMD machine for installation! THANKS! :-) hey! back to the original story line. that's great, and you're welcome. i'd encourage anyone to report on your success or failure with 9atom offline. the goal is to get everything that should work working. - erik To further report the machine seems to be running after installation quite snappily though I seem to have messed something up and get a lot of messages about failed venti writes, due to a lack of a connection. Now that I've had a chance to really examine the system, I'm noticing a rather high interrupt count (1584), and I'm not exactly sure how to figure out what's triggering them. I did not install venti. I just configured my ip address for DHCP, and I've got aux/timesync running (I think that was suspect before for some reason). Stats shows interrupts as a solid rectangle of activity all the time.
Re: [9fans] new 9atom.iso
On Sat, Aug 29, 2009 at 10:25 AM, erik quanstrom quans...@quanstro.netwrote: Now that I've had a chance to really examine the system, I'm noticing a rather high interrupt count (1584), and I'm not exactly sure how to figure out what's triggering them. i set HZ=1000. so that accounts for 1000 of them. i've also modified /dev/irqalloc to count up the interrupts, so you should get a rough idea of which irqs are responsible. i say rough because chaned interrupts can confuse the matter a bit. I did not install venti. I just configured my ip address for DHCP, and I've got aux/timesync running (I think that was suspect before for some reason). Stats shows interrupts as a solid rectangle of activity all the time. i get that too from stats. it's just tuned to HZ=100. the reason for the increase is so that millisecond sleeps can work a bit better. on all the systems i use, the overhead is not worth worring about. Ah, I see so these are just normal interrupts of a healthy beating heart of a system. :-) I was a little concerned I had configured something incorrectly. Thanks for the explanation. - erik
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 1:54 AM, hiro 23h...@googlemail.com wrote: perhaps we should try to boot plan 9 from a linux kernel? Sounds great to me... this probably makes me a troll... I'm pretty sure Ron has done that too... from LinuxBIOS.
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 8:19 AM, erik quanstrom quans...@quanstro.netwrote: I'm pretty sure Ron has done that too... from LinuxBIOS. i'm pretty sure that coreboot neé linuxbios is not linux. Could be, I've never had the luxury of trying it all out... however I thought a minimal linux from coreboot/linuxbios (I think it was called linuxbios when this was tried) could kexec plan 9. I may be remembering incorrectly though (as usual). Dave - erik
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 8:33 AM, ron minnich rminn...@gmail.com wrote: On Fri, Aug 28, 2009 at 8:24 AM, David Leimbachleim...@gmail.com wrote: Could be, I've never had the luxury of trying it all out... however I thought a minimal linux from coreboot/linuxbios (I think it was called linuxbios when this was tried) could kexec plan 9. Actually i wrote something in 1999 called lobos that preceded kexec, and maybe even /dev/reboot (not sure). I still recall a linux groupie telling me that Linus would never accept linux rebooting linux into the kernel ... ha! I've got a reasonable summary article of kernels booting kernels -- all 5 versions of them -- in some cluster 200x paper. It concluded that Plan 9 was the cleanest of the lot. Surprise! Did that pre-date the two kernel monte that used to be used on Scyld's Beowulf thing? Also, Eric, the 9atom.iso works on my older AMD machine for installation! THANKS! :-) ron
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 8:46 AM, erik quanstrom quans...@quanstro.netwrote: Also, Eric, the 9atom.iso works on my older AMD machine for installation! THANKS! :-) hey! back to the original story line. that's great, and you're welcome. i'd encourage anyone to report on your success or failure with 9atom offline. the goal is to get everything that should work working. - erik To further report the machine seems to be running after installation quite snappily though I seem to have messed something up and get a lot of messages about failed venti writes, due to a lack of a connection.
Re: [9fans] new 9atom.iso
On Fri, Aug 28, 2009 at 9:37 AM, matt maht-9f...@maht0x0r.net wrote: To further report the machine seems to be running after installation quite snappily though I seem to have messed something up and get a lot of messages about failed venti writes, due to a lack of a connection. venti=/dev/sdC0/venti or venti=#S/sdC0/venti in plan9.ini not sure which is best, I have the former and it works but the latter was already in my plan9.ini and that didn't work but that might be something else and I've never experimented after it worked :) Thanks with 9atom, I just re-installed and installed a venti+fossil :-). That got rid of the messages, and I think I wanted to have venti anyhow.
Re: [9fans] 9P on android
I'm interested in doing some stuff with the Palm Pre. I'm actually looking at the javascript implementations of it as well. I just have practically no time to invest these days in this stuff. I think someone already got some of the plan 9 userspace tools on here though. Dave On Thu, Aug 27, 2009 at 1:20 AM, Enrico Weigelt weig...@metux.de wrote: Hi folks, I just purchased an G2-Touch phone (running Android) - a really cool toy, but it lacks 9P support ;-o Maybe someone's already working on this issue ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 174 7066481 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 9:16 AM, erik quanstrom quans...@quanstro.netwrote: 2009/8/26 erik quanstrom quans...@quanstro.net: it contains all the changes from the last 10 days. should fix all reported problems, except béla's. Could you post the link? I am new to this list and plan9, and i can not find a 9atom.iso, but a plan9.iso.bz2 [1] It would also be helpful for me reading some introductory material, i guess i can find it, but if you know some reference i would appreciate it. the link is ftp://ftp.quanstro.net/other/9atom.iso.bz2 cf819b70c90cedc39e305fb57d38f5df37302f84Aug 26 09:13 9atom.iso.bz2 just a point of clarification. the purpose of 9atom.iso is to help people get going who are having trouble with various sata or pata chipsets. i recommend using the standard cd if it works for you. applying the contrib packages to an official cd makes more sense as i hope that this one-off cd can go away in the future. it has different kernels and 9loads than the distribution. it also applies the ape strtod fix to awk, and doesn't use floating point in venti or fossil to avoid rounding errors. you can think of 9atom.iso as plan9.iso.bz2 + contrib quanstro/9load-e820 (binaries only) contrib quanstro/sd (binaries only) /n/sources/patch/apestrtod (awk binary only) /n/sources/patch/fossil-sleep-stress (venti moded, too) for my own convienence, there are some kernel differences not covered above. they should be inconsequential. but the source to that kernel is here ftp://ftp.quanstro.net/other/kernel.mkfs.bz2 - erik I think there's work going on to use plan 9 to load plan 9 (maybe?) to replace 9load. However, is there any chance of getting your 9load in the mainline if/once people determine it to support more hardware?
Re: [9fans] 9P on android
On Thu, Aug 27, 2009 at 8:59 AM, C H Forsyth fors...@vitanuova.com wrote: I'm actually looking at the javascript implementations of [9p] as well. has javascript finally got support for binary data? I haven't been following. I find a lot of web stuff to be off-putting, so I've not been keeping up. base64 encoding stuff is crap but could suffice in a pinch. Dave
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 10:05 AM, ron minnich rminn...@gmail.com wrote: On Thu, Aug 27, 2009 at 9:51 AM, David Leimbachleim...@gmail.com wrote: I think there's work going on to use plan 9 to load plan 9 (maybe?) to replace 9load. It's a gsoc project for Iruata to which I just gave a passing grade. it's doable. It needs a new PBS, which iruata wrote. ron COOL!
Re: [9fans] 9P on android
On Thu, Aug 27, 2009 at 9:57 AM, erik quanstrom quans...@coraid.com wrote: I haven't been following. I find a lot of web stuff to be off-putting, so I've not been keeping up. base64 encoding stuff is crap but could suffice in a pinch. uh, i don't think so. 9p2000 doesn't have a base64 encoding option. As long as the server can deal with decoding and turning it into 9p again, it's nearly the same thing (albeit a 9p proxy). I'm looking at these two implementations here to figure out how they work if binary javascript doesn't... http://www.kix.in/projects/web9/ http://code.google.com/p/limbo-machine/wiki/JS Dave - erik
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 9:16 AM, erik quanstrom quans...@quanstro.netwrote: 2009/8/26 erik quanstrom quans...@quanstro.net: it contains all the changes from the last 10 days. should fix all reported problems, except béla's. Could you post the link? I am new to this list and plan9, and i can not find a 9atom.iso, but a plan9.iso.bz2 [1] It would also be helpful for me reading some introductory material, i guess i can find it, but if you know some reference i would appreciate it. the link is ftp://ftp.quanstro.net/other/9atom.iso.bz2 cf819b70c90cedc39e305fb57d38f5df37302f84Aug 26 09:13 9atom.iso.bz2 I really don't understand why, from home or work, I can't download this thing... cf819b70c90cedc39e305fb57d38f5df37302f84 Is the checksum I'm getting. When I download via a web browser it gets to the last bit of the data, and craps out. When I use an ftp client, it claims it is complete, but then gets the wrong checksum. I'm totally baffled. Is there somewhere else I can try to pull this from? Dave
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 1:20 PM, erik quanstrom quans...@quanstro.netwrote: I really don't understand why, from home or work, I can't download this thing... cf819b70c90cedc39e305fb57d38f5df37302f84 Is the checksum I'm getting. that's the same checksum i posted. i guess i don't understand the problem. the file size is 88153831. Yeah, I realized that after I posted I sent the wrong checksum. e4441484b67be72ad0fd62cc828052f6 9atom.iso.bz2 is what I got. When I download via a web browser it gets to the last bit of the data, and craps out. When I use an ftp client, it claims it is complete, but then gets the wrong checksum. I'm totally baffled. Is there somewhere else I can try to pull this from? no alternate locations. sorry. - erik
Re: [9fans] new 9atom.iso
On Thu, Aug 27, 2009 at 1:59 PM, erik quanstrom quans...@quanstro.netwrote: Yeah, I realized that after I posted I sent the wrong checksum. e4441484b67be72ad0fd62cc828052f6 9atom.iso.bz2 is what I got. that's the proper md5sum. i posed the sha1sum. maybe i didn't make that clear. - erik argh... :-(
[9fans] vmware oddity (Fusion on Mac OS X)
Just fired up my plan 9 image in VMWare, and I noticed that gnot is showing a large amount of interrupts, and then the whole tracking of the system interrupts goes to nothing, the mouse stops working, and things are generally frozen. However, the odd bit is at one point time seemed to speed up and gnot went really fast, before freezing again. anyone experienced this? It just unfroze again, but l i s and c on gnot are totally pegged. :-( Dave
Re: [9fans] vmware oddity (Fusion on Mac OS X)
now i am getting repeated soverflow for fx-in messages repeatedly. On Tue, Aug 18, 2009 at 7:20 AM, David Leimbach leim...@gmail.com wrote: Just fired up my plan 9 image in VMWare, and I noticed that gnot is showing a large amount of interrupts, and then the whole tracking of the system interrupts goes to nothing, the mouse stops working, and things are generally frozen. However, the odd bit is at one point time seemed to speed up and gnot went really fast, before freezing again. anyone experienced this? It just unfroze again, but l i s and c on gnot are totally pegged. :-( Dave
Re: [9fans] vmware oddity (Fusion on Mac OS X)
On Tue, Aug 18, 2009 at 7:32 AM, erik quanstrom quans...@quanstro.netwrote: On Tue Aug 18 10:28:44 EDT 2009, leim...@gmail.com wrote: now i am getting repeated soverflow for fx-in messages repeatedly. it sounds like the interrupt handler takes long enough that there is no time to process the incoming frames. i wonder, are you running venti? I am, and venti took a long time to start at boot this time around. I suppose I should just run fossil in vmware. - erik
Re: [9fans] Thrift RPC
On Thu, Aug 13, 2009 at 8:41 PM, Uriel urie...@gmail.com wrote: On Thu, Aug 13, 2009 at 4:27 PM, David Leimbachleim...@gmail.com wrote: On 8/13/09, erik quanstrom quans...@coraid.com wrote: we don't use te*xt for 9p, do we? the difference being, 9p is the transport not the representation of the data and 9p has a fixed set of messages. Also 9p aims at file systems pretty obviously where Thirft is a generic RPC mechanism with stub compilers for bindings for several languages. I have not been able to convince coworkers that filesystem namespaces are the way to go. I think they think it is too hard. *shrug* you can lead a horse... Funny, the problem I usually have is that people think file systems are *too simple*, oh, no data types other than *byte stream* and *drectory*, and no type checking! We are all going to die! Interestingly enough, people dealing with management of servers have been using stuff like SMASH CLP, which uses commands like cd and show, which may as well have been cd or ls to access system resources. I'm talking about smart power strips from Raritan, which have power monitoring and control per receptacle. So really, a lot of the things I do like about plan 9 are just nearly there in the wild in some cases, and feel quite natural. The next step is to make a generic CLP filesystem that speaks 9p :-). Might be fun, but I don't have an extra 600 dollars for a power strip right now :-) People seem to have trouble believing something simple can do a job that they have convinced themselves needs to be very complicated. Seems like in some cases people still do want the simplicity of filesystem access. So perhaps we're not entirely screwed yet. :-) Dave uriel
Re: [9fans] Thrift RPC
On Mon, Aug 17, 2009 at 8:44 AM, ron minnich rminn...@gmail.com wrote: It had to happen: System and method for accessing SMASH-CLP commands as a web service United States Patent Application 20080016143 Oh there's absolutely no prior art there ... in the namespace thing. I think I'm going to patent patenting things now, and then sue everyone. I can be a professional sewer. Dave ron
Re: [9fans] Thrift RPC
On 8/13/09, erik quanstrom quans...@coraid.com wrote: we don't use te*xt for 9p, do we? the difference being, 9p is the transport not the representation of the data and 9p has a fixed set of messages. Also 9p aims at file systems pretty obviously where Thirft is a generic RPC mechanism with stub compilers for bindings for several languages. I have not been able to convince coworkers that filesystem namespaces are the way to go. I think they think it is too hard. *shrug* you can lead a horse... - erik
Re: [9fans] Plan 9 hg with private repositories
On Thu, Aug 13, 2009 at 2:47 AM, Ethan Grammatikidis eeke...@fastmail.fmwrote: On Thu, 13 Aug 2009 11:13:58 +0200 Bela Valek bval...@gmail.com wrote: Correct me if I am wrong, but an sshv2 server is also providing sshv1 too. I vaguely remember reading that some ssh software would refuse to work with ssh v1 by default because v1 is so insecure. Many times you must turn v1 on, but it's available. It's off by default due to it being insecure. -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] Using proportional fonts in Acme for Programming
On Thu, Aug 13, 2009 at 10:55 AM, Daniel Lyons fus...@storytotell.orgwrote: On Aug 13, 2009, at 3:14 AM, Aaron W. Hsu wrote: So, I was browsing around the other day looking at Acme resources, and I discovered an old post from 1995 wherein someone advocated the use of proportional fonts for programming in Acme. This surprised me, to say the least. He even went as far as to mention that SML was the language they were using, and had managed to get a decent indenting pattern for it that was just as readable, without messing things up for proportional font users. I have to admit that I'm a bit skeptical about whether such a technique actually works, and so, I thought I would pose some questions to you. Bjarne Stroustrup actually advocates this style in The C++ Programming Language. This discussion reminds me of this elastic tab stops concept: http://nickgravgaard.com/elastictabstops/ I don't think it made it into any editors, but it would support the kind of fancy alignment I like to have in my code while also supporting real fonts, which I would prefer to use. Thirdly, would you continue using proportional width fonts in cases like Lisp code, where you very often see something like the following indentation scheme, and how would you resolve these indentation problems with proportional width fonts if you did continue to use them? (let ([foo bar] [something else]) (some-func (called again) (with fun indentation) (and yet) (another))) I bet you could set up Emacs to use a proportional font. It can do anything, right? :) I'd love it if Acme or Plan 9 had good support for some kind of Lisp variant. Acme has good enough support for Lisp in that I can edit the program buffer, and then re-load it all in Acme via the win program. I use it with SBCL this way on my mac actually. Emacs + SLIME is pretty nice, but sometimes quite a bit more than I need. — Daniel Lyons
Re: [9fans] oh, no! (again)
On Tue, Aug 11, 2009 at 10:57 AM, erik quanstrom quans...@quanstro.netwrote: i don't know where it's getting the 9pcf that it's putting in 9fat. it doesn't appear to be the same as /386/9pcf from the cd. (there's only one.) as soon as i figure that out, this will probablly all work. okay. the cd was rolled correctly, but i discovered a potential source of confusion. evidently the installer didn't want to overwrite the bad 9pcf and 9load that were already in 9fat. so download a new copy of 9atom.tar.bz2 and when you start the installer, make sure to zero out 9fat at a minimum. to do this - open a new window - dd -if /dev/zero -of /dev/sdXX/9fat -bs 4k When I download this ISO, it gets to what appears to be the last byte then aborts.
Re: [9fans] Acme niceties
On Tue, Aug 11, 2009 at 8:24 PM, erik quanstrom quans...@quanstro.netwrote: (Did you ever notice it puts it back when it's done? Error window pops up, mouse moves there; delete the window, mouse moves back.) worth one smile per day, after all these years. ☺ - erik
Re: [9fans] linux reinvents factotum, secstore ...
On Fri, Aug 7, 2009 at 10:34 AM, Daniel Lyons fus...@storytotell.orgwrote: On Aug 7, 2009, at 7:06 AM, Ethan Grammatikidis wrote: X11 isn't a desktop, it tries very hard not to define a look and feel, but it has to include inter-app communications to support the supposedly desirable drag drop as well as any copy/paste beyond plain text. In fact my big beef with dbus is that everything is all hot-all-over about dbus when it needs to be using X IPC. My beef is that they were hot-all-over CORBA not too long ago. I expect in another three years nobody will be using D-Bus, they'll be using some new layer that sits on top of it... ad nauseam. Outside Plan 9 I don't see anyone solving two problems with one technology; instead, they're just solving one problem and introducing a new one. Yeah they were hot on CORBA, and KDE folks were doing DCOP, which was derived from some X11 ICE thing... Neither of them was that great, and somehow they've both come back to DBUS. I don't honestly know the rhyme or reason for any of it. Anyone who thought CORBA was the answer didn't seem to understand the question. — Daniel Lyons
Re: [9fans] a few Q's regarding cpu/auth server
Now here's the point. I and a billion other people HAVE MORE FUN THINGS TO DO THAN FRET ABOUT SECURITY. A weak OS needs me to put in boring work... Hah... yes, that would be why I'm merely reading this thread instead of adding to it... Oh crap, nevermind :-) -- Ethan Grammatikidis Those who are slower at parsing information must necessarily be faster at problem-solving.
Re: [9fans] more time amusement under vmware
On Mon, Aug 3, 2009 at 10:56 PM, roger peppe rogpe...@gmail.com wrote: the time problem i was having before (fast clock) had seemed to be irreproducible. however just now, i noticed the following odd behaviour: fiddle% date -u Thu Jan 1 00:00:00 GMT 1970 fiddle% cat /dev/time 0 0 0 1 fiddle% fiddle% # wait a few seconds fiddle% cat /dev/time 0 0 0 1 fiddle% the clock is completely stopped! (although sleep doesn't sleep forever - sleep 10 sleeps for about 3.43 seconds, so *something* has a concept of time) most odd. Yeah.. :-( Odd and crappy. I can't figure out why this would happen.
Re: [9fans] Parallels Vesa driver question
On Tue, Aug 4, 2009 at 12:25 AM, Bakul Shah bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com wrote: On Mon, 03 Aug 2009 20:12:08 PDT David Leimbach leim...@gmail.com wrote: Wow Where's parallels 4. I doubt I qualify for a free one. And VMWare Fusion really sucks with Plan 9 at the moment :-( qemu works well enough for me on FreeBSD Linux but not on a Mac. VirtualBox doesn't run plan9 but it runs FreeBSD, Linux and Windows fairly well so may be there is hope. There is an open source version of VirtualBox that might be worth tinkering with. I was considering giving qemu a try on the mac. I believe there's a mac centric front-end for it even. In fact, how much of virtualbox is using qemu?
