[chuck-users] Reply to Kassen on shreds, functions and objects

[Kassen]

On 16/11/2007, Jim Hinds <jahbini at jahbini.org> wrote:
>
> Apologies: I broke mailing list rule #1: "dont use subject lines like Re:
> chuck-users Digest, Vol 28, Issue 23"  My bad.
>

Erm, you did? The subject above looks perfectly fine to me, I'm more
concerned about why I just got this now when Gmail tells me it was send 4
hours ago but never mind, we have enough labeling and timing in ChucK
already to get into those topics.



HI.  The function is a function.  It is only a function and things within it
> (the string beep) are totally invisible to anything outside of the function
> definition.  (That's only partly true as they theoretically could be passed
> by reference to something else, just ignore this fact for now.)
>

So far I'm with you, yes.



 'beep' does not belong to the sporked object.  In fact, the name 'tester'
> isn't likely to be known to the sporked object.
>



I'm not sure here. I was/am under the impression that ChucK intentionally
has a compiler and a VM that share the same address space (
http://chuck.cs.princeton.edu/doc/develop/ ) so we could edit it while it
was running. "chuck --shell" should enable us to go into a shred and edit
the code that's running in it.

This is quite a obscure feature, I only found out about it back then because
I was using the "recently edited" feature of the WiKi to look for new and
exciting tid-bits, let me reference this as well because it's not in the
official docs to the best of my knowledge;
http://wiki.cs.princeton.edu/index.php/ChucK/Dev/Shell
http://wiki.cs.princeton.edu/index.php/ChucK/Dev/Shell/Examples

Oh :¬(, I just tried this again, then looked at the source for the shell and
tried some more stuff and now it seems that whole page is more of a design
plan then something we can do now. That would explain nicely why I never got
it to work back then... :¬)

Either way, as we might spork the same function several times every
resulting shred will have to have it's own "beep" as the content of those
may change in more elaborate versions of that function. Frankly I don't see
why this couldn't become a member variable of the Shred.


Chucks object and class capabilities are growing, but as they say on the
> street, they are not all 'that.'  It has to do with inheritance, namespaces,
> run-time magic, and lots of stuff that would kill the real-time capability
> of a shred.   All these are fun problems for a computer science person, but
> not so very fun if you just want to make chuck sing.  I usually just pretend
> that sporked things are not objects at all.
>
> A shred is more like an independent agent: a baby.  All it knows is the
> function that is used to give it birth.  That function must know how to do
> all the communication to and from the outside environment.  That function
> can call other functions (in other classes, possibly), look at global
> variables (in the same source file) and such.
>
> I'm sticking with global variables, at least for the short term.  Programs
> in chuck are usually on the smallish side and a few global variables won't
> hurt the music and are just a necessary evil.  I give those global variables
> useful names like "second_violin_bow_velocity" or some such and to keep
> track of them better.
>

Perhaps I should clarify that I have no real problem here. Of course global
variables are fine and indeed ChucK is powerful enough that all programs end
up being relatively small. I can do the equivalent of everything mentioned,
for one thing the sporked function might belong to a class which would
resolve the whole name space issue as every sporked shred would share the
name-space of that instance of the class.

What I'm after with this investigation is mainly two things. First of all I
like to poke around, see how stuff works, see if it can be abused in funny
ways and generally get a deeper understanding of it all. This bit acts funny
when poked so that's a encouragement to poke some more and ask questions.
Maybe I'm the only one but I find very large negative numbers as shred id's
for non-running shreds quite remarkable.

Secondly, and this is where it gets practical, making ChucK "sing" is fun
and I feel I've got a fairly firm grasp on that but changing the way in
which is sings once it starts (at least in ways not necessarily anticipated
at the time we told it to sing) is quite a bit harder if we don't want it to
start over from scratch. I'm still looking for ways to get more options
there and at first this looked like a hole. Doing such things seems to me
like a field on the border between "theoretical issues of interest to the
computer science department" and "making ChucK sing".

So that's where these questions came from, I haven't gone completely silly,
at least not more so then the required amount to ChucK at all :¬).


Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20071117/76a276e8/attachment.htm