Re: [racket-dev] A basic package system
Bullet point 2 seems like it may overlap (in a practical, what do I use today sort of a way) with Matthew's modulelet construct. Both group modules together, both provide independently loadable things. Do we really want/need both of these? Robby On Tue, Jul 26, 2011 at 5:49 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Eli and I had a very useful conversation last night and we realized that a lot of the ideal package system we are imagining is within our reach very quickly. Today I made a demonstration of our ideas: https://github.com/jeapostrophe/exp/tree/master/pkgs There's a README there. Once you read it, Run use/program.rkt Then edit use/pkg-in.rkt and change the safe to unsafe You'll see that it changes the meaning of racket/listy module reference in use/program.rkt I haven't implemented the module algebra, but it should be clear from looking at the macro implementations that the existing identifier algebra in require/provide will work transparently. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call
On Jul 27, 2011, at 1:29 AM, Ryan Culpepper wrote: Checklist items for the v5.1.2 release (using the v5.1.1.900 release candidate build) Search for your name to find relevant items, reply when you finish an item (please indicate which item/s is/are done). Also, if you have any commits that should have been picked, make sure that the changes are in. Important: new builds are created without announcement, usually whenever I pick a few commits. If you need to commit changes, please make sure you tell me to pick it into the release branch. -- Release candidates are at -- http://pre.racket-lang.org/release/installers This installer page still shows Saturday 23rd as the most recent build. I believe I'm blocked on this. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A basic package system
They have more similarities than your message suggests I believe. And it is probably worth exploring that. As far as I can see a facet/modulet has less stuff than a package and possibly a different story vis a vis files in the filesystem. Robby On Wednesday, July 27, 2011, Jay McCarthy jay.mccar...@gmail.com wrote: I don't see them as overlapping, but you may understand them different than I do. The way I see modules/facets is that 'racket/list.rkt' will have a 'default' facet and a 'testing' facet and a 'documentation' facet, so that each use can be syntactically close but separately loadable. The way I see packages is that they allow indirection of module paths, so that inside 'a.rkt', 'racket/list' can refer to something other than the usual thing because of what package it is inside. Packages also allow module privacy in a way we don't provide now, because some modules may not be provided from the package, even though they are inside it. So... do you think those two understandings overlap? Or do you understand them differently? Jay On Wed, Jul 27, 2011 at 7:52 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Bullet point 2 seems like it may overlap (in a practical, what do I use today sort of a way) with Matthew's modulelet construct. Both group modules together, both provide independently loadable things. Do we really want/need both of these? Robby On Tue, Jul 26, 2011 at 5:49 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Eli and I had a very useful conversation last night and we realized that a lot of the ideal package system we are imagining is within our reach very quickly. Today I made a demonstration of our ideas: https://github.com/jeapostrophe/exp/tree/master/pkgs There's a README there. Once you read it, Run use/program.rkt Then edit use/pkg-in.rkt and change the safe to unsafe You'll see that it changes the meaning of racket/listy module reference in use/program.rkt I haven't implemented the module algebra, but it should be clear from looking at the macro implementations that the existing identifier algebra in require/provide will work transparently. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A basic package system
10 minutes ago, Robby Findler wrote: They have more similarities than your message suggests I believe. And it is probably worth exploring that. As far as I can see a facet/modulet has less stuff than a package and possibly a different story vis a vis files in the filesystem. They're really unrelated -- the new thing with facets/modulets/whatever name they get is a kind of a separately loadable sub-module. What we were talking about is basically making the `foo' in (require foo) be an identifier that you could define to actually point to some random file. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Using clang to Build Racket on Mac OS X
Hello Racket Developers, I thought I would write a quick note about building Racket on Mac OS X 10.6.8 with the new clang compiler (the new front-end to the LLVM compiler backend that is becoming the standard compiler on Mac OS X for XCode 4 and later). Overall, it's been a good experience. As promised, clang seems to compile the C sources in the racket distribution much more quickly than gcc, and has better-formatted error and warning messages. I believe that the resulting native code libraries make racket run faster, but haven't run any detailed tests (there was quite a gap between my last gcc-based build and my first clang-based one, so the improvements may also be due to Racket development). The only wart in the process is the following: when compiling with clang or llvm-gcc with the -O4 option, which enables link-time optimization in the LLVM backend, the GC is unable to correctly determine the stack growth direction. Unfortunately, the configure script doesn't realize that it cannot determine the direction---apparently the test gets it wrong, but appears successful---so supplying the direction manually via the configure argument doesn't work. The build fails when first trying to run raco setup when the GC notes that the stack growth is inconsistent with its assumptions. I'm writing this email partly to see if anyone else has seen the error and knows what to do about it, and partly because I thought you might like to know how racket fairs on the newer OS X compiler. If someone wants to test modifications to the configure script's stack growth test, I would be happy to take patches and test-compile them on my system. For now, I am having great luck building with clang -O3; eventually, it would be nice to have the LTO, since that's one of the most exciting benefits of using the LLVM toolchain. Thanks again for the Racket system! Will PGP.sig Description: This is a digitally signed message part _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Using clang to Build Racket on Mac OS X
50 minutes ago, Will M. Farr wrote: I believe that the resulting native code libraries make racket run faster, but haven't run any detailed tests (there was quite a gap between my last gcc-based build and my first clang-based one, so the improvements may also be due to Racket development). To see a difference you should make sure that you're timing some code that runs at the C level -- since racket code gets jitted the same anyway. (Maybe compilation could be faster since there's a lot of syntax work and that's mostly at the C side.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.2
On Sunday, Stephen Bloch wrote: On Jul 19, 2011, at 5:16 PM, Ryan Culpepper wrote: * Stephen Bloch sbl...@adelphi.edu - Picturing Programs Tests Looks good. I've just pushed three commits: ab01d563ca6a0313e1cb5c07372a2bd2929ae4bc should definitely go into the release (it corrects some error messages to match what they are now) 9a24e66df0e2f7c3a516ce3d3542aab099afaaa3 should probably go into the release (it fixes a bug in one of my test cases, so it passes now) 764f356fdcda14bf5a0af91474bd8ad0640564b5 could go into the release (it adds some test cases, which pass in both the release candidate and the latest git update) I picked the first two, but not the third. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.2
On Tue, Jul 19, 2011 at 5:16 PM, Ryan Culpepper r...@cs.utah.edu wrote: * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) Done. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call
11 hours ago, Michael Sperber wrote: I still need Stephen Chang's commit to be merged over: commit 8956364387fa25ffeb51e50fc1a83c20fd88af32 Author: Stephen Chang stchang...@gmail.com Date: Sun Jul 24 12:18:09 2011 -0400 change recon-val in stepper to use render-to-sexpr for non-lazy lists There was a conflict with that change -- I've finally resolved it and started a new build. Four hours ago, John Clements wrote: This installer page still shows Saturday 23rd as the most recent build. I believe I'm blocked on this. Should take about three hours for the build to finish. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Wed, Jul 27, 2011 at 12:21 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: On 2011-07-26 1:20 PM, Jay McCarthy wrote: I don't have a lot of expertise on the ORM side, but I think Snooze would probably be awesome and my MongoDB-backed structs may be helpful too. Is there a way of generically traversing all structure in a completely privileged way in Racket, without programming at the VM level? For example, one might wish to serialize some arbitrary data structure or write an object inspector or interactive debugger. If you have a sufficiently powerful inspector, you can traverse any structure. In principle, you can even traverse closures this way, but no inspector with the needed power exists. See `struct-vector'. I'm guessing no is the answer, based on the existence of separate serializable and non-serializable structure definitions. I guess that if I were to try it out I'd be defeated by opaque closures and by the inspector mechanism. Does that sound right? Regards, Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote: If you have a sufficiently powerful inspector, you can traverse any structure. In principle, you can even traverse closures this way, but no inspector with the needed power exists. See `struct-vector'. That sounds fantastic! Especially the traversal of closures. What kinds of dark alchemy would I have to engage in to get hold of the necessary inspector? Would such an inspector be able to represent the structure of chaperoned and impersonated values accurately? Finally, what about the other direction? I notice there's no obvious `vector-struct`. Is there a general way of moving from the description of a structure to the structure itself? Regards, Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A basic package system
On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Robby Findler wrote: They have more similarities than your message suggests I believe. And it is probably worth exploring that. As far as I can see a facet/modulet has less stuff than a package and possibly a different story vis a vis files in the filesystem. They're really unrelated -- the new thing with facets/modulets/whatever name they get is a kind of a separately loadable sub-module. What we were talking about is basically making the `foo' in (require foo) be an identifier that you could define to actually point to some random file. Would a binding for foo affect uses like foo/bar? And would this mean going to a semantics for require specs where unbound identifiers have one meaning, and bound identifiers have another? That leads to issues with silent failures, where you try to refer to a binding but a typo leads to the wrong require instead of a syntax error. Also, right now I can do (define racket Racket) and then (require racket) and it works fine. If require starts looking at bindings, suddenly the collection namespace becomes part of the normal Racket namespace. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call
On Wed, Jul 27, 2011 at 1:29 AM, Ryan Culpepper r...@cs.utah.edu wrote: * Carl Eastlund c...@ccs.neu.edu - Dracula Tests (confirm that Dracula runs from PLaneT) Done, in case my [late] response on the prior thread was missed. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote: No such alchemy exists, it's just intended as part of the conceptual framework. Would it be fair to say that were such a thing to come into existence, the VM would need to be changed as part of that work? No, `struct-vector' uses the chaperoned accessors, but doesn't represent their structure. OK. And there's nothing else that can expose that structure? No. OK. Thanks, Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Wed, Jul 27, 2011 at 4:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Jul 27, 2011 at 1:10 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: On 2011-07-27 4:01 PM, Sam Tobin-Hochstadt wrote: If you have a sufficiently powerful inspector, you can traverse any structure. In principle, you can even traverse closures this way, but no inspector with the needed power exists. See `struct-vector'. That sounds fantastic! Especially the traversal of closures. What kinds of dark alchemy would I have to engage in to get hold of the necessary inspector? No such alchemy exists, it's just intended as part of the conceptual framework. Would such an inspector be able to represent the structure of chaperoned and impersonated values accurately? No, `struct-vector' uses the chaperoned accessors, but doesn't represent their structure. Finally, what about the other direction? I notice there's no obvious `vector-struct`. Is there a general way of moving from the description of a structure to the structure itself? No. There is struct-type-make-constructor; if you have the inspector for the structure, you can get at its structure type as well. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Wed, Jul 27, 2011 at 1:20 PM, Tony Garnock-Jones to...@ccs.neu.edu wrote: On 2011-07-27 4:17 PM, Sam Tobin-Hochstadt wrote: No such alchemy exists, it's just intended as part of the conceptual framework. Would it be fair to say that were such a thing to come into existence, the VM would need to be changed as part of that work? Yes. No, `struct-vector' uses the chaperoned accessors, but doesn't represent their structure. OK. And there's nothing else that can expose that structure? Right. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Recommending nightly builds during releases
An hour and a half ago, Vincent St-Amour wrote: Have you tried the nightly builds? http://pre.racket-lang.org/installers/ Just a quick note: when there's a release going on, it's a perfect opportunity to recommend using that build rather than going for the nightly that has moved on since the release started... -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A basic package system
On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Robby Findler wrote: They have more similarities than your message suggests I believe. And it is probably worth exploring that. As far as I can see a facet/modulet has less stuff than a package and possibly a different story vis a vis files in the filesystem. They're really unrelated -- the new thing with facets/modulets/whatever name they get is a kind of a separately loadable sub-module. What we were talking about is basically making the `foo' in (require foo) be an identifier that you could define to actually point to some random file. Would a binding for foo affect uses like foo/bar? And would this mean going to a semantics for require specs where unbound identifiers have one meaning, and bound identifiers have another? That leads to issues with silent failures, where you try to refer to a binding but a typo leads to the wrong require instead of a syntax error. Also, right now I can do (define racket Racket) and then (require racket) and it works fine. If require starts looking at bindings, suddenly the collection namespace becomes part of the normal Racket namespace. I just want id-require-transformers. Right now we have require-transformers but there's no reason we couldn't/shouldn't have id macros too. (define racket Racket) is not problem because it's a phase-0, non-require-transformer binding. Using these macros this way is just a nice way to implement the package system. It's not really a new feature (as my example shows... we already have it.) Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A basic package system
On Thu, Jul 28, 2011 at 12:35 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund c...@ccs.neu.edu wrote: On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Robby Findler wrote: They have more similarities than your message suggests I believe. And it is probably worth exploring that. As far as I can see a facet/modulet has less stuff than a package and possibly a different story vis a vis files in the filesystem. They're really unrelated -- the new thing with facets/modulets/whatever name they get is a kind of a separately loadable sub-module. What we were talking about is basically making the `foo' in (require foo) be an identifier that you could define to actually point to some random file. Would a binding for foo affect uses like foo/bar? And would this mean going to a semantics for require specs where unbound identifiers have one meaning, and bound identifiers have another? That leads to issues with silent failures, where you try to refer to a binding but a typo leads to the wrong require instead of a syntax error. Also, right now I can do (define racket Racket) and then (require racket) and it works fine. If require starts looking at bindings, suddenly the collection namespace becomes part of the normal Racket namespace. I just want id-require-transformers. Right now we have require-transformers but there's no reason we couldn't/shouldn't have id macros too. I would say that the silent failure mode is a reason not to. The only other place I can think of where we allow both bound and unbound identifiers, and interpret them differently, is syntax templates. I don't think of a require spec as a template -- mostly data with a few, special, overriding references -- I generally expect each name to have a single unambiguous meaning. (define racket Racket) is not problem because it's a phase-0, non-require-transformer binding. Require transformers are at phase 0, too. Or are you suggesting that we interpret bound names if they are require transformers, but not if they're something else? Once again, only templates behave that way. It would be very odd to me to treat require specs as mostly data, with a few special, overriding bindings, rather than as a type of expression where each name has a single meaning. Using these macros this way is just a nice way to implement the package system. It's not really a new feature (as my example shows... we already have it.) We already have require macros for application positions because all application positions in require specs are interpreted as bindings. All identifier-only positions are interpreted as data and used as collection names. In general, Racket macros avoid mixing data and expressions (anything that interprets bindings), because it leads to very confusing behavior. This is similar to why cond has a binding for else rather than using its symbolic name, and even more directly similar to why match does not have id transformers either. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
