April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: update needed to Pharo book section 3.5

by Mariano Martinez Peck

Doug, do you want a username to edit the book? I can create one for you...just tell me. cheers mariano On Thu, Apr 21, 2011 at 7:54 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > If someone can look at this .... > > Laurent > ---------- Forwarded message ---------- > From: Doug Edmunds <dougedmunds(a)gmail.com> > Date: Mon, Apr 18, 2011 at 11:40 PM > Subject: update needed to Pharo book section 3.5 > To: laurent laffont <laurent.laffont(a)gmail.com> > > > http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting > > uses ParagraphEditor in the example code. > > According to v 1.3, ParagraphEditor is deprecated (Deprecated13 package). > > You should hunt around for some other class to use in section 3.5 > instead of ParagraphEditor. > > :dae > > -- Mariano http://marianopeck.wordpress.com

April 30, 2011

Re: [Pharo-project] System time

by Alexandre Bergel

'Time now' gives me the same result than OSX Alexandre On 30 Apr 2011, at 16:15, Jimmie Houchin wrote: > On 4/30/2011 11:50 AM, StÃ©phane Ducasse wrote: >>> I am developing a time sensitive application. I poll a server every minute for new data. The data is time sensitive and the sooner I can get the data to the release of the data the better. >>> >>> I have noticed that Pharo's system time drifts away from the OS system time. I would really like the Pharo system time to be the correct time. >> do you have a repeatable scenario? >> VM >> Image information. > Pharo 1.3 and the latest Cog. > >>> I have not been able to find where in Pharo I can call to update the System clock to the correct time. >> you can use OSProcess (only mac and linux) > No, that's not the problem. The OS clock is right. It's Pharo that has drifted away from correct time. Regardless it would be nice if I have to correct the OS clock, it would still be nice to resync Pharo with the OS, keep both in sync and correct. What I am wanting is simply to resync the Pharo clock with the OS clock. > > It seems that when the Pharo image is started that it gets the OS System time, but keeps its own time after that. Now I do not know the consequences of Pharo adjusting its time backward. If this isn't possible, then I might have to do some workarounds to insure that I get my data in a timely manner. > > The image I have been developing in is currently about 30 seconds ahead of the OS clock. It is on my laptop. It might be due to the laptops sleep and hibernation. I have not tested this on my server. > > That is the situation as best I know it. > > Thanks. > > Jimmie > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 30, 2011

Re: [Pharo-project] System time

by Jimmie Houchin

On 4/30/2011 11:50 AM, StÃ©phane Ducasse wrote: >> I am developing a time sensitive application. I poll a server every minute for new data. The data is time sensitive and the sooner I can get the data to the release of the data the better. >> >> I have noticed that Pharo's system time drifts away from the OS system time. I would really like the Pharo system time to be the correct time. > do you have a repeatable scenario? > VM > Image information. Pharo 1.3 and the latest Cog. >> I have not been able to find where in Pharo I can call to update the System clock to the correct time. > you can use OSProcess (only mac and linux) No, that's not the problem. The OS clock is right. It's Pharo that has drifted away from correct time. Regardless it would be nice if I have to correct the OS clock, it would still be nice to resync Pharo with the OS, keep both in sync and correct. What I am wanting is simply to resync the Pharo clock with the OS clock. It seems that when the Pharo image is started that it gets the OS System time, but keeps its own time after that. Now I do not know the consequences of Pharo adjusting its time backward. If this isn't possible, then I might have to do some workarounds to insure that I get my data in a timely manner. The image I have been developing in is currently about 30 seconds ahead of the OS clock. It is on my laptop. It might be due to the laptops sleep and hibernation. I have not tested this on my server. That is the situation as best I know it. Thanks. Jimmie

April 30, 2011

[Pharo-project] [update 1.3] #13178

by StÃ©phane Ducasse

13178 ----- - Issue 4125: option to copy a stacktrace to clipboard in the debugger context menu. Thanks Mariano Martinez-Peck. - Issue 3952: SystemNavigation deeper use of environment. Thanks Benjamin van Ryseghem. - Issue 3445: [Repackage] SUnit should be well structured. Thanks Torsten Bergman. Stef from York.

April 30, 2011

Re: [Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?

by Andres Valloud

When the expected answer is not a literal, then the order is not so important. Usually, complex tests have expected answers that are not literals, and you end up with a method along the lines of expectedAnswer := self doItOneWay. actualAnswer := self doItTheOtherWay. self assert: expectedAnswer = actualAnswer or expectedAnswer := self doItOneWay. actualAnswer := self doItTheOtherWay. self assert: actualAnswer = expectedAnswer But, see, in this case the temporary value names remove the confusion, and then the order doesn't matter as much. It seems to me the original issue is that the meaning of a message argument is implicit only in the order because the selector does not distinguish between the two provided arguments. In short, the selector is vague because it does not help disambiguating the meaning just by reading the code aloud. You can change the order if you want, but I suspect there's more to it than that. My 2c of devalued Monopoly money printed on recycled newspaper... :). Andres. On 4/30/11 11:22 , Mariano Martinez Peck wrote: > Thanks everybody, it is nice to see I am not alone.. > Yes, Stef, the API is the same, but the sematics is not. I mean, I > muuuch prefer to change it, but indeed, there will be a change in the > "behavior". What I mean is that all test cases that were using > #assert:equals: in the "correct" way (correct I mean to what SUnit > says), then after will be "incorrect". I don't care. The only problem is > that when they debugger the message will be incorrect. > But it is as always....or improve or be backward compatibility.... > > So... +1 to the change > > Here is the issue tracker: > http://code.google.com/p/pharo/issues/detail?id=4129 > > if we finally agree, I can submit the fix. > > Cheers > > Mariano > > > On Sat, Apr 30, 2011 at 7:13 PM, Damien Cassou <damien.cassou(a)gmail.com > <mailto:damien.cassou@gmail.com>> wrote: > > On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > testBlah > > | universalAnswer | > > universalAnswer := 30. > > universalAnswer := universalAnswer + 11. > > self assert: universalAnswer equals: 42. > > > > In this case, 42 is the "expected" and "universalAnswer" is the > "actual" > > value. > > I feel weird writing like this: > > > > self assert: 42 equals: universalAnswer. > > I think I'm responsible for this non sense, sorry about that. When I > put the parameters in this order, I thought the result would be > similar to JUnit in which 'expected' is always before 'actual'. > Unfortunately, it looks like I just forgot to read the whole sentence: > 'self assert that something equals 42' reads much better than the > other way around. I don't think too much code depends on this > #assert:equals: method as it has only been introduced recently. > > I vote for changing the order. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > > > > -- > Mariano > http://marianopeck.wordpress.com >

April 30, 2011

Re: [Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?

by Andres Valloud

I use temporary value names such as expectedAnswer and actualValue. Then I feel there's no confusion. On 4/30/11 7:20 , Mariano Martinez Peck wrote: > Hi guys. I always code my tests something like this: > > testBlah > | universalAnswer | > universalAnswer := 30. > universalAnswer := universalAnswer + 11. > self assert: universalAnswer equals: 42. > > In this case, 42 is the "expected" and "universalAnswer" is the "actual" > value. > I feel weird writing like this: > > self assert: 42 equals: universalAnswer. > > I don't know why...but I do..the same as when doing should: [] raise: > Error. > In that case you put the "actual" first and the "expected" at the end... > > ok....the "problem" is that assert:equals: is in fact: asserts: > expected equals: actual instead of > asserts: actual equals: expected > > So, with my test I would receive a description in the debugger that says > "'Expected 41 but was 42.'" > which is completely the opposite. Of course, if I write my tests in the > way I don't like, that is: > self assert: 42 equals: universalAnswer. > > then i got the correct message "'Expected 42 but was 41.'" > > I don't pretend pharo change this because I guess it is standard, and > blah blah blah. But senders of #assert:equals: should both, some written > as mine (so the message is incorrect for them) and some correct. > > In addition, I think it is a problem of the selector name. If we could > make it clearer, the won't be necessary to confuse "actual" with > "expected". > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com >

April 30, 2011

Re: [Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?

by Mariano Martinez Peck

Thanks everybody, it is nice to see I am not alone.. Yes, Stef, the API is the same, but the sematics is not. I mean, I muuuch prefer to change it, but indeed, there will be a change in the "behavior". What I mean is that all test cases that were using #assert:equals: in the "correct" way (correct I mean to what SUnit says), then after will be "incorrect". I don't care. The only problem is that when they debugger the message will be incorrect. But it is as always....or improve or be backward compatibility.... So... +1 to the change Here is the issue tracker: http://code.google.com/p/pharo/issues/detail?id=4129 if we finally agree, I can submit the fix. Cheers Mariano On Sat, Apr 30, 2011 at 7:13 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > testBlah > > | universalAnswer | > > universalAnswer := 30. > > universalAnswer := universalAnswer + 11. > > self assert: universalAnswer equals: 42. > > > > In this case, 42 is the "expected" and "universalAnswer" is the "actual" > > value. > > I feel weird writing like this: > > > > self assert: 42 equals: universalAnswer. > > I think I'm responsible for this non sense, sorry about that. When I > put the parameters in this order, I thought the result would be > similar to JUnit in which 'expected' is always before 'actual'. > Unfortunately, it looks like I just forgot to read the whole sentence: > 'self assert that something equals 42' reads much better than the > other way around. I don't think too much code depends on this > #assert:equals: method as it has only been introduced recently. > > I vote for changing the order. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > -- Mariano http://marianopeck.wordpress.com

April 30, 2011

Re: [Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?

by Damien Cassou

On Sat, Apr 30, 2011 at 4:20 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > testBlah > Â Â Â | universalAnswer | > Â Â Â universalAnswer := 30. > Â Â Â universalAnswer := universalAnswer + 11. > Â Â Â self assert: universalAnswer equals: 42. > > In this case, 42 is the "expected" and "universalAnswer" is the "actual" > value. > I feel weird writing like this: > > Â Â Â self assert: 42 equals: universalAnswer. I think I'm responsible for this non sense, sorry about that. When I put the parameters in this order, I thought the result would be similar to JUnit in which 'expected' is always before 'actual'. Unfortunately, it looks like I just forgot to read the whole sentence: 'self assert that something equals 42' reads much better than the other way around. I don't think too much code depends on this #assert:equals: method as it has only been introduced recently. I vote for changing the order. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

April 30, 2011

[Pharo-project] System time

by Jimmie Houchin

I am developing a time sensitive application. I poll a server every minute for new data. The data is time sensitive and the sooner I can get the data to the release of the data the better. I have noticed that Pharo's system time drifts away from the OS system time. I would really like the Pharo system time to be the correct time. I have not been able to find where in Pharo I can call to update the System clock to the correct time. Any help greatly appreciated. Jimmie

April 30, 2011

Re: [Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?

by Nicolas Cellier

Mariano, I agree, I have NEVER written self assert: expected = actual description: 'expected should equal this result but is not'. That makes me think of this story: In my company, C++ "experts" decided to nether write bool isActive ... if (isActive) { ... } because they pretend every condition must be a test (== <= etc...) to be sure it's a boolean... So they ended up wrting this kind of stupid thing: if (isActive==true) { ... } But I told them : what if you forget one of the equal signs ? Isn't it worse than above ? A lint rule would be so much better ! They said ah, yes you're right, we now gonna write it: if( true==isActive ) { ... } Sometimes, I see loops written like this while(false==isNotActive) { ... } and scratch my head a few seconds. I think our minds are just different... Nicolas 2011/4/30 Peter Hugosson-Miller <oldmanlink(a)gmail.com>: > It feels backwards to me too, in the same way that "one plus one equals two" > feels more natural than "two equals one plus one". > > -- > Cheers, > Peter. > On 30 apr 2011, at 16:20, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi guys. I always code my tests something like this: > > testBlah > Â Â Â | universalAnswer | > Â Â Â universalAnswer := 30. > Â Â Â universalAnswer := universalAnswer + 11. > Â Â Â self assert: universalAnswer equals: 42. > > In this case, 42 is the "expected" and "universalAnswer" is the "actual" > value. > I feel weird writing like this: > > Â Â Â self assert: 42 equals: universalAnswer. > > I don't know why...but I do..the same as when doing should: []Â raise: > Error. > In that case you put the "actual" first and the "expected" at the end... > > ok....the "problem" is that assert:equals:Â is in fact:Â Â asserts: expected > equals: actualÂ instead of > asserts: actual equals: expected > > So, with my test I would receive a description in the debugger that says > "'Expected 41 but was 42.'" > which is completely the opposite. Of course, if I write my tests in the way > I don't like, that is: > Â self assert: 42 equals: universalAnswer. > > then i got the correct message "'Expected 42 but was 41.'" > > I don't pretend pharo change this because I guess it is standard, and blah > blah blah. But senders of #assert:equals: should both, some written as mine > (so the message is incorrect for them) and some correct. > > In addition, I think it is a problem of the selector name. If we could make > it clearer, the won't be necessary to confuse "actual" with "expected". > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

April 30, 2011