> 24. 2. 2015 v 16:36, Juraj Kubelka <[email protected]>: >> >> Hi! >> >> I have a problem in the recent Pharo 4 image: the method >> MonitorDelay>>#signalLock:afterMSecs:inMonitor:queue: returns a boolean >> instead of MonitorDelay object. >> And in the method Monitor>>#exitAndWaitInQueue:maxMilliseconds: it raises >> message not understood on #unschedule. >> >> Pharo #40505. >> >> -=-=- >> | monitor | >> monitor := Monitor new. >> monitor critical: [ monitor waitWhile: [ true ] maxMilliseconds: 200 ]. >> -=-=- >> >> Is it known error? Someone is changing Monitor or related code? >> Thanks, >> Juraj >> >> 2015-02-24 20:45 GMT+01:00 Juraj Kubelka <[email protected]>: >> >>> Well, basically it is enough to add #yourself in to the class method: >>> >>> signalLock: aSemaphore afterMSecs: anInteger inMonitor: aMonitor queue: >>> anOrderedCollection >>> anInteger < 0 ifTrue: [self error: 'delay times cannot be negative']. >>> ^ (self new setDelay: anInteger forSemaphore: aSemaphore monitor: >>> aMonitor queue: anOrderedCollection) schedule; *yourself* >>> >>> But I am wondering if it is the only one affected method. >>> If someone agree with this solution, I can create test case and slice. >>> >>> Cheers, >>> Juraj >>> >> > On Wed, Feb 25, 2015 at 4:45 AM, Nicolai Hess <[email protected]> wrote:
> > > > > Yes, this has changed (see multiple issues on fogbugz). > Ben Coman uses the return value in WorldState>>#interCyclePause: > for tesing if the delay has been scheduled. > > I think there is a good chance that Monitor is the only class that expects > the > Delay as the return value. > So, yes, please create a fix with your proposed solution. > - or wait for Ben to comment on this :) > > nicolai > Juraj, Your solution looks fine. Please go ahead to create a Fogbugz issue and submit a slice. It would be cool if your test covers the usage of that method and not "just" that it returns a particular class, since there seems no existing test for that method. I haven't had a lot to do with Monitors so it would be good to see a use case. If you notify me when you <Resolve> the issue I'll be happy to review. btw, can you cover both methods? Actually, looking through senders of #schedule, Delay class>>timeoutSemaphore:afterMSecs: suffers the same. Juraj could you cover this also? cheers -ben
