[chuck-users] instrument in function - good idea, or?

[Stefan Blixt]

I'm a bit intrigued by this behaviour, so I felt like testing what actually
happens when a shred exits.
Here's a little test program:

SinOsc @ sinosc;

fun void hello() {
        SinOsc @ localSinOsc;
        new SinOsc @=> localSinOsc;
        localSinOsc @=> sinosc;
        localSinOsc => dac;
        1::second => now;
        <<< "Mark 1b" >>>;
}

spork ~ hello();
<<< "Mark 1">>>;
0.5::second => now;
<<< "Mark 2">>>;
1000 => sinosc.freq;
1::second => now;
<<< "Mark 3">>>;
2000 => sinosc.freq;
1::second => now;
sinosc => dac;
<<< "Mark 4">>>;
while (true) {
        1::day => now;
}

This will run without error. At Mark 1b it goes silent (the SinOsc creating
shred exits). At 3 it writes to that sinosc that has been stored outside the
shred without generating a NullPointerException, and at 4 it turns the
sinosc on again by chucking it to dac.

This means that UGens aren't necessarily destroyed by a shred that exits,
but it will diconnect them from the graph connected to dac.

Here's a tweaked version of the same program:

SinOsc @ sinosc;

fun void hello() {
        SinOsc @ localSinOsc;
        new SinOsc @=> localSinOsc;
        localSinOsc @=> sinosc;
        1::second => now;
        <<< "Mark 1b" >>>;
}

spork ~ hello();
<<< "Mark 1">>>;
0.5::second => now;
<<< "Mark 2">>>;
sinosc => dac;
1::second => now;
<<< "Mark 3">>>;
2000 => sinosc.freq;
1::second => now;
sinosc => dac;
<<< "Mark 4">>>;
while (true) {
        1::day => now;
}

Here the sinosc isn't chucked to dac in the shred that creates it, but it
still disconnects it. So the shred keeps track of what UGens have been
created inside it, and makes an effort to disconnect them when it exits.

I'm not going to argue right or wrong here - clearly there is an idea behind
disconnecting UGens in shreds that exits, and this is as good an
implementation of that as I can see. The alternatives would be to either
make the sinosc variable corrupt (point to a deallocated piece of memory),
or allow a shred to assign null to variables outside its scope, which
doesn't feel like a sensible thing to do.

Sorry for going a bit OT (mail threads can be forked), but I've always found
compiler theory fascinating in a hobbyist kind of way. :)

/Stefan

2009/10/9 Kassen <signal.automatique at gmail.com>

>
> So the moral of the story: if you terminate a shred via exit(), it does NOT
>> get the benefit of a standard shred clean-up.
>>
>>
> I'd like to briefly return to this.
>
> We're all human with the doubts and insecurities that come with that and
> the VM will come across at authoritative even while it's misbehaving.
>
> It can be hard when you're not that experienced with ChucK (yet) to say
> "I'm right and ChucK is wrong", I know I found that hard and would instead
> blame the issue on me not understanding the syntax, then keep it to myself
>
> I suspect a lot of found bugs go unreported because users blame themselves
> instead of blaming the VM. In case of doubt; report. It may be a bug (which
> can go on The List), it might be a issue with the docs (in which case it
> needs documentation) or you may misunderstand something (in which case you
> get to learn).
>
> Just wanted to point that out; the VM is wrong quite often.
>
> Yours,
> Kas.
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091009/31503326/attachment.htm>