Both issues should be covered by SLICE-Issue-14990-MonitorDelaysignalLockafterMSecsinMonitorqueue-should-return-MonitorDelay-object-JurajKubelka.2
Thank you for the review! Juraj > 25. 2. 2015 v 12:32, Juraj Kubelka <[email protected]>: > > Hi, > > it is already done: > https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-inMonitor-queue-should-return-MonitorDelay-object > > <https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-inMonitor-queue-should-return-MonitorDelay-object> > > > I will check this one too: Delay class>>timeoutSemaphore:afterMSecs: > > Cheers, > Juraj > >> 25. 2. 2015 v 12:29, Ben Coman <[email protected] >> <mailto:[email protected]>>: >> >> >>> 24. 2. 2015 v 16:36, Juraj Kubelka <[email protected] >>> <mailto:[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] >> <mailto:[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] >> <mailto:[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 >
