[chuck-users] Killing thread from without

[Hans Aberg]

On 22 Apr 2009, at 00:01, Kassen wrote:

>> I also checked (I think) that it wasn't due to CPU overloads. They  
>> seem to
>> be due to delays in the program.
>
> Yes, that's right. Printing to the screen is a relatively slow
> process, the same holds true for CSound and SC; it's a universal
> problem even for modern computers.

ChucK needs to pipe these to some other process. Scala gets around  
this somehow - it uses Gtk.

> It would help to increase your
> buffer size but of course that would go at the expense of latency.

I'm not sure what buffers there are - I am on Mac OS X, which is Unix.

>> Thank you. I was starting to think along those lines. But the  
>> default should
>> be that all such printouts are turned off, and turned on in a debug  
>> mode.
>
> I can see where you are coming from but personally I think the
> defaults do make sense, though maybe the info when sporking from
> within code isn't as needed as the feedback at adding files or using
> Machine.add(). I'm not sure the VM itself makes that distinction,
> maybe sporked shreds are the same as other shreds there with the one
> difference being namespace, that would make a lot of sense,
> considering the provisions for future extension in the direction of
> smaller granularity in updating running code for livecoding purposes.

It is more how I expect compilers to work. Both optimizations and  
extra warnings should one turn on by hand.

> Still; when you care about performance and want to configure ChucK to
> your needs (that can of course differ from project to project) you are
> likely starting ChucK with a set of flags and parameters already
> (buffer size number of channels, etc, etc). A simple batch file or
> BASH script would take care of it for you.

Anyway, it turns out that --verbose0 does not turn it off. So in view  
it chokes on printouts, it is a bug.

   Hans