[chuck-users] Returning a Shred and crashing Chuck

[mike clemow]

> I'd also be quite interested in
> Shred type objects giving access to that shred's name-space

I guess even using the public keyword for sporked shreds (if functions
ever become objects  ;-)  for some kind of global access to the
namespace, maybe?

public fun void foo()
{
5 => int value;
while (second => now) <<< value >>>>;
}

spork ~ foo() @=> Shred bar;
4::second => now;

3 => bar.value;
week => now;

Of course, we'd have to distinguish between a "public" and a "fun" first.  ;-)

-Mike

On Fri, Jun 13, 2008 at 11:17 AM, Kassen <signal.automatique at gmail.com> wrote:
>
>
> 2008/6/13 mike clemow <gelfmuse at gmail.com>:
>>
>> Yes, I forgot to mention that!  Crazy...  I guess I'll manually
>> unchuck the SinOsc for now.  I'll have to check if that happens with
>> other UGens...
>
> Unchucking unused Ugens it good form anyway. Wherever you can afford to I'd
> do that because it saves CPU. IT tisn0/t alway appropriate because with some
> Ugens or systems of Ugens the code need not be aware of when the Ugen is
> "done", for example with the physical models in the STK.
>
>>
>> Meanwhile, if I unchuck that SinOsc from the dac it works in the sense
>> that the SinOsc objects don't add up, however, only if the shreds
>> finish executing.  If I remove the parent while one of the sporked
>> shreds is still running, one sine keeps going.  Ostensibly because the
>> last shred hasn't finished and the unchuck line hasn't run.  This
>> makes me really wish I could define code that would be called when a
>> shred exits.  That would be a neat feature...
>
> Yes, quite weird and I can't remember this being like that in the past. This
> is truely arcane stuff and likely only Ge knows.... But I have a suspicion.
> Clearly a outside reference to a shred affects how it deals with cleanup. I
> suspect this has to do with Ge having been working at garbage collection
> (which also works with references... or at least will). I suspect what we
> are seeing might be a trace of the start of a GC framework. In that case we
> found a bug in a feature that's not even here yet... That would be quite
> funny.
>
> Disclaimer; this is complete speculation and not of any practical use.
>
> Code to be run when a shred exits is a interesting idea but I suspect it's
> asking for trouble. Because a shred has it's own namespace which is
> obviously gone when the shred is such code would probably need to be run
> *before* it exits and after it get's it's exit notice.... but then what if
> this code does stuff like advance time or (worse yet!) call for the exit of
> the same shred? I suspect this would be asking for stuck VM's and confused
> shredulers. I'd rather have proper cleanup. I'd also be quite interested in
> Shred type objects giving access to that shred's name-space like this;
>
> fun void foo()
> {
> 3 => int value;
> while (second => now) <<< value >>>>;
> }
>
> spork ~ foo() @=> Shred bar;
>
> 4::second => now;
>
> //modest proposal starts here
> 5 => bar.value;
> hour => now;
>
> This would also enable us to run manual cleanup; either from the last lines
> of the shred's code (asuming it's not a infinite loop) or from the shred
> that calls for it's exit, right before the exit call.
>
> Kas.
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
http://semiotech.org
http://deadlylittlepills.com/michael