[chuck-dev] towards matching client / server messages in chuck

Ge Wang gewang at CS.Princeton.EDU
Wed Dec 22 11:21:40 EST 2004

Hi Chris!

> I've been working on completing the 'alpha' prototype of my system
> (so I knew I wouldn't have time to plan on coding chuck patches)

This is python + ChucK jamming system, right?  How many critical
features of ChucK are missing for doing this, besides the proper
network/id protocol?

> I'm thinking the plan might go like this (pending your approval, other 
> plans, etc):
> - creating a central message table or message printing class/function
> - modifying the existing server-side messages to use this table
> - sorting out the request/response protocol to support message return 
> codes
> - implementing client-side printouts based on the protocol + table

This sounds very good - that would clear up much of the existing mess.
We should wait for a little while longer, however, before implementing
- because the major version will be released soon, and there are many
changes to existing code.

> as for the immediate mode / 'bug' :
> It looks like the 'bug' I was talking about was possibly related to 
> the script I was
> using. I'll come up with an example to post / work on debugging my 
> scripts

I see.  But it is still dangerous to call VM in this mode from another 
thread.  I will
make some passes over this and see if there are any safe/quick 

> don't remember the exact method calls, but there was a 
> 'submit-immediate' and 'submit-for-later' call to the chuck vm class.
> I'm wondering if there would be any negative impact on the networking 
> if there was a
> 'submit-eventually' that would block until an ID was properly returned 
> back to the
> caller.. If this could work it might be the approach to take for the 
> problem I was
> addressing (getting a shred ID on any submission.) in kludging around 
> it.

submit-eventually would make sense - the caller wouldn't have to wait 
for too long
before the id is assigned or the thing is rejected anyway.

> Assuming we're able to create a plan to get the changes into 
> chuck-proper, would
> you prefer I work against the stable release or the development copy?

right now there is a manual branch in CVS for (chuck_dev/v2), 
which is going
back into src/ once it's ready - we should start there (and then).

> I look forward to working on this project in the future.

That's great to hear.  Thank you very much!


More information about the chuck-dev mailing list