Has anyone made progress on this bug? The simplest form of the bug was this: (defn splode [n] (doseq [i (filter #(= % 20) (map inc (range n)))]))
This blows the heap, but it shouldn't. I find this deeply troubling, because if this doesn't work, it undermines my faith in the implementation of lazy sequences, which are quite ubiquitous in Clojure. map and filter are written in the most natural way in boot.clj, so if they don't work properly, it means that anything written with lazy-cons is suspect. I have an idea to try, but I'm not set up to build the java sources on my computer, so maybe someone else can run with it: Right now, LazyCons.java takes one function which includes both the knowledge of how to create the first and the rest. Perhaps LazyCons.java needs to be implemented so that the constructor take two separate functions, one that generates the first, and one that generates the rest. This way, as soon as the first is generated, it can be cached, and the first-generating-function can be set to null. Similarly, when the rest is generated, it will be cached, and its generating function can be set to null. So if the problem is being caused by the first-generating-function keeping something alive that needs to be garbage collected, this would solve it, by releasing it as soon as possible. The lazy-cons macro in boot.clj wouldl also need to be changed to call the new LazyCons constructor with two functions, rather than just one. Of course, if the problem is that the rest-generating-function is holding onto something, this will not solve the problem. --Mark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
