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

[chris turner]

Ge,

Thanks for the kind words and sorry for the delay in the reply.

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)

However, this is nearing completion, so I'll probably be able to devote 
more
effort to patching support for similar client/server messages.

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

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

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.

I'll probably just do some tests with this to see..

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?

(assuming the latter)

Thanks again for the great software. I look forward to working on this 
project in
the future.

- Chris


On Nov 24, 2004, at 4:28 AM, Ge Wang wrote:
>
>> I had to tweak the shred queuing a little bit so that the shred id 
>> was returned
>> up the call graph, tweak the client such that it would actually print 
>> the
>> corresponding message, and hold on to the initial message type for 
>> the print.
>>
>> I'll be happy to integrate it in a cleaner way with the cvs chuck if 
>> desired /
>> add support for other status messages. Ideally, I'd like all the 
>> messages to match
>> on the client and server, but I didn't want to go mucking around with 
>> the protocol
>> without seeing how well it would be recieved / fit in with other 
>> plans.
>
> We need to somewhat design this part of the protocol...
>
>> As a side note, I wasn't sure what 'immediate' mode was for shred 
>> submission, so I made all the shreds immediate as a test (because 
>> immediate shreds get an id at that point, which made it -much- easier 
>> to know the shred id : ) )
>
> This could be problematic.  Immediate mode was for skipping the 
> message queue and calling the VM
> on the current thread.  This is how machine.add() and friends work.  
> However, it could crash using it
> from the server thread because the VM is on another thread and is not 
> reentrant.  Sorry for the lack
> of documentation on this...