On 16/11/2007, Jim Hinds <jahbini@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/Shellhttp://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.