Re: [chuck-users] Killing thread from without
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
participants (1)
-
Hans Aberg