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

[Pharo-project] Fwd: Pharo support for magma repositories

by StÃ©phane Ducasse

Begin forwarded message: > From: Markus Fritsche <fritsche.markus(a)googlemail.com> > Date: May 1, 2011 4:56:48 PM GMT+02:00 > To: pharo-users-owner(a)lists.gforge.inria.fr, magma(a)lists.squeakfoundation.org > Subject: Pharo support for magma repositories > > Hello, > > I registered a project at squeaksource: > http://www.squeaksource.com/MagmaPharoSupport.html > > In my pharo image ;-) (I will check loading in a clean pharo image in > a bit) this enables using (local, server not yet tested) magma > repositories with the Pharo version of Monticello. It also alters the > cleanup-method of MagmaSession to be working with Pharo (PointerFinder > vs. ProtoObject>>#pointersTo). > > If anyone wants to join the project, you're welcome. > > Pharo version: > Pharo1.3a > Latest update: #13177 > > Magma: > Ma client server cmm.217 > Ma base additions cmm.187 > Magma server cmm.425 > > > Kind regards, > Markus Fritsche >

May 1, 2011

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

by Mariano Martinez Peck

On Sun, May 1, 2011 at 3:49 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > So...the only thing we change is the order in the parameters....the > question > > is... do you condiser that changing the API ? > > I think this is changing the API because the contract of the method > changes. But, it's an important change and it has a limited impact: > > - only error messages for non passing tests will be affecting > exactly > - there are few senders of this message > yes, I checked that too > - among the existing senders, a lot of them use the API the wrong way > (which means there code will get fixed automatically when we update > the API :-)). > > exactly :) The other possibily is to forget about actual and expected and let the message be soemthing like 'Assertion failed: (' , actual asString , ') ~= (' , expected asString , ')' or 'Assertion failed: (' , expected asString , ') ~= (' , actual asString , ')' But still...I prefer the previous one 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

May 1, 2011

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

by Damien Cassou

On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > So...the only thing we change is the order in the parameters....the question > is... do you condiser that changing the API ? I think this is changing the API because the contract of the method changes. But, it's an important change and it has a limited impact: - only error messages for non passing tests will be affecting - there are few senders of this message - among the existing senders, a lot of them use the API the wrong way (which means there code will get fixed automatically when we update the API :-)). -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 1, 2011

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

by StÃ©phane Ducasse

this is a detail. Fix it fast and pass to the next important point. On May 1, 2011, at 3:54 PM, Mariano Martinez Peck wrote: > > > On Sun, May 1, 2011 at 3:49 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Sun, May 1, 2011 at 2:50 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > So...the only thing we change is the order in the parameters....the question > > is... do you condiser that changing the API ? > > I think this is changing the API because the contract of the method > changes. But, it's an important change and it has a limited impact: > > - only error messages for non passing tests will be affecting > > exactly > > - there are few senders of this message > > yes, I checked that too > > - among the existing senders, a lot of them use the API the wrong way > (which means there code will get fixed automatically when we update > the API :-)). > > > exactly :) > > The other possibily is to forget about actual and expected and let the message be soemthing like > > 'Assertion failed: (' , actual asString , ') ~= (' , expected asString , ')' > > or > > 'Assertion failed: (' , expected asString , ') ~= (' , actual asString , ')' > > > But still...I prefer the previous one 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 >

May 1, 2011

Re: [Pharo-project] System time

by Mariano Martinez Peck

On Sun, May 1, 2011 at 4:15 AM, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello, > > My OS for this application is Windows. On a freshly opened image, the image > and OS time are in sync. Over a period of time the image drifted 34 seconds > away from OS time. I do not know how long I had this image open, but it has > been a number of days, possibly a week plus. > > I saved the image and quit. I reopened the image and did DateAndTime now > and it was in sync with the OS once again. Same image, vm and OS that was > out of sync by 34 seconds only one minute before. > > I have opened an image on my server which is also running the latest cog > vm, the current Pharo 1.3 and Windows Vista. I am going to periodically do a > DateAndTime now to log the drift if any. Prior to opening this image I > updated the OS system clock with time.nist.gov which is about 1000 miles > away. > > I know that within a second or so it can be subject to my coordination of > doing DateAndTime now while watching my OS system clocks seconds. But 34 > seconds is beyond any subjective standards. > > The only reason I discovered this was while exploring how I want to > retrieve my data, act upon my data and then pause (Delay wait) until time to > repeat. > dtnow := DateAndTime now. > dtnext := DateAndTime year: 2011 month: 4 day: 30 hour: 11 minute: i > second: 5. "The next minute in the future" > (Delay forDuration: (dtnext - dtnow)) wait. > I have no idea about these topics...but maybe something related to the Delay issue that Gary and Andrian used to have: http://code.google.com/p/pharo/issues/detail?id=3986 > > I got an error, that Duration cannot be a negative number. As I processed > the debugger, I saw that dtnow was greater than dtnext. I watched the OS > clock and manually selected the next minute before I executed. However, I > was within that 34 second window. > > So now I am exploring the problem. > > Thanks. > > Jimmie > > > On 4/30/2011 5:06 PM, Alexandre Bergel wrote: > >> '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 >>> >>> > > -- Mariano http://marianopeck.wordpress.com

May 1, 2011

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

by Mariano Martinez Peck

On Sun, May 1, 2011 at 1:10 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Apr 30, 2011, at 8:22 PM, 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. > > why? > Right now the API is the method assert: expected equals: actual ^ self assert: (expected = actual) description: (self comparingStringBetween: expected and: actual) Which description message is "Expected: expected but was actual" Now....we want to change it to: assert: actual equals: expected ^ self assert: (expected = actual) description: (self comparingStringBetween: expected and: actual ) So...the only thing we change is the order in the parameters....the question is... do you condiser that changing the API ? Cheers Mariano > not? I'm confused. > > > 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 > > > > > -- Mariano http://marianopeck.wordpress.com

May 1, 2011

Re: [Pharo-project] HelpBrowser takes too much time to open

by Mariano Martinez Peck

On Sat, Apr 30, 2011 at 5:35 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > > in fact cannot the cache be class side? beucase now each time you do > HelpBrowser open, you compute again the cache....but I am not sure if they > should change amont different opened browsers > > Could be. It is important to have a scenario. > The problem is getting the pragmas from the whole system. > > If you put the cache on the class side, then you will indeed need to reset > the cache, by registering to the system events. The reset has to be > performed at each installation of a new help. This is a bit more work. Shall > we do to that direction? I think it makes sense. > Not necessary. For me, what I would do is: 1) Put the cache at class side so that opening different times it only computes it once 2) Implement #cleanUp self resetChache #resetCache helpTopicCache := nil 3) Modify the "refresh button" , #refresh, so that I also resets the cache. So...whenever there is a change in the system, the use press "refresh". I think it is not a big problem. Anyway, I think the solution I told to Torsten may be better: http://forum.world.st/HelpBrowser-takes-too-much-time-to-open-tp3484859p348… Cheers Mariano > > Alexandre > > > > > > > On Sat, Apr 30, 2011 at 5:07 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > Yes, but this depends what is the expected behavior of the browser. I > like the Agile approach that says you're done when all the tests are green > :-) > > > > Alexandre > > > > > > On 30 Apr 2011, at 10:02, Mariano Martinez Peck wrote: > > > > > Yes, but I have no idea. Another thing is that now HelpBrowser should > implement something like: > > > > > > HelpBrowser >> cleanUp > > > self resetChache > > > > > > >> resetCache > > > helpTopicCache := nil > > > > > > So that the class is automatically cleaned in #cleanUpForRelease and > friends... right now since Smalltalk cleanUp sends to all classes which > understand such method, just implemented that should be enough. > > > > > > Cheers > > > > > > Mariano > > > > > > > > > On Sat, Apr 30, 2011 at 4:58 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > > You're right Mariano. However, I do not know if the help browser gets > updated if you have a browser opened and add a new help in the system. In > any case, this is a requirement that is not formalized by the unit tests. > > > > > > I think that ideally, the reset cache should be done when receiving an > event of a class creation that is a help. > > > > > > Alexandre > > > > > > > > > On 30 Apr 2011, at 09:29, Mariano Martinez Peck wrote: > > > > > > > Cool! Thanks Alexandre. Now...the problem with the cache is always > the same...when to invalidate them. > > > > In this case, when do I need to set helpTopicCache to nil. I guess > that if you create a help, then it is "automatically" detected when you open > the browser. > > > > Now, you have to explicitly flush the cache, haven't you? So...is > there some documentation of HelpSystem that should be updated to reflect > that ? > > > > > > > > Thanks > > > > > > > > On Sat, Apr 30, 2011 at 3:15 AM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > > > > > MessageTally time: [HelpBrowser open] between 2 seconds in Cog > and with a regular VM between 6 and 8.... > > > > > is there an easy way to improve it ? > > > > > > > > > > Alexandre, do you want another place where to put a cache like > Metacello's currentVersion? ;) > > > > > > > > :-) > > > > Sure. Easy. > > > > > > > > SystemHelp>>allSystemHelpPragmas takes time. When you open a browser, > the method HelpBrowser>>open is called once and > SystemHelp>>allSystemHelpPragmas twice. Easy to suspect that a cache is > missing. > > > > > > > > So, if you define > > > > -=-=-=-=-=-=-=-=-= > > > > HelpBrowser>>helpTopic > > > > ^ helpTopicCache ifNil: [ helpTopicCache := rootTopic > asHelpTopic ] > > > > -=-=-=-=-=-=-=-=-= > > > > > > > > and adapt HelpBrowser>>refresh you win 50% of execution time. > > > > > > > > Here is it: > > > > > > > > > > > > http://code.google.com/p/pharo/issues/detail?id=4126 > > > > > > > > Before this fix, I have: > > > > [HelpBrowser open] timeToRun > > > > => 6099 > > > > > > > > After the fix I have: > > > > [HelpBrowser open] timeToRun > > > > => 3094 > > > > > > > > Naturally, tests are kept green. > > > > > > > > Cheers, > > > > Alexandre > > > > > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > Alexandre Bergel http://www.bergel.eu > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Mariano > > > > http://marianopeck.wordpress.com > > > > > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Mariano > > > http://marianopeck.wordpress.com > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

May 1, 2011

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

by Hernan Wilkinson

you will see the problem in the error description... it will be backwards And it has some redefinitions in some subclasses, I donÂ´t understand why :-) On Sat, Apr 30, 2011 at 3:22 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> 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>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 > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

May 1, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Philippe Marschall

On 29.04.2011 19:03, Eliot Miranda wrote: > > > On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos(a)gmx.net > <mailto:kustos@gmx.net>> wrote: > > On 27.04.2011 19 <tel:27.04.2011%2019>:23, Eliot Miranda wrote: > > Philippe, > > > > can you please profile before and after? This could very well > be to > > do with the additional cost of shallowCopy for contexts, but it is > > inevitable that a correct implementation is going to be more expensive > > than the simple block-copy. The new implementation can be optimized, > > but we need to profile first to be sure we're tilting at the relevant > > windmill. > > > What kind of profiling do you have in mind, MessageTally? > > > Yes, that would be fine. Thanks! OK, there you go. As you'll see the runtime is about the same, that's because we do more iterations in the same time. Also note the time we're spending in WriteStream >> #nextPutAll: with interestingly has a different growing behavior than WriteStream >> #nextPut: (only 25% vs 100%). I already raised the issue once but people argued that the current code is prefect. Cheers Philippe

May 1, 2011

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

by StÃ©phane Ducasse

On Apr 30, 2011, at 8:22 PM, 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. why? not? I'm confused. > 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 >

May 1, 2011