[racket-dev] Release for v5.3.4 has begun

2013-04-08 Thread Ryan Culpepper
The release process for v5.3.4 has begun: the `release' branch was created for any work that is left and is now bumped to v5.3.3.900. You can go on using the `master' branch as usual, it is now bumped to v5.3.4.1 (to avoid having two different trees with the same version). If you have any

[racket-dev] Packages

2013-04-08 Thread Eli Barzilay
This is a (long) criticism of the current state of the package system. (It is a by-product of PR13669, where I raised that point.) Executive summary: I very strongly think that pkg create should change. See the bottom for my suggestion. * Most code development happens in a single collection

Re: [racket-dev] Packages

2013-04-08 Thread Matthew Flatt
I stand by my recommendation from December: http://lists.racket-lang.org/dev/archive/2012-December/011218.html That is, I think this suggestion should be phrased as a patch. As implied in my quote below, I tried something much like you're describing, and I was unhappy with the resulting

Re: [racket-dev] Packages

2013-04-08 Thread Eli Barzilay
A few minutes ago, Matthew Flatt wrote: I stand by my recommendation from December: http://lists.racket-lang.org/dev/archive/2012-December/011218.html That is, I think this suggestion should be phrased as a patch. As implied in my quote below, I tried something much like you're

[racket-dev] ARM support in the JIT

2013-04-08 Thread Matthew Flatt
I've pushed changes to the JIT to add an ARM back-end, which is based on Paulo César Pereira de Andrade's very nice implementation of GNU lightning for ARM. The generated code uses Thumb and VFP instructions when available, and floating-point arithmetic is unboxed as on x86. Places should work,

Re: [racket-dev] Packages

2013-04-08 Thread Matthias Felleisen
Matthew wouldn't ask for a patch if he wanted you to go thru the work and would reject the patch out of hand. If, however, the patch is delete design completely, use this one instead, he and the rest of dev may reject it too. In between all shades of grey. -- Matthias On Apr 8, 2013, at

Re: [racket-dev] ARM support in the JIT

2013-04-08 Thread Brian Mastenbrook
On 04/08/2013 03:58 PM, Matthew Flatt wrote: I've pushed changes to the JIT to add an ARM back-end, which is based on Paulo César Pereira de Andrade's very nice implementation of GNU lightning for ARM. The generated code uses Thumb and VFP instructions when available, and floating-point

Re: [racket-dev] ARM support in the JIT

2013-04-08 Thread Matthew Flatt
At Mon, 08 Apr 2013 16:15:03 -0500, Brian Mastenbrook wrote: On 04/08/2013 03:58 PM, Matthew Flatt wrote: I've pushed changes to the JIT to add an ARM back-end, which is based on Paulo César Pereira de Andrade's very nice implementation of GNU lightning for ARM. On what processors is

Re: [racket-dev] Packages

2013-04-08 Thread Jay McCarthy
On Mon, Apr 8, 2013 at 2:18 PM, Eli Barzilay e...@barzilay.org wrote: This is a (long) criticism of the current state of the package system. (It is a by-product of PR13669, where I raised that point.) Executive summary: I very strongly think that pkg create should change. See the bottom for

Re: [racket-dev] Packages

2013-04-08 Thread Eli Barzilay
50 minutes ago, Jay McCarthy wrote: On Mon, Apr 8, 2013 at 2:18 PM, Eli Barzilay e...@barzilay.org wrote: It all starts at how someone is expected to approach developing a package, regardless of how this is defined in the current system. A quick way to get to the core of the problem is to

Re: [racket-dev] Packages

2013-04-08 Thread Neil Toronto
I probably shouldn't jump into this because I've barely used the new package system, but here I go... On 04/08/2013 03:17 PM, Eli Barzilay wrote: 50 minutes ago, Jay McCarthy wrote: I don't see how you can start from this place and say, I am making the elis-awesome-stuff package, so therefore