[chuck-users] shreds, namespace, functions, classes, etc

[Kassen]

On 19/11/2007, Ge Wang <ge at ccrma.stanford.edu> wrote:
>
> Hi!


Hi Ge!


This is bug, where the internal ID is uninitialized for user instantiated
> Shred instances.  This has been fixed in CVS (unsporked shreds id default
> to 0).


Very good! I now see why normal shreds don't start counting at 0 like
everything else, good solution.



  However, it brings up the bigger question of what this user
> created Shred might be used for, since currently, there is no facility to
> spork from these Shred objects (at the moment, Shred instances are
> internally created and can be accessed afterwards).  For now, perhaps it
> makes sense to disable Shred instantiation from code?  Thoughts?


Yes, I admit I have no real use for them right now but if

spork ~ my_function() @=> Shred foo;

is useful (and I think it is, giving shreds names might lead to more
readable code if we are dealing with a situation where we need to remove
shreds from the VM) then I'd say creating a array of empty Shred objects
would be useful too. We could assign shreds to them as they get sporked and
deal with larger numbers of shreds with less efford. I could imagine this
getting useful if we have shreds that represent something like synth voices,
we know how many the CPU can take and we want some sort of voice management
or something. How useful this is depends more or less on the member
functions the Shred object has. .exit() and .id() were easy to assume but
are there more? The documentation is rather vague about that class, aside
from noting it exists.

class Super_shred extends Shred { //blahblah}

....on the other hand gives us a object that can't be used for anything
right now so I would be fine with disabling that until somebody has a good
idea on how to use a thing like that.


Not the most fruitful of experiments, this, so far, but I do quite like the
idea of making the variables that the function had accessible as members of
the object that it becomes once sporked. How hard would that be to
implement? It's not worth a lot of work as we can get equivalent
functionality by using a class and sporking from there but as a concept it
makes sense to me, particularly with regard to inter-shred communication at
low syntax-overhead. I'd say that's a topic that does deserve our attention
in the coming time but perhaps there are better ideas.


Also, that whole "scope" thing to the --shell, is that a plan that has since
been discarded and and should I stop lusting after it? That sort of
functionality is the one thing I envy our friends in the SuperCollider world
over. I've been talking about that rather a lot and if there was some sort
of outline like say "we won't do it for now" or -say- "after garbage
collection" I could relax about it on the list/ WiKi, I'm sure people are
quite bored with me going "I want that, preferably graphically in the Mini"
all the time by now :¬).


Thanks for your help, hope you are well,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071119/9292927f/attachment.htm