Re: [racket-dev] Pre-Release Checklist for v5.1.2, Second Call
On Jul 27, 2011, at 1:29 AM, Ryan Culpepper wrote: > > * John Clements > - Stepper Tests Done. > Updates: > - Stepper Updates: update HISTORY > (updates should show v5.1.2 as the most current version; email me > to pick the changes when they're done, or tell me if there are no such > changes.) Done. John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket/draw and whalesong?
On Jul 28, 2011, at 1:32 PM, Danny Yoo wrote: > On Robby and Matthew's suggestion that I look into implementing the > primitives of racket/draw, I took a look at the implementation. If I > understand this correctly, it looks like I need to implement the > methods of the drawing context interface, right? Yes. > (If so, there's one obstacle that I'll need to tackle first, which is > to get Whalesong to compile and execute racket/class. At the moment, > I don't have enough of the primitives coded up to support the class > library.) I guess it's really -- port racket/class -- then racket/draw _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] cannot disable libffi
Ah it was --disable-foreign. --disable-libffi is to use the bundled ffi instead of the host one, or something. On 07/28/2011 11:42 AM, Jon Rafkind wrote: > I am trying to compile racket for a different architecture that libffi > is not ported to so I tried to use --disable-libffi but foreign/libffi > still gets configured. A) should that be happening and B) is there a way > around it? > > $ ../configure --disable-libffi --host=x86 > ... > configure: error: "libffi has not been ported to x86-unknown-none." > configure: error: ../../../foreign/libffi/configure failed for > foreign/libffi > > _ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] cannot disable libffi
I am trying to compile racket for a different architecture that libffi is not ported to so I tried to use --disable-libffi but foreign/libffi still gets configured. A) should that be happening and B) is there a way around it? $ ../configure --disable-libffi --host=x86 ... configure: error: "libffi has not been ported to x86-unknown-none." configure: error: ../../../foreign/libffi/configure failed for foreign/libffi _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] racket/draw and whalesong?
On Robby and Matthew's suggestion that I look into implementing the primitives of racket/draw, I took a look at the implementation. If I understand this correctly, it looks like I need to implement the methods of the drawing context interface, right? (If so, there's one obstacle that I'll need to tackle first, which is to get Whalesong to compile and execute racket/class. At the moment, I don't have enough of the primitives coded up to support the class library.) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Jul 28, 2011 7:26 AM, "Noel Welsh" wrote: > > On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones wrote: > > > 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? > > There is nothing you can't do with a brave heart and a disassembler. > In other words, I've occasionally thought it would be fun to write a > generic object inspector via abuse of the FFI. Certainly. That's how the disassembler I wrote works. It's not a stable solution, but it is effective. sam th _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Tue, Jul 26, 2011 at 6:20 PM, Jay McCarthy wrote: > I was recently telling some people that I thought 'Ruby on Rails' was > mostly an ORM plus a set of default dispatching rules with convenient > ways of extending the defaults. I agree, though I don't have much RoR experience. However, that isn't where the action is in web frameworks these days. My opinion is that it resides in two areas: 1. "rich clients" -- that is, interfaces that use a lot of Javascript. Here FRP within the browser and between the browser and server would be a big win. Interesting to stuff to look at: Opa, WebSharper, (and Javascript frameworks like backbone.js, and the Scala reactive project, etc.) 2. Scalable servers like https://github.com/jdegoes/blueeyes Both could be addressed from Racket. I'm not convinced it really has the computing horsepower to do a bang-up job for #2 (certainly it has the abstractions) but then neither does Node.js and that doesn't stop Node's extremely active supporters. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket on Rockets
On Wed, Jul 27, 2011 at 9:20 PM, Tony Garnock-Jones wrote: > 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? There is nothing you can't do with a brave heart and a disassembler. In other words, I've occasionally thought it would be fun to write a generic object inspector via abuse of the FFI. N. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] New release build
...is ready, including the stepper changes. -- ((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
