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 workarounds.
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 1.2.0.0 (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! Best, Ge!