- Pharo-dev - lists.pharo.org

I would be extremely grateful for a reproducible case for the following Socket issue

by Eliot Miranda

http://forum.world.st/Socket-s-readSemaphore-is-losing-signals-with-Cog-on-… On 8/13/2011 13:42, Levente Uzonyi wrote: > Socket's readSemaphore is losing signals with CogVMs on linux. We > found several cases (RFB, PostgreSQL) when processes are stuck in the > following method: > > Socket >> waitForDataIfClosed: closedBlock > "Wait indefinitely for data to arrive. This method will block until > data is available or the socket is closed." > > [ > (self primSocketReceiveDataAvailable: socketHandle) > ifTrue: [^self]. > self isConnected > ifFalse: [^closedBlock value]. > self readSemaphore wait ] repeat > > When we inspect the contexts, the process is waiting for the > readSemaphore, but evaluating (self primSocketReceiveDataAvailable: > socketHandle) yields true. Signaling the readSemaphore makes the > process running again. As a workaround we replaced #wait with > #waitTimeoutMSecs: and all our problems disappeared. > > The interpreter VM doesn't seem to have this bug, so I guess the bug > was introduced with the changes of aio.c. Â« [hide part of quote] Oh, interesting. We know this problem fairly well and have always worked around by changing the wait in the above to a "waitTimeoutMSecs: 500" which turns it into a soft busy loop. It would be interesting to see if there's a bug in Cog which causes this. FWIW, here is the relevant portion: "Soft 500ms busy loop - to protect against AIO probs; occasionally, VM-level AIO fails to trip the semaphore" self readSemaphore waitTimeoutMSecs: 500. Cheers, - Andreas _,,,^..^,,,_ best, Eliot

March 23, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Pollet

as long as $PWD is respected, I don't think either way really matters On 23 March 2016 at 11:53, Damien Cassou <damien.cassou(a)inria.fr> wrote: > Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > > > On Tue, Mar 22, 2016 at 9:37 AM, Damien Pollet <damien.pollet(a)gmail.com> > > wrote: > > > >> Because there is this concept called "consistency" that's interesting to > >> have :p > >> > >> If your code wants $HOME it can ask for it explicitly, same for /. > However > >> if it just wants to do something in $PWD consistent with most use-cases, > >> the image directory is the sensible default. > >> > >> > > I agree with Pollet. I don't care if it is image directory or $HOME. > What I > > care is that $PWD of the VM process should match with FileSystem >> > > workingDirectory. And right now it does not match. > > I was not clear enough: I agree that consistency is important and VM > must answer the same as image. What that "same" should be is still > unclear to me though. You propose the image folder, but this is > inconsistent with other applications launched by double-click. I propose > to be consistent with other applications: HOME on Linux, / on OS X. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Denis Kudriashov

2016-03-23 14:05 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > [mock someMessage. mock2 someMessage2] were done > [mock someMessage. mock2 someMessage2] were doneInOrder > I really like this idea. Thank's. What about: [mock someMessage. mock2 someMessage2] should beDone [mock someMessage. mock2 someMessage2] should beDoneInOrder ?

March 23, 2016

[Ann] New version of StateSpecs 2.0

by Denis Kudriashov

Hello. I glad to present new version of StateSpecs: - should expressions based on normal message sends instead of pragma magic Pragma based approach allows to write very natural expressions like 1 should be an instance of: Number But it is completely not practical because it is impossible to work with such code as with any other. No easy way to find senders or implementors of expressions. It is difficult to understand how it works. It's hidden magic. So now this approach is extracted to separate package as nice experiment on what can be done with smalltalk. And legal approach now is to use normal keywords like: 1 should beInstanceOf: SmallInteger 1 should beKindOf: Number With this you can easily find implementors and get full list of defined expressions. (look at class SpecOfShouldExpression) - new functionality: - boolean properties validation. You can send any messages to "should be" which will be executed by subject of "should" and then validated for truth: 1 should be between: 10 and: 50 #(1 2) should be isEmpty - properties chain validation. You can send any series of messages to "object where" to write should expression for internal property: (1@3) where x should be: 1 (0@1 corner: 10@20) where origin x should be: 0 - unordered equality for collections and explicit order sentence: #(1 2) should equal: #(2 1) "not fail" (1 2) should beOrderedEqualTo: #(2 1) "fail" Idea that in tests you usually put as less details as possible. And only if you really need specific behaviour you write it requirement explicitly. - better failures descriptions similar to existed assertions: 1 should be: 2 => Got "1" but it should be "2" 1 should beInstanceOf: String => Got "1" but it should be instance of String #(1 2) should be isEmpty => #(1 2) should be isEmpty (1@3) where x should be: 10 => Got "1" from (1@3) x but it should be 10 - improved existing should expressions: - collection item specification is based on expected item spec #(10 20) should include: 10 at: 1 #(10 20) should include: (Kind of: Number) at: 1 - block failure spec is based on expected failure spec: [1/0] should raise: ZeroDivide "not fail" [1/0] should raise: Error "fail because explicit exception class is specified" [1/0] should raise: (Kind of: Error) "not fail" [self error: 'test'] should raise: errorInstance "fail because raised exception is not the same instance as errorInstance" [1/0] should raiseError "not fail when any kind of errors was signalled" - repackaged to separate specs from DSL code - cleaned classes - comments - no dependency from SMock anymore You can load StateSpecs by Gofer it smalltalkhubUser: 'dionisiy' project: 'StateSpecs'; configurationOf: 'StateSpecs'; loadStable. . Loo at details and examples here http://www.smalltalkhub.com/#!/~dionisiy/StateSpecs I hope StateSpecs can become legal alternative for classic assertions. It models requirements and failures as first class objects which make them good target for object specific tools which will be difficult to achieve with assertion methods. Best regards, Denis

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Ben Coman

On Wed, Mar 23, 2016 at 8:39 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-23 12:38 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> Maybe... >> [ mock someMessage. mock2 somMessage2 ] shouldve beenSent >> >> but maybe you don't want different #shouldXXX messages. > > > Thank you too, Ben. And yes it will not follow other should expressions. But > it would not be bad to use completely different word instead of #should Okay, then perhaps... [mock someMessage. mock2 someMessage2] were sent [mock someMessage. mock2 someMessage2] were sentInOrder [mock someMessage. mock2 someMessage2] were done [mock someMessage. mock2 someMessage2] were doneInOrder but then do you also need singular #was for single items? [mock someMessage. mock2 someMessage2] expect done [mock someMessage. mock2 someMessage2] expect doneInOrder Expect squeezes in usage in both future and past tense... "I expect he'll arrive soon" "I expect he went home" cheers -ben

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Denis Kudriashov

2016-03-23 12:38 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Maybe... > [ mock someMessage. mock2 somMessage2 ] shouldve beenSent > > but maybe you don't want different #shouldXXX messages. > Thank you too, Ben. And yes it will not follow other should expressions. But it would not be bad to use completely different word instead of #should

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Ben Coman

On Wed, Mar 23, 2016 at 6:31 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-23 11:02 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >> >> But from English it not sounds like it should be occurred in past. Normally thats my cue ;) but I don't have any great ideas. >> So what correct and not long sentence can be used here? maybe: >> >> mock had received someMessage >> >> >> mock should haveReceived someMessage >> > > Thank's for suggestions. Thats idea from Marcus too. But it feels too long. > But maybe. Now I actually already rename #receive to #haveReceived. But I > hope for better sentence. >> >> >> And same question for verification group of message sends (at the end of >> test): >> >> [mock someMessage. mock2 someMessage2] should occur >> >> [mock someMessage. mock2 someMessage2] should occurInSameOrder >> >> >> [ mock someMessage. mock2 somMessage2 ] should have beenSent > > > It's long too. And I wish reduce number of separated words because it is not > good practically. Maybe... [ mock someMessage. mock2 somMessage2 ] shouldve beenSent but maybe you don't want different #shouldXXX messages. cheers -ben > It raises more questions: how it is implemented, what the > better name for intermediate object (result of have in that case) and > others. > At least your suggestion will be like > [ mock someMessage. mock2 somMessage2 ] should haveBeenSent > > Another idea is to use #happen word: > [ mock someMessage. mock2 somMessage2 ] should happen

March 23, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Cassou

Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > On Tue, Mar 22, 2016 at 9:37 AM, Damien Pollet <damien.pollet(a)gmail.com> > wrote: > >> Because there is this concept called "consistency" that's interesting to >> have :p >> >> If your code wants $HOME it can ask for it explicitly, same for /. However >> if it just wants to do something in $PWD consistent with most use-cases, >> the image directory is the sensible default. >> >> > I agree with Pollet. I don't care if it is image directory or $HOME. What I > care is that $PWD of the VM process should match with FileSystem >> > workingDirectory. And right now it does not match. I was not clear enough: I agree that consistency is important and VM must answer the same as image. What that "same" should be is still unclear to me though. You propose the image folder, but this is inconsistent with other applications launched by double-click. I propose to be consistent with other applications: HOME on Linux, / on OS X. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Denis Kudriashov

2016-03-23 11:02 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > But from English it not sounds like it should be occurred in past. So what > correct and not long sentence can be used here? maybe: > > mock had received someMessage > > > mock should haveReceived someMessage > > Thank's for suggestions. Thats idea from Marcus too. But it feels too long. But maybe. Now I actually already rename #receive to #haveReceived. But I hope for better sentence. > > And same question for verification group of message sends (at the end of > test): > > [mock someMessage. mock2 someMessage2] should occur > > [mock someMessage. mock2 someMessage2] should occurInSameOrder > > > [ mock someMessage. mock2 somMessage2 ] should have beenSent > It's long too. And I wish reduce number of separated words because it is not good practically. It raises more questions: how it is implemented, what the better name for intermediate object (result of have in that case) and others. At least your suggestion will be like [ mock someMessage. mock2 somMessage2 ] should haveBeenSent Another idea is to use #happen word: [ mock someMessage. mock2 somMessage2 ] should happen

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Max Leske

> On 23 Mar 2016, at 10:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > I prepare new version of Mocketry with many new functions. And I have little question about some naming. > > It will be possible to verify (at the end of test) that particular message was happened. My first suggestion was: > > mock should receive someMessage > > But from English it not sounds like it should be occurred in past. So what correct and not long sentence can be used here? maybe: > > mock had received someMessage mock should haveReceived someMessage > > And same question for verification group of message sends (at the end of test): > > [mock someMessage. mock2 someMessage2] should occur > [mock someMessage. mock2 someMessage2] should occurInSameOrder [ mock someMessage. mock2 somMessage2 ] should have beenSent > > Does it sounds correct? What suggestions? > > Best regards, > Denis Cheers, Max

March 23, 2016