24. 2. 2015 v 16:36, Juraj Kubelka <juraj.kubelka@gmail.com>:

...

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 <juraj.kubelka@gmail.com>:

...

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 <nicolaihess@web.de> 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

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 <juraj.kubelka@gmail.com>:

Hi,

it is already done: https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-i... <https://pharo.fogbugz.com/f/cases/14990/MonitorDelay-signalLock-afterMSecs-i...>

I will check this one too: Delay class>>timeoutSemaphore:afterMSecs:

Cheers, Juraj

...

25. 2. 2015 v 12:29, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>>:

...

24. 2. 2015 v 16:36, Juraj Kubelka <juraj.kubelka@gmail.com <mailto:juraj.kubelka@gmail.com>>:

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 <juraj.kubelka@gmail.com <mailto:juraj.kubelka@gmail.com>>: 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 <nicolaihess@web.de <mailto:nicolaihess@web.de>> 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