- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Zinc problems found

by Sven Van Caekenberghe

On 29 Apr 2011, at 07:32, Sven Van Caekenberghe wrote: > I remember having thought about the first issue, I just don't remember why I did it that way, I'll have to check a bit. The first issue should be fixed now: Name: Zinc-HTTP-SvenVanCaekenberghe.149 Author: SvenVanCaekenberghe Time: 30 April 2011, 8:55:03 pm UUID: 3a49e678-fa7b-4c30-bdc6-0944c7637e7f Ancestors: Zinc-HTTP-SvenVanCaekenberghe.148 rewrote ZnHTTPSocketFacade class>>#entendURL:withArguments: to be compatible with HTTPSocket class>>#argString: (Thanks Esteban Lorenzano) > The second issue them, can you send a print string of the headers in that response ? Maybe there just is no body ? Is there a way for me to try that request ? This is a deeper issue (I described it in a reply to a message 'Strange results from Zinc for the www.delicious.com domain'). I am working on it. Sven

May 1, 2011

Re: [Pharo-project] System time

by Jimmie Houchin

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 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 >>

May 1, 2011

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

May 1, 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 1, 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