March 2016 - Pharo-dev - lists.pharo.org

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

by Eliot Miranda

Hi Dale, On Tue, Mar 22, 2016 at 7:49 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Mariano, > > I think this _is_ the OSX issue that I was talking about ... there is a > way to arrange for PWD to be set correctly when double clicking apps, but > it has to be set a system option so each user has to do it themselves ... > Is that a setting in the Desktop preferences (or...?) or is it a setting on the app itself? > > > Dale > > > On 3/22/16 6:01 AM, Mariano Martinez Peck wrote: > > > > 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. > > > > >> On 22 March 2016 at 13:05, Damien Cassou < <damien.cassou(a)inria.fr> >> damien.cassou(a)inria.fr> wrote: >> >>> Damien Pollet < <damien.pollet(a)gmail.com>damien.pollet(a)gmail.com> >>> writes: >>> >>> > On 22 March 2016 at 12:56, Damien Cassou <damien.cassou(a)inria.fr> >>> wrote: >>> > >>> >> typical applications ran with double-click are bound to the HOME >>> >> directory. Why do you want to do it differently? >>> >> >>> > >>> > Only on Linux. On OS X it's / >>> >>> so, why do you want to make it the image directory? >>> >>> -- >>> 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 >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- _,,,^..^,,,_ best, Eliot

March 24, 2016

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

by Denis Kudriashov

2016-03-23 21:21 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Personally I would rename ShouldExpression to ExecutedBlock or > ExecutedExpression, keep #should as nice syntactic sugar, but provide > #executed as the standard way of creating ExecutedExpressions. After all > this is useful for more than SUnit. Thank's for suggestion Eliot. I would think about it. Underhood should expressions are based on reusable components which has no relation to tests. It is first class specifications of object state. Should expression just creates particular instance of spec to validate receiver by it. So ShouldExpression is just syntax sugar helper class. It not implements any "real" behaviour.

March 23, 2016

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

by Eliot Miranda

On Wed, Mar 23, 2016 at 12:04 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-23 19:39 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> This reads nicely. What is the class of the value answered by #should? >> What can you do with it? >> > > It returns ShouldExpression instance which wraps receiver to execute > following messages. And following messages are supposed to execute some > assertions under receiver. > For example it can be "1 should be: 2". Or in case with block: "[1/0] > should raise: ZeroDivide" > Personally I would rename ShouldExpression to ExecutedBlock or ExecutedExpression, keep #should as nice syntactic sugar, but provide #executed as the standard way of creating ExecutedExpressions. After all this is useful for more than SUnit. > And for message sends verification I tried to find something similar. > > >> For example, assuming it is a record of the execution of the receiver, >> you could use >> >> [mock someMessage. mock2 someMessage2] executed completely >> [mock someMessage. mock2 someMessage2] executed completelyInOrder >> >> and then #executed is meaningful, whereas #should is merely a linguistic >> hack. >> >> And of course one could use #executes, but I think #executed is better; >> it has the sense of >> >> [mock someMessage. mock2 someMessage2] when executed, #executes completely >> > _,,,^..^,,,_ best, Eliot

March 23, 2016

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

by Denis Kudriashov

2016-03-23 19:39 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > This reads nicely. What is the class of the value answered by #should? > What can you do with it? > It returns ShouldExpression instance which wraps receiver to execute following messages. And following messages are supposed to execute some assertions under receiver. For example it can be "1 should be: 2". Or in case with block: "[1/0] should raise: ZeroDivide" And for message sends verification I tried to find something similar. > For example, assuming it is a record of the execution of the receiver, you > could use > > [mock someMessage. mock2 someMessage2] executed completely > [mock someMessage. mock2 someMessage2] executed completelyInOrder > > and then #executed is meaningful, whereas #should is merely a linguistic > hack. > > And of course one could use #executes, but I think #executed is better; it > has the sense of > > [mock someMessage. mock2 someMessage2] when executed, #executes completely >

March 23, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] I would be extremely grateful for a reproducible case for the following Socket issue

by Eliot Miranda

Hi Levente, On Wed, Mar 23, 2016 at 11:31 AM, Levente Uzonyi <leves(a)caesar.elte.hu> wrote: > Hi Eliot, > > What sort of reproducibility are you looking for? Is it enough if it > happens once every few hours or do you need something that you can trigger > on demand? I'll take every few hours, but I'd prefer "in under 30 minutes". Getting warm and fuzzy feelings when trying to prove a negative with something that takes hours to run is very difficult. Let's say you have a case which reproduces in 8 hours 50% of the time. To reach 99% confidence level in a fix I'd have to run it for 8 * (50 log: 2) hours without seeing it reproduce, right? That's nearly 2 days; it could take weeks to fix :-( Levente > _,,,^..^,,,_ best, Eliot

March 23, 2016

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

by Eliot Miranda

Hi Denis, On Wed, Mar 23, 2016 at 9:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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 > > ? > This reads nicely. What is the class of the value answered by #should? What can you do with it? For example, assuming it is a record of the execution of the receiver, you could use [mock someMessage. mock2 someMessage2] executed completely [mock someMessage. mock2 someMessage2] executed completelyInOrder and then #executed is meaningful, whereas #should is merely a linguistic hack. And of course one could use #executes, but I think #executed is better; it has the sense of [mock someMessage. mock2 someMessage2] when executed, #executes completely :-) _,,,^..^,,,_ best, Eliot

March 23, 2016

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

by Eliot Miranda

On Wed, Mar 23, 2016 at 6:05 AM, Ben Coman <btc(a)openinworld.com> wrote: > 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? > IMO use "was done/was doneInOrder". It is correct English to say "a compound action was performed". In any case it is the block that is evaluated, and that's a singular item. [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 > _,,,^..^,,,_ best, Eliot

March 23, 2016

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