[9fans] Blocks in C
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] lowest valid stack address
2009/9/2 erik quanstrom quans...@quanstro.net: aside: from the overcommit vm discussion. in http://9fans.net/archive/2000/06/634 rob says that plan 9 doesn't overcommit vm. what's the history here? Exactly two years ago you started a thread about memory overcommit. If I remember correctly, plan9 overcommits vm. Few weeks later the Go program from gorka crashed while allocating the stack, maybe an overcommiting check was added, probably gorka knows. Andrés
[9fans] scheme plan 9
HI,everyone: Has anyone ported scheme into plan 9 ? or is there some scheme implementation existence on plan 9 ? i want to learn SCIP recently ,but i can't find a scheme in plan 9 . so ask .. looking forward for the answer as soon as possible... thanks first.
Re: [9fans] lowest valid stack address
2009/9/2 Andrés Domínguez andres...@gmail.com: 2009/9/2 erik quanstrom quans...@quanstro.net: aside: from the overcommit vm discussion. in http://9fans.net/archive/2000/06/634 rob says that plan 9 doesn't overcommit vm. what's the history here? Exactly two years ago you started a thread about memory overcommit. If I remember correctly, plan9 overcommits vm. Few weeks later the Go program from gorka crashed while allocating the stack, maybe an overcommiting check was added, probably gorka knows. I don´t think there was an extra check added for this, that was probably coincidence. I think that was some other effect. The vm space may (and normally is) bigger than the physical memory (that is what vm is about). but not the quantity really backed up by physical memory because there is no swap (there is but noone uses it). If you don´t touch the memory, it never gets mapped in, so you may reserve a big chunk, but it has to fit in your vm in the space between the stack and the bss. In my go program I was reserving something unreasonable like 1Gb (I was doing some funny things with it) of stack using the thread library and I probably ran out of vm space for the proc and the kernel does check this. -- - curiosity sKilled the cat
Re: [9fans] scheme plan 9
number of schemes 4 http://www.plan9.bell-labs.com/wiki/plan9/Contrib_index/ maybe one is what you are looking for there is also a gsoc project, search 9fans for more details http://9fans.net/archive/ xiangyu wrote: HI,everyone: Has anyone ported scheme into plan 9 ? or is there some scheme implementation existence on plan 9 ? i want to learn SCIP recently ,but i can't find a scheme in plan 9 . so ask .. looking forward for the answer as soon as possible... thanks first.
Re: [9fans] Blocks in C
IMHO, I'd say C is C and I think it's better to leave it as it is. If you want a language with extra features you can probably find one. 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. 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] Blocks in C
IMHO, I'd say C is C and I think it's better to leave it as it is. If you want a language with extra features you can probably find one. the blocks thing only works (apparently) by having two (visible) classes of function pointers. ugh. `clang' is apparently not just the name of the frontend but the sound it makes (cf. the `cricket bat' speech in Stoppard's `The Real Thing'). automatic memory management is more fundamental for application programming. i agree with nemo. every time i happen to see nick stoughton i suggest they should just STOP changing C. (it doesn't work. i'll probably stop suggesting it.) one thing that gets me is that i've had people fulminate about the few minor changes in Plan 9's C compilers, because `they are not standard', yet unlike the endless tinkering in the gcc (and now Apple) world they were made by someone who at least had some close connection with the original language (not to mention a sense of style).
Re: [9fans] scheme plan 9
number of schemes 4 http://www.plan9.bell-labs.com/wiki/plan9/Contrib_index/ One that's not in the contrib tree is s9fes (Scheme 9 From Empty Space). BLS
Re: [9fans] scheme plan 9
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!) --On Wednesday, September 02, 2009 10:21 +0100 matt maht-9f...@maht0x0r.net wrote: number of schemes 4 http://www.plan9.bell-labs.com/wiki/plan9/Contrib_index/ maybe one is what you are looking for there is also a gsoc project, search 9fans for more details http://9fans.net/archive/ xiangyu wrote: HI,everyone: Has anyone ported scheme into plan 9 ? or is there some scheme implementation existence on plan 9 ? i want to learn SCIP recently ,but i can't find a scheme in plan 9 . so ask .. looking forward for the answer as soon as possible... thanks first.
Re: [9fans] Blocks in C
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] Blocks in C
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. Peace uriel 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] lowest valid stack address
2009/9/2 Andrés Domínguez andres...@gmail.com: 2009/9/2 erik quanstrom quans...@quanstro.net: aside: from the overcommit vm discussion. in http://9fans.net/archive/2000/06/634 rob says that plan 9 doesn't overcommit vm. what's the history here? Exactly two years ago you started a thread about memory overcommit. If I remember correctly, plan9 overcommits vm. Few weeks later the Go program from gorka crashed while allocating the stack, maybe an overcommiting check was added, probably gorka knows. No checks have been added. I started a rather active thread about this a few months ago in attempt to figure out a way to `protect' from this behavior starving the kernel of memory and thus panicking. I'll leave it up to Elly to find some way to actually exploit this :). The problem ended up being that I'd have to rework a lot of the slab allocator, or do checks on every memory allocation, and I didn't want to do that. More detailed info for those who care: Lemma: In order to avoid overcommitting, we must impose limits on how much memory may, in fact, be allocated. To make the implementation provable, you must be able to assert that memory always comes from the same spot, and you thus have a single path to follow into allocation. Memory limits must be enforced based on real hardware in the system. The issue here is that some slabs will always fill up disproportionately to others. Thus, whichever limit you impose, slabs must be growable. Thus: - Systemic limits require you to be able to migrate pages between zones. - Per-zone memory limits are silly because you have to be able to migrate pages between zones, - Per-process and per-user memory limits are silly, though easier to implement, because they add too much overhead to allocations and frees. Basically, it boils down to: If you want to implement this effectively, the slab allocator needs to be reworked so that memory zones can `steal' pages from other zones. If this is a real issue, I'm happy to go take another stab at it: I stopped working on it last time because it seemed most people found it a non-issue. --dho Andrés
Re: [9fans] lowest valid stack address
Exactly two years ago you started a thread about memory overcommit. If I remember correctly, plan9 overcommits vm. Few weeks later the Go program i thought this was common knowledge, and so i ommitted recounting the discussion. since it's not common knowledge i'll recount. plan 9 overcommits vm. a large amount of this overcommit is due to the stack, since the kernel gives each process a 16mb segment. overcommit means you can malloc n bytes or even use a few extra bytes on the stack but will fault when accessing it. needless to say, overcommit is not much fun. executables are paged out even with no swap. the reason for the crash of the Go program is that the stack segment is 16mb. while plan 9 will demand load and zero fill within the stack segment, it's just a fault to try to access memory outside of any segment. therefore, we know the Go program had a stack =16mb. (by careful arrangement, the page below the stack is generally invalid — it's not in any segment.) the bss, stack and shared segments are zero-filled on demand. it doesn't appear they can be paged out. If you don´t touch the memory, it never gets mapped in, so you may reserve a big chunk, but it has to fit in your vm in the space between the stack and the bss. In my go program I was reserving something unreasonable like 1Gb the maximum segment allowed by the pc kernel is 1984mb. (SEGMAPSIZE*PTEPERTAB*BY2PG), see segment.c:/^by2pg - erik
Re: [9fans] lowest valid stack address
problem ended up being that I'd have to rework a lot of the slab allocator, or do checks on every memory allocation, and I didn't want to do that. More detailed info for those who care: could you use plan 9 terminology? Lemma: In order to avoid overcommitting, we must impose limits on how much memory may, in fact, be allocated. To make the implementation provable, you must be able to assert that memory always comes from the same spot, and you thus have a single path to follow into allocation. from the same spot could mean from the same point in the code or from the same physical address. either way, i don't buy this assertion. counter example: ssd drive remapping algorithms. - erik
Re: [9fans] Blocks in C
Hi kix (Anant), I don't like it, but the question is: do you need it? If you can do the same code with 8c, without much efford, then probably you don't need it. kix 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. 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 -- Rodolfo García kix EA4ERH - IN80ER
Re: [9fans] lowest valid stack address
2009/9/2 erik quanstrom quans...@quanstro.net: problem ended up being that I'd have to rework a lot of the slab allocator, or do checks on every memory allocation, and I didn't want to do that. More detailed info for those who care: could you use plan 9 terminology? Probably not. Plan 9 uses a slab allocator to allocate memory in both kernel and userland. The only fault I see in my previous email is saying `zone' instead of `pool', but they're synonymous enough. If you cite a specific ambiguity, I'm more than happy to clarify. Lemma: In order to avoid overcommitting, we must impose limits on how much memory may, in fact, be allocated. To make the implementation provable, you must be able to assert that memory always comes from the same spot, and you thus have a single path to follow into allocation. from the same spot could mean from the same point in the code or from the same physical address. either way, i don't buy this assertion. counter example: ssd drive remapping algorithms. That was a rather poor choice of words. Restatement: To prove the safety of the implementation, you must be able to assert that any memory allocation triggers a check on the availability of the requested memory. This revised statement doesn't require that a single code path be followed into allocation, but since malloc() obtains memory from the slab allocator, it makes sense to build the protection into the slab allocator: it's centralized, and all allocations are guaranteed to go through there anyway. The safety of such an implementation is much easier to prove. I hope that clarifies what I meant. Example for what I did not mean: the FreeBSD jail system `virtualizes' kernel resources by partitioning them to certain jail IDs. This requires any resources wishing to be shared to be jail-aware, with the side-effect that proving a jail only has access to what it needs is much more difficult, because you have to prove that every resource is `protected' anywhere that it is potentially used in the kernel. The analogue to this sort of thing for our discussion would be introducing an additional API to be used in conjunction with malloc(), requiring it to be used every time. Clearly, it is more difficult to prove that all mallocs() are safe with such an API, and it is *impossible* to prove that future calls will be protected, as it is impossible to prove that future additions to the kernel are properly handled with respect to jails. It's a somewhat silly comparison (as no one in their right mind would implement this as an API to be used alongside malloc), but it illustrates my point well. And it was easier to come up with that than coming up with some other theoretical non-centralized (from a code point of view) solution to this problem. --dho - erik
Re: [9fans] Blocks in C
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. 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. --dho
Re: [9fans] scheme plan 9
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
[9fans] nice quote
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
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 ... :-) 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 ron -- Rodolfo García kix EA4ERH - IN80ER
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
On Wed, 2009-09-02 at 10:04 +0200, Anant Narayanan 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).
They are NOT closures in my book. They lack lexical scoping. A true
closure makes the following possible (using JavaScript to stay closer
to C syntax):
function outer() {
var outer_var = 1;
return function () {
outer_var = { simply: a different object }
}
}
Notice how I can modify outer_var from within the closure. With blocks
all you get is an upvaluer (IOW, outer_var becomes constant).
This is still useful for things like map, etc. But I hate when people
call anonymous classes in Java closures (although depending on
a textbook it is possible to stretch the term).
Finally, if you want to know how to get from GCC blocks to the real
deal read up 6.6 of this excellent paper:
http://www.lua.org/doc/hopl.pdf
Full details with examples are in the linked article.
The article seems to miss a couple of important points. And the
better alternative for those who want to know what's going on
is Apple's developer website:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html#//apple_ref/doc/uid/TP40007502-CH1-SW1
I think the feature is quite
elegant and might be useful in cases where you want map/reduce like
functionality in C.
It is a fun feature, no doubt. It is also pretty easy to implement.
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?
Personally I think you'd be better off exploring a connection that a
language called Lua has to C. In the immortal words of Casablanca it
just could be the begging of a beautiful friendship.
Thanks,
Roman.
Re: [9fans] Blocks in C
On Wed, 2009-09-02 at 08:07 -0700, David Leimbach wrote: Has anyone actually looked at the spec Yes. Well, I know I did ;-) 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. Right-O. In fact, blocks are particularly, how shall I put it, congruent to the most promising C parallelization framework to date: Cilk. 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. 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. 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? Thanks, Roman.
Re: [9fans] nice quote
(Dave Kirk, Nvidia) A: No, I think C will die like Fortran has http://developer.nvidia.com/page/cg_main.html
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.
[9fans] 9intro book in lulu
Hi, as you may know, the Introduction to OS Abstractions book (aka 9intro) is avail in pdf in various places from the web. It will continue that way, btw. But, as some asked for that and I think it's nice, it's also available at lulu.com. This is the url. http://www.lulu.com/content/paperback-book/introduction-to-os-abstractions-using-plan-9-from-bell-labs/7609919 hth
Re: [9fans] scheme plan 9
On Wed, 02 Sep 2009 12:32:53 BST Eris Discordia eris.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!) The second edition of SICP uses IEEE Scheme (basically R4RS Scheme) and pretty much every Scheme implementation supports R4RS -- s9fes from http://www.t3x.org/s9fes/ certainly supports it. It doesn't support rational or complex numbers but as I recall no example in SICP relies on those. Killing parens won't make you an adult :-)
Re: [9fans] nice quote
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
Re: [9fans] Interested in improving networking in Plan 9
On Mon, 31 Aug 2009 11:33:13 CDT Eric Van Hensbergen eri...@gmail.com wrote: On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.com wrote: An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface. The fact that its not immediately clear is what makes it a good research topic. It will likely take several iterations to identify a best fit interface with the likely result that multiple interfaces/views are required. I think there are precious little information on synthetic file system design, given its continuing popularity in the non-Plan-9 world, we could use more published wisdom/experiences from the evolution of various file-system based interfaces. Oh I don't know Shoehorning a DB interface into a FS interface doesn't feel right but stranger things have happened.
Re: [9fans] scheme plan 9
I use chibi at work; s'not bad considering the size, certainly better than tinyscheme. I currently use a custom dialect for new stuff, but the old is either Chibi or Gauche. On Wed, Sep 2, 2009 at 11:13 AM, David Leimbach leim...@gmail.com wrote: 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 -- And in the Only Prolog programmers will find this funny department: Q: How many Prolog programmers does it take to change a lightbulb? A: No. -- Ovid By cosmic rule, as day yields night, so winter summer, war peace, plenty famine. All things change. Air penetrates the lump of myrrh, until the joining bodies die and rise again in smoke called incense. Men do not know how that which is drawn in different directions harmonises with itself. The harmonious structure of the world depends upon opposite tension like that of the bow and the lyre. This universe, which is the same for all, has not been made by any god or man, but it always has been, is, and will be an ever-living fire, kindling itself by regular measures and going out by regular measures -- Heraclitus
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 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
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] Interested in improving networking in Plan 9
On Wed, Sep 2, 2009 at 5:50 PM, Bakul Shah bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com wrote: On Mon, 31 Aug 2009 11:33:13 CDT Eric Van Hensbergen eri...@gmail.com wrote: On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com wrote: An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface. The fact that its not immediately clear is what makes it a good research topic. It will likely take several iterations to identify a best fit interface with the likely result that multiple interfaces/views are required. I think there are precious little information on synthetic file system design, given its continuing popularity in the non-Plan-9 world, we could use more published wisdom/experiences from the evolution of various file-system based interfaces. Oh I don't know Shoehorning a DB interface into a FS interface doesn't feel right but stranger things have happened. There are some folk about who are working on a distributed spreadsheet ( hypernumbers.com, there used to be a trial system up and lots of documents, but I'm not sure where that all went, and I can't be bothereed signing up just now, they're presenting at ICFP CUFP on Friday, so the company/project should still be properly alive). Anyway, the idea they've got is that every cell in a spreadsheet has a URL and you can reference and use cells across a distributed space. Interesting idea, but I'm not entirely sure what to do with it, being spreadsheet-challenged myself. Robby
Re: [9fans] nice quote
Clarifying context: this was at a hpc clusters conference -- their view of fortran is not your view of fortran. 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
Found the reference: 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. the thread library is clearly better than i thought. it can turn ordinary c into a functional programming language! ☺ - erik
Re: [9fans] Blocks in C
On Wed, 02 Sep 2009 08:20:52 PDT Roman V Shaposhnik r...@sun.com wrote:
On Wed, 2009-09-02 at 10:04 +0200, Anant Narayanan 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).
They are NOT closures in my book. They lack lexical scoping. A true
closure makes the following possible (using JavaScript to stay closer
to C syntax):
function outer() {
var outer_var = 1;
return function () {
outer_var = { simply: a different object }
}
}
From reading the URL you cited, it seems you can't return a
block from a function but you can sort of achieve the same
effect by declaring a global `block variable' and assigning a
block to it -- now you can use this block var elsewhere.
int (^ugly)();
int outer() {
__block int outer_var = 1;
ugly = ^{ outer_var = 42; }
}
Presumably __block says outer_var is allocated on heap so now
it can live beyond the life of a particular invocation of
outer(). outer_var will have to be freed when ugly is
assigned to a different block. So it seems GC is a
requirement now. The original C features were just right
to keep the compiler simple and still provide a lot of
expressive power. IMHO GC doesn't fit that model.
Because of the heap allocation, most likely you won't get a
proper closure. For instance, in Scheme
(define (counter)
(let ((x 0))
(lambda () (set! x (+ x 1)) x)))
(define c1 (counter))
(c1) = 1
(c1) = 2
(define c2 (counter))
(c2) = 1
(c1) = 3
etc.
Thus on every invocation of the counter function you get a
fresh counter x and c1 and c2 increment their own copy of x
independently. With blocks you'd render the above as
something like:
typedef int(^ctr_t)();
int counter(ctr_t*c) {
__block int x = 0;
*c = ^{ return ++x; }
}
ctr_t c1, c2;
void foo()
{
counter(c1); // presumably taking address of a block var is allowed
printf(%d\n, c1());
printf(%d\n, c1());
counter(c2);
printf(%d\n, c2());
printf(%d\n, c1());
}
I bet you'd get 1 2 3 4, and not 1 2 1 3. If they do get this
right, they'd have to allocate a fresh x on every invocation
of counter and this will add to the memory garbage. Now their
GC problem is even worse! And I haven't even used
concurrency so far!
They very carefully delineate what you can and can not do
with lexically scoped variables etc. but the model is far
more complex.
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?
Personally I think you'd be better off exploring a connection that a
language called Lua has to C. In the immortal words of Casablanca it
just could be the begging of a beautiful friendship.
Amen! Or kill one's prejudice against parens (talk to your
parens!) and use Scheme which is about as simple as it can
get.
Re: [9fans] nice quote
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)
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 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. - erik
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 7:29 AM, 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 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. ron
Re: [9fans] nice quote
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. That reminds me of another amusing story. It seems that back in the 70s or 80s someone asked some big name in CS what people would be programming with in the year 2000. His response: I don't know, but it'll be called FORTRAN. This isn't your father's FORTRAN... BLS
Re: [9fans] nice quote
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. Furthermore, I don't think it's sophistry to say that you don't need side effects to do output. ALGOL-derived languages use side effects for output, because (to take C as an example) the type of an expression like print(Hello, world\n) is taken to be `int', and thus the `value' of that expression must be some integer --- say, 13. Then you need to add a concept of `side effects' to express the fact that there's more going on here than just calculating the number 13. Purely functional programming doesn't eschew I/O (although it encourages a style that separates I/O from algorithms --- as does good programming style in any language); rather, it re-works the types of the I/O operations so that, if you have a function foo :: String - Int the value of foo Hello, world!\n really is just an integer (and there's nothing else going on to introduce side-effects to talk about). Whereas if you have a function bar :: String - IO Int then the value (as expressed in the language and understood by the programmer) of bar Hello, world!\n is a combination of I/O behavior, concurrency, etc. So you don't need to introduce a concept of `side effects' to talk about those things. If you were building a denotational semantics for C, this how you would deal with I/O. The value (denotation) of a C expression of type int would be a combination of I/O behavior, assignment behavior, etc., as well as (possibly, due to the possibility of non-termination) an integer. Purely functional programming just reduces the degree of difference between the denotational semantics of the language and the programmer's mental model of it. Which is very likely all I have to say on the subject. jcc
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?)
[9fans] plan9.iso and 9atom.iso fail on SATA IDE system
Hi, The test subject is a desktop PC, it has SATA primary harddrive and IDE master optical drive (according to the BIOS). I tried to install with the regular CD (Aug. 15), it detected the SATA harddrive only. I also tried Erik's 9atom.iso, it detected the IDE drive only, so it booted the Live CD only. It reported 47 e820 entries during boot. (i try to get access to the other test subject too, so i can post its error messages. the problem is, that its not in my possession) Greetings: Béla
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] plan9.iso and 9atom.iso fail on SATA IDE system
The test subject is a desktop PC, it has SATA primary harddrive and IDE master optical drive (according to the BIOS). I tried to install with the regular CD (Aug. 15), it detected the SATA harddrive only. I also tried Erik's 9atom.iso, it detected the IDE drive only, so it booted the Live CD only. It reported 47 e820 entries during boot. what date 9atom.iso? the latest is from aug 26. it detects more hardware. could you send me the output of pci or lspci -nv or whatever offlist? - erik
Re: [9fans] nice quote
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. jcc
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] nice quote
On Wed, 2009-09-02 at 12:11 -0700, Brian L. Stuart wrote: 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. A friend of mine, who is still serving on the C committee, once mentioned who lucky they were to have C++ around as a perfect dumping ground for all the cool enhancements that got proposed along the way. Thanks, Roman. P.S. Another friend of mine still feels sad that Fortress didn't become that same sort of dumping ground for Fortran ;-)
[9fans] nupas update
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. - erik
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] nupas update
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? imap4d and upas/fs are running on a regular plan 9 install. apple mail is running as normal. there is no 9p required on the mac. while i'm sure that the p9p client stuff would work with nupas imap4d, it would take work to port the servers. - erik
