[racket-dev] futures waiting for scheme_make_envunbox

2010-08-25 Thread Sam Tobin-Hochstadt
While trying to use futures to parallelize a simple piece of code, I was able to remove all of the waiting except for this: future: 3 waiting for runtime at 1282743524205.783936: [scheme_make_envunbox] which happens continuously. What causes this function to be invoked, and how can I eliminate

Re: [racket-dev] gc vs assignment

2010-08-25 Thread Neil Toronto
Matthias Felleisen wrote: Catching up with some mail. Neil wrote: Avoiding allocation reduces GC collects, which reduces stutters and hitches. My (possibly old) understanding of GC and mutation tell me that this is one of those prejudices that programmers should get rid of. Every mutation

Re: [racket-dev] [plt] Push #20926: master branch updated

2010-08-25 Thread Robby Findler
Oh, sorry! I'll push a change back. As to your question, I'd say not on my account. Robby On Wed, Aug 25, 2010 at 8:46 AM, Casey Klein clkl...@eecs.northwestern.edu wrote: On Wed, Aug 25, 2010 at 8:31 AM, Casey Klein clkl...@eecs.northwestern.edu wrote: On Wed, Aug 25, 2010 at 7:40 AM,  

Re: [racket-dev] require sub-forms

2010-08-25 Thread Shriram Krishnamurthi
Actually, I grepped through the source in the hope that that's precisely what I would find. It's when I didn't that I wrote the list. Shriram On Wed, Aug 25, 2010 at 10:11 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Tue, Aug 24, 2010 at 10:18 PM, Eli Barzilay e...@barzilay.org wrote: On

Re: [racket-dev] futures waiting for scheme_make_envunbox

2010-08-25 Thread Matthew Flatt
While we look into the other problems... What happens if you use `let' instead of the internal defines in `mandelbrot-point'? There's a `set!' implicit in the `letrec' that is implicit in the use of internal definitions. Maybe the Typed Racket optimizations confuse the compiler so that it

Re: [racket-dev] gc vs assignment

2010-08-25 Thread Jay McCarthy
On Tue, Aug 24, 2010 at 3:47 PM, Neil Toronto neil.toro...@gmail.com wrote: Matthias Felleisen wrote: Catching up with some mail. Neil wrote: Avoiding allocation reduces GC collects, which reduces stutters and hitches. My (possibly old) understanding of GC and mutation tell me that this

Re: [racket-dev] futures waiting for scheme_make_envunbox

2010-08-25 Thread Jay McCarthy
On Wed, Aug 25, 2010 at 8:07 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Aug 25, 2010 at 9:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 25 Aug 2010 09:42:40 -0400, Sam Tobin-Hochstadt wrote: While trying to use futures to parallelize a simple piece of code, I was able to

Re: [racket-dev] require sub-forms

2010-08-25 Thread Jay McCarthy
On Wed, Aug 25, 2010 at 8:18 AM, Eli Barzilay e...@barzilay.org wrote: On Aug 25, Jay McCarthy wrote: On Tue, Aug 24, 2010 at 10:18 PM, Eli Barzilay e...@barzilay.org wrote: On Aug 24, Jay McCarthy wrote: There is not now but we could make a module that only exported them so you could

Re: [racket-dev] require sub-forms

2010-08-25 Thread Eli Barzilay
On Aug 25, Jay McCarthy wrote: I agree that it's basically the same when done right, which is why I initially suggested the simpler solution. I think the one benefit of these export sets is that they make it a language abstraction rather than a convention of where to put files. IMO, the

Re: [racket-dev] [plt] Push #20926: master branch updated

2010-08-25 Thread Robby Findler
Also, the email when tests fail come with filenames, which can be useful. Robby On Wed, Aug 25, 2010 at 9:38 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Wed, Aug 25, 2010 at 7:46 AM, Casey Klein clkl...@eecs.northwestern.edu wrote: On Wed, Aug 25, 2010 at 8:31 AM, Casey Klein

Re: [racket-dev] hashes in ASL

2010-08-25 Thread Jay McCarthy
This change will be pushed momentarily. Jay On Sat, Aug 21, 2010 at 7:04 PM, Shriram Krishnamurthi s...@cs.brown.edu wrote: Why does make-hash require one argument, rather than just taking zero like make-hash in Racket does?  ASL is anyway a language with state, so it's perfectly meaningful

Re: [racket-dev] hashes in ASL

2010-08-25 Thread Jay McCarthy
Just pushed an update with optional argument constructors and immutable hash operations. Jay On Tue, Aug 24, 2010 at 11:36 AM, Jay McCarthy jay.mccar...@gmail.com wrote: What documentation are you looking at?

Re: [racket-dev] futures waiting for scheme_make_envunbox

2010-08-25 Thread Matthew Flatt
At Wed, 25 Aug 2010 08:41:04 -0600, Jay McCarthy wrote: Unfortunately, trying to decompile this file produces an error in the decompiler: [sa...@punge:~/tmp plt] raco decompile mandelbrot.rkt hash-ref: no value found for key: 1128 Blake will see if this is a bug fixed in our local

Re: [racket-dev] futures waiting for scheme_make_envunbox

2010-08-25 Thread Matthew Flatt
At Wed, 25 Aug 2010 08:17:32 -0600, Matthew Flatt wrote: There's a `set!' implicit in the `letrec' that is implicit in the use of internal definitions. Maybe the Typed Racket optimizations confuse the compiler so that it doesn't see how to convert the `let' into a `letrec'. One requirement

Re: [racket-dev] gc vs assignment

2010-08-25 Thread Joe Marshall
On Tue, Aug 24, 2010 at 2:47 PM, Neil Toronto neil.toro...@gmail.com wrote: In my defense, I was talking about framerate, not total or average cost of memory management. That is very different situation. Games are really almost real-time apps. I'd say that they *are* real-time apps. You

Re: [racket-dev] hashes in ASL

2010-08-25 Thread Shriram Krishnamurthi
Catching up ... What documentation are you looking at? http://docs.racket-lang.org/htdp-langs/advanced-prim-ops.html#(part._(lib._htdp-advanced..ss._lang)._.Hash_.Tables) If I type hash in the Help Desk, I get hash provided from racket/base, racket but not from ASL, in contrast to, say,

Re: [racket-dev] ~e vs ~.s

2010-08-25 Thread Eli Barzilay
On Aug 25, Eli Barzilay wrote: [...] If I touched your code, it would be a good idea to check that I did the right thing. A git tip, to make this easier: you don't need to look throughout the diff of the whole push -- that has too many changes in many cases (including this). To conveniently