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