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...