It's an issue of when the object referenced by 'a' can be garbage
collected.
Rich is able to do some magic in the bytecode whereby the 'a'
reference is set to null prior to the effective call to fn2 (and still
pass the object), thus the object can be garbage collected whenever
fn2 is done with it
I do not understand the question.
On Jun 22, 5:46 am, ann wrote:
> (defn fn1 [a] (fn2 a) )
>
> When is a cleared, before call to fn2 or after?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.
Before.
On Jun 22, 3:46 am, ann wrote:
> (defn fn1 [a] (fn2 a) )
>
> When is a cleared, before call to fn2 or after?
--
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
Note that posts from n
(defn fn1 [a] (fn2 a) )
When is a cleared, before call to fn2 or after?
--
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
Note that posts from new members are moderated - please be patient w
On Sat, Dec 12, 2009 at 10:57 AM, Daniel Werner
wrote:
> On Dec 10, 3:10 pm, Rich Hickey wrote:
>> I'm happy to announce I have implemented this fine-grained locals
>> clearing in the compiler, in the 'new' branch.
>
> Is there a chance for this featur
On Dec 10, 3:10 pm, Rich Hickey wrote:
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch.
Is there a chance for this feature to find its way into master before
Clojure 1.1 is released?
--
You received thi
> Also, it may be very useful to try all your code on 'new' *without*
> taking
> advantage of the new features, and reporting back on any
> breakage.
That's more what I was thinking. While I find the new features
interesting, I'm less jazzed about spending the time to build on
features that
h Hickey wrote:
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch. It should automatically
> cover all cases in which the code doesn't explicitly reuse the head -
> including non-tail usage, destructurin
On Thu, Dec 10, 2009 at 2:26 PM, Richard Newman wrote:
>> +1 As cool as the new branch is, this is the first compelling reason
>> I've seen to go to my boss and say we need to switch to it now.
>>
>> Thanks Rich!
>
> Speaking of which... I know the new branch is where Rich publishes his
> current
> +1 As cool as the new branch is, this is the first compelling reason
> I've seen to go to my boss and say we need to switch to it now.
>
> Thanks Rich!
Speaking of which... I know the new branch is where Rich publishes his
current work. Does anyone (Rich included!) have any opinion on whether
+1 As cool as the new branch is, this is the first compelling reason
I've seen to go to my boss and say we need to switch to it now.
Thanks Rich!
On Dec 10, 6:40 am, "Stephen C. Gilardi" wrote:
> On Dec 10, 2009, at 9:10 AM, Rich Hickey wrote:
>
> What a great change! We ran into the problem
On Dec 10, 2009, at 9:10 AM, Rich Hickey wrote:
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch. It should automatically
> cover all cases in which the code doesn't explicitly reuse the head
branches of the execution path and to emit code that
> clears them at the point of last use in any particular branch.
>
> I'm happy to announce I have implemented this fine-grained locals
> clearing in the compiler, in the 'new' branch. It should automatically
> cover
that this is strictly a lifetime management issue and does not
change the nature of lazy sequences - they are real, linked data
structures, the tail of which might not yet have been created. They
are most emphatically *not* ephemeral streams of values. However, with
fine-grained locals clearing,
14 matches
Mail list logo
