Re: lazy-seq realization/retention within futures

2010-08-11 Thread Jules
In general the problem of whether a local can be cleared is undecidable. However a very advanced compiler might be able to find out that the closure of a future will only be called once, and clear the reference to the closure. It is much simpler to just special case futures. One problem that might

Re: lazy-seq realization/retention within futures

2010-08-11 Thread Stuart Halloway
Yes. Concerned about making future work, less concerned about hypothetical examples. :-) The "I know I don't need what I closed over ever again" case can be solved on a per-occurrence basis where it matters. Stu > On Wed, Aug 11, 2010 at 3:06 PM, Stuart Halloway > wrote: >> Chouser, >> >> The

Re: lazy-seq realization/retention within futures

2010-08-11 Thread Chouser
On Wed, Aug 11, 2010 at 3:06 PM, Stuart Halloway wrote: > Chouser, > > There is now a ticket and roadmap for fixing this: See > https://www.assembla.com/spaces/clojure/tickets/423-make-sure-future-clears-closed-overs. Did you see that my examples didn't use future at all? --Chouser http://joyof

Re: lazy-seq realization/retention within futures

2010-08-11 Thread Stuart Halloway
Chouser, There is now a ticket and roadmap for fixing this: See https://www.assembla.com/spaces/clojure/tickets/423-make-sure-future-clears-closed-overs. Stu > On Wed, Aug 11, 2010 at 1:25 AM, timcharper wrote: >> >> I've distilled the issue down to a series of two tests: in one case, >> the

Re: lazy-seq realization/retention within futures

2010-08-11 Thread Meikel Brandmeyer
Hi, Am 11.08.2010 um 07:25 schrieb timcharper: > On Aug 7, 6:42 pm, Ben Mabey wrote: > >> (deftype Foo []) >> ; The entire lazy-seq is held in memory resulting in an OutOfMemoryError. >> (let [foos (take 1000 (repeatedly #(Foo.)))] >> @(future (doseq [foo foos] foo))) It looks like a non

Re: lazy-seq realization/retention within futures

2010-08-11 Thread Chouser
On Wed, Aug 11, 2010 at 1:25 AM, timcharper wrote: > > I've distilled the issue down to a series of two tests: in one case, > the head is properly released, and in the other, the head is retained > even though it seems it shouldn't be. > > http://gist.github.com/510601 Those are nice tests. Plea

Re: lazy-seq realization/retention within futures

2010-08-11 Thread Armando Blancas
Have you considered taking a function that will produce the collection? (map-queue odd? #(range 1 10) :queue-size 5) and in your function of course, (doseq [value (coll)] So that there's no intermediary holding on to the head. Making your function a macro would perhaps clean it up a bit so clien

Re: lazy-seq realization/retention within futures

2010-08-10 Thread timcharper
On Aug 7, 6:42 pm, Ben Mabey wrote: > Hi all, > I've run into an issue with a lazy-seq either being prematurely realized > or having the head unwittingly retained.  Reading chapter 5 in The Joy > of Clojure I realize that I am breaking one of the rules (page 150 in my > MEAP version): avoid bind