[chuck-users] Killing thread from without

Hans Aberg haberg at math.su.se
Wed Apr 22 12:18:45 EDT 2009

On 22 Apr 2009, at 17:31, Kassen wrote:

>> It would be nice if one could generate a console display like when  
>> one is
>> using programs like 'top -uR' or 'less'. That will work on  
>> computers that
>> have terminal emulators like 'xterm' (and Terminal on Mac OS X).
>> With it, one could display information about the output. For a  
>> playing
>> keyboard, one might display information about the tuning, key  
>> shift, etc.
> I agree, that would be nice but I don't need it especially badly.

Les Hall, thread "Keyboard Stuff", seemed trying to do something  

> I
> think there is probably more interest in extending the graphical
> elements of the MiniAudicle.

That would require more work. I'm not sure how the console display is  
done - perhaps it suffices with access to control characters.

>> For high level GUI, Scala now uses Gtk2 (Gtk+). It is available on  
>> Linux and
>> Windows, I think. On Mac OS X, the situation is a bit messy. There  
>> is a
>> package that has bindings directly to Aqua:
>>  http://www.gtk-osx.org/
>> but works only in Intel. Otherwise, it is simplest to use MacPorts,  
>> but one
>> gets absolute paths to /opt/, which is not good for a standalone
>> distribution. Installing it alone requires a lot of package chasing.
> Yes, but ChucK itself (unlike the miniAudicle and the Audicle) doesn't
> need any graphics manager. You can run ChucK from your CLI without
> starting your graphical manager (I'm not sure OSX will allow that, on
> Linux you can hit Ctrl + Alt + Fn where n is 1-6, in Windows you can
> pick this at startup). I sometimes do that, if ChucK would use Gtk
> we'd lose that ability.

I have only run 'chuck' from the console. If there is a GUI, one does  
not need to start it - just have a command line option.

>> Well, it may be intended, but "verbose" is not explained in the  
>> manual (just
>> one occurrence).
> It's documented in the online docs;
> http://chuck.cs.princeton.edu/doc/program/vm.html

I tend to prefer a local PDF, as it is easy to search.

> If you'd argue that that implies that "verbose0" should stop printouts
> of started shreds I'd probably have to agree with you. I don't think
> anyone anticipated that somebody would want to stop this kind of
> printout but they could become a serious issue when we'd use shreds
> for grains and would start sporking a few hundred per second.

Yes, threads can be produced in large numbers: that is the point of  

Is there a way to schedule a thread ahead? Like in this pseudocode:
   // CReate a function for later use as thread:
   foo(int x, int y) {...}
   // set a thread foo(3,5) to start at time 1100::ms + now:
   schedule(foo(3,5), 1100::ms + now).id() => int id0;
   // If is pressed key: prevent the thread from sporking:
   if (id != 0)


More information about the chuck-users mailing list