Mark,
I just uploaded all the changes to 2.4b using the 'update from server' command, and saved the image, (I guess that makes it equivalent to 2.4c).
I filed in my publish-subscribe change-set and everything appears to be fine - 'PostOffice start' begins testing in the background, and all the messages appear on the Transcript...
When you got the error, were you working with a clean image? Does the error occur with 2.4b or 2.4c?
One problem I have discovered is 'nested updates'. That is, if one trigger sets off another trigger by one of its subscribers, you will get a call to PostOffice incoming: msg from inside the PostOffice incoming: msg. Since this method uses a mutex critical: the two calls to the method will deadlock each other.
(The simple fix is to remove the protected: block from PostOffice: incoming, which I have done)
I have found this to be a problem with OO and Semaphores in general - there is so much cross-calling of messages it is difficult to predict when a locked message will call itself. It would be good to have a "smart semaphore" that forced outside callers to wait, but let self invoke multiple invocations of a message. I would appreciate it if someone could point out some code to identify if the invoker of the currently executing message is self or not.....
Does this idea of having outside callers wait in line, and have self rudely pushing to the front of the queue make sense?
Any other solutions?
<irrelevant thought>
I just realized that you can use the event system to uphold all the existing dependency relationships. Simply change addDependent: aDependent (in Object) to read: self when: #changed send: #update to: aDependent.
plus its variant methods - you get the idea.....
</irrelevant thought>
Peter
When I try "PostOffice start" I get an error about error: having the wrong number of parameters in WeakRegistry>>protected: It's a hard error to find because (a) the error notifier shows up behind all other windows, since it's running in a background thread (restore the display to see the error notifier) and (b) the debugger for some reason doesn't show the backtrace if you choose to debug.
But maybe this is on purpose? I get a similar kind of error dialog when I send #run to the Transcript (playing with variations on Peter's examples).
Mark
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html