[chuck-users] public class connections mystery

[mike clemow]

Kas,

Yeah, I honestly have no idea what should and shouldn't be happening
in GC land.  :)

It occurs to me that I usually implement this type of mechanism using
shreds rather than classes.  One thing that Chuck does is nudge you in
the direction of asking yourself "do I really need to wrap that in a
class/namespace?  or is what I really want a shred I can send an Event
to?"

Just a paradigmatic opinion.

-Mike

http://michaelclemow.com
http://semiotech.org




On Fri, Feb 24, 2012 at 1:22 PM, Kassen <signal.automatique at gmail.com> wrote:
> On Fri, Feb 24, 2012 at 11:17:08AM -0500, mike clemow wrote:
>>
>
> Mike,
>
>
>> *Lack* of garbage collection might be the problem here.  Maybe the
>> connections are collected, but the objects aren't?  The objects
>> actually *should* be collected but hang out due to an incomplete gc
>> implementation.  Could that be the case?
>>
>
> Hmmmmm. At the very least there is a issue along those lines here. In
> a way inter-UGen connections that are removed is a sort of GC, in
> terms of CPU usage, but that's different from GC as keeping memory
> usage reasonable. Currently those are independent, it seems, for UGens
> and in the future they should probably be more closely linked.
>
> Here, at first glance, it seems to me that the UGens in question are
> not garbage as they are in the public namespace. As far as I can see
> they will never be garbage for the rest of the VM's life as long as
> we don't assign NULL to them. I'll have a more in-depth look at what's
> going wrong with this code tomorrow.
>
>> I guess that what we're saying is that the the original Cell object in
>> the function sinOsc should fall out of scope after the method returns.
>>  Should the reference to that object in the static member cells[] hold
>> it in scope as David's code implies?
>
> I don't dare say what this code "should" do right now without a closer
> look, but I strongly feel that yes, we should be able to put anything
> we please in the global namespace by assigning it to such a static
> member of a public class and that that should not lead to
> disconections.
>
>>
>> David, another thing to consider is that this approach may be
>> unhelpful to you for one reason or another; either the Chuck is not
>> complete enough to make it clear that this should not be possible, or
>> Chuck is broken enough to not let this be possible even if it should
>> be.  (This is a relatively common occurrence actually. ;)
>>
>
> True, but most practical things we might like to do can be done,
> though it may take some roundabout ways here and there. That's half
> the fun. Well, often ;-)
>
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users