[chuck-users] retrieving shred id when calling chuck from command line

Szabolcs Horvát szhorvat at gmail.com
Fri Mar 15 13:14:12 EDT 2013

Thanks for the reply Kassen!

I looked at miniAudicle just a little bit, and it seems that it takes a
smarter approach than just parsing the output for chuck (but I'm not
entirely sure, I didn't dig deep).

While the chuck output is somewhat machine readable, trying to parse that
still seems unreliable.  Because of its concurrent nature chuck could print
just about anything at just about any time which makes the parsing solution
very messy.

So if anyone can give me pointers on how to retrieve the shred ID better,
without having to parse the textual output, I'd appreciate it very much!


On 11 March 2013 11:03, Kassen <signal.automatique at gmail.com> wrote:

> On Sun, Mar 10, 2013 at 07:06:32PM -0400, Szabolcs Horvát wrote:
> > Hello,
> >
> > I am a chuck novice, so please be gentle :-)  (actually just started
> > learning today)
> Welcome on board!
> >
> > I would like to call chuck from another program and add/remove shreds,
> > as well as control some parameters.  Adding shreds is easy, just chuck
> > + shed.ck, but to remove them I need the shred id.  So the first
> > question is, how can I retrieve the shred id when adding new shreds?
> >
> Yes, this is a issue, it also affects automation using editors like
> Emacs and Vim. I think it is needlessly complicated by the sending
> process not returning the shred ID at successful addition and that
> info instead ending up only in the VM window.
> I just checked to be sure and even --status ends up in the vm window
> only.
> Maybe it is not a bug as such but I think it is at least a usability
> issue. The formatting of errors appears to have been made
> machine-readable on purpose (it'd be enough to have our editor cursor
> jump to the relevant line and character) but it doesn't get returned
> to the calling program.
> > I know that the listener process prints the shred id, but to parse the
> > output of the listener, weed out errors, and catch the shred id only
> > is very messy.  Is there a better way?  How does miniAudicle do this
> > (since it has to do practically the same thing)?
> >
> Maybe the mini somehow "cheats", I never looked into the internal
> design of it. Spencer will know.
> >
> > The other question is about how to control all shreds with global
> > parameters.  I found a way, but since I'm new to ChucK, I'm looking
> > for some reassurance that this is the correct and the simplest way.
> >
> > I created a class like this:
> >
> > public class MyState {
> >     static int freq;
> > }
> >
> > 500 => MyState.freq;
> >
> > Then I read/set the parameter MyState.freq from various shreds.
> >
> > Is this the correct way?
> Yes, that is the way to get around namespace for mutable data.
> Hope that helps a bit, and "welcome!" again!
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20130315/a7832d42/attachment.htm>

More information about the chuck-users mailing list