[chuck-users] ChucK and Processing

[Kassen]

On 9/3/07, Arthur Clemens <arthur at visiblearea.com> wrote:
>
>
> No, this is just because of the way applets are quit in Java. If 'chuck
> --kill' is sent the processed are killed normally, so ChucK behaves
> predictable
>

Ok, so the issue is that ChucK keeps running when Processing is killed? If
that's a real problem you could try to make ChucK poll processing over OSC
every second or so and if it isn't running ChucK could send a system command
to kill ChucK.



> The public class not used in the demo, but I kept the file because that is
> the way I would ideally solve it.
>

That's what I suspected now.

<snip>

> So even if 'fileplayer.ck' is called earlier, it is added last to the VM.
> First the chuckdemo.ck files are run and they do not know any FilePlayer
> class at that time.
> Note that the order varies at each run. Sometimes the FilePlayer class is
> added second or third, sometimes first.
>
> I don't know if this is because of the way Java calls the processes, or if
> class initialization in ChucK happens after file processing.
>

This is very odd, I'm inclined to suspect Processing is sending the commands
in the wrong order. What you could do is start ChucK using this;

chuck --loop fileplayer.ck

That should force it to be added at the right moment.


So I would be fine if I could call for each file: 'chuck -add fileplayer.ck
> chuckdemo.ck:with:a:lot:of:params', but after the first file ChucK is
> bailing out:
> [fileplayer.ck]:line(1): class/type 'FilePlayer' is already defined in
> namespace 'global'
> why can't it just ignore this?
>

Because (right now) you can't re-define existing public classes.

I don't quite understand why it won't add the second file after running the
first has failed, there might be a good reason for that but I don't see it.

I'd sugest you try the sugestion of adding the public class to the VM at the
time you start the VM, that should force the order to be the right way
around, let's see where that gets us.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070903/fa734e1c/attachment.htm