September 2012 - Pharo-users

Logs MongoTalk

by Santiago Bragagnolo

Hi Francois! Here is logger for pharo. It works in pharo 1.2, 1.3, 1.4 and 2.0. http://concretetypeinference.blogspot.fr/2012/06/metacello-paullepoulpe-pro… Gofer new url: 'http://ss3.gemstone.com/ss/PaulLePoulpe'; package: 'ConfigurationOfPaulLePoulpe'; load. ( ConfigurationOfPaulLePoulpe project version:'1.0') load There are some examples in the package, in any case, you can get some documentation in here: http://concretetypeinference.blogspot.fr/2012/06/pharo-logger-aka-paul-octo… But with the examples, it should be straight forward.. Santiago.

Sept. 7, 2012

factory for quickly building test objects

by sergio_101

hey, all.. i was wondering of there was a system to allow me to quickly build an object for testing.. something that would let me build a complex object that and feed it to a test suite. something that would allow me to define all of the object's attributes and assure its validity quickly.. any ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.ThoseOptimizeGuys.com http://www.CodingForHire.com http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Sept. 7, 2012

Re: [Pharo-users] [Pharo-project] after object create callback?

by Guillermo Polito

Hi! In Pharo, when an object is created, the #initialize message is sent to it automatically. You can create an #initialize method in your class and put whatever you want in it :). BTW, I copy this question to the pharo_users mailing list, since it looks a more appropiate place for it. Cheers, Guille On Fri, Sep 7, 2012 at 3:29 PM, sergio_101 <sergio.rrd(a)gmail.com> wrote: > hey, all.. > > i was wondering how to implement an 'after_create' callback in smalltalk.. > > the idea is, immediately after creating an object, some predefined > methods get called. > > any ideas? thanks! > > > -- > ---- > peace, > sergio > photographer, journalist, visionary > > http://www.ThoseOptimizeGuys.com > http://www.CodingForHire.com > http://www.coffee-black.com > http://www.painlessfrugality.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > >

Sept. 7, 2012

Re: [Pharo-users] Pharo 2.0 + Seaside

by Dale Henrichs

The configuration for Seaside3.1 exposed a bug in Metacello ... I have a fix for the bug in place, but I have one or two additional bugs/features to implement[1] that are also related to the Seaside3.1 configuration needs ... Dale [1] https://github.com/dalehenrich/metacello-work/issues?milestone=4&page=1&sor… ----- Original Message ----- | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> | To: "A friendly place where any question about pharo is welcome" <pharo-users(a)lists.gforge.inria.fr> | Sent: Friday, September 7, 2012 3:22:26 AM | Subject: Re: [Pharo-users] Pharo 2.0 + Seaside | | | | | On Sun, Aug 26, 2012 at 1:52 PM, Chris < cpmbailey(a)btinternet.com > | wrote: | | | | | On 24/08/2012 14:09, StÃ©phane Ducasse wrote: | | | On Aug 24, 2012, at 2:28 PM, Chris wrote: | | | | I would love to start using Pharo 2.0 but really need Seaside to be | working. I'm assuming from what I've read that it is possible, but | got some issues such as BlockContext missing, references to | OmniBrowser, something about loading Metacello and when it finished | there were 39 failures/errors in the tests. This was just from | loading from the configuration browser in a fresh 2.0 image. Is | there a better way? I like the look of the new system browser so far | but it has felt a little sluggish in places. I hope this improves as | I almost don't want to go back to OmniBrowser now :-) | :) | | Chris | | Do not start with 2.0 because we are shaking the system :) | Now imagine that you really want, then start from the seaside | configurationOfSeaside and let us know the problem you find. | | I'm quite happy with1.4 currently but would like to try things such | as Fuel, Tanker, Nautilus and so on. | | | Fuel works from Pharo 1.1 to Pharo 2.o. Tanker will only work in 2.0. | Seaside is working in 2.0 but not yet the ConfigurationOf. During | ESUG Seasiders said it was going to be fixed soon. | | | With regards to Seaside, it's actually pretty close to be fair. I had | to prefix MetacelloMCProject with Smalltalk at: in | ConfigurationOfMetacello>># project. The OmniBrowser packages | obviously complained but I just proceeded. There are methods such as | fixCallbackTemps on BlockContext and that class is now gone, | presumably these could move to ContextPart? Of the failing tests | after that, most were just a case of renaming calls to | includesSubString: with includesSubstring: . Most of the other | errors were related to SystemChangeNotifier no longer existing, the | odd one where FileDirectory doesn't and so on | | | | | | | | | | | | -- | Mariano | http://marianopeck.wordpress.com | |

Sept. 7, 2012

Re: [Pharo-users] Pharo 2.0 + Seaside

by Mariano Martinez Peck

On Sun, Aug 26, 2012 at 1:52 PM, Chris <cpmbailey(a)btinternet.com> wrote: > On 24/08/2012 14:09, StÃ©phane Ducasse wrote: > >> On Aug 24, 2012, at 2:28 PM, Chris wrote: >> >> I would love to start using Pharo 2.0 but really need Seaside to be >>> working. I'm assuming from what I've read that it is possible, but got some >>> issues such as BlockContext missing, references to OmniBrowser, something >>> about loading Metacello and when it finished there were 39 failures/errors >>> in the tests. This was just from loading from the configuration browser in >>> a fresh 2.0 image. Is there a better way? I like the look of the new system >>> browser so far but it has felt a little sluggish in places. I hope this >>> improves as I almost don't want to go back to OmniBrowser now :-) >>> >> :) >> >> Chris >> >> Do not start with 2.0 because we are shaking the system :) >> Now imagine that you really want, then start from the seaside >> configurationOfSeaside and let us know the problem you find. >> > > I'm quite happy with1.4 currently but would like to try things such as > Fuel, Tanker, Nautilus and so on. Fuel works from Pharo 1.1 to Pharo 2.o. Tanker will only work in 2.0. Seaside is working in 2.0 but not yet the ConfigurationOf. During ESUG Seasiders said it was going to be fixed soon. > With regards to Seaside, it's actually pretty close to be fair. I had to > prefix MetacelloMCProject with Smalltalk at: in ConfigurationOfMetacello>># > **project. The OmniBrowser packages obviously complained but I just > proceeded. There are methods such as fixCallbackTemps on BlockContext and > that class is now gone, presumably these could move to ContextPart? Of the > failing tests after that, most were just a case of renaming calls to > includesSubString: with includesSubstring: . Most of the other errors were > related to SystemChangeNotifier no longer existing, the odd one where > FileDirectory doesn't and so on > >> >> >> >> > > -- Mariano http://marianopeck.wordpress.com

Sept. 7, 2012

ss3.gemstone.com MAINTENANCE Friday September 7 from 2pm-3pm PDT

by Dale Henrichs

ss3.gemstone.com will be down for Maintenance this Friday (September 7) for 1 hour starting at 2pm PDT. We're fixing a configuration issue (my mistake:). Dale

Sept. 5, 2012

Re: [Pharo-users] [Pharo-project] Zinc-HTTP-Deprecated

by Sven Van Caekenberghe

FYI, Sven Van Caekenberghe uploaded a new version of Zinc-HTTP to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenbergh… ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.300 Author: SvenVanCaekenberghe Time: 5 September 2012, 1:59:02 am UUID: a09fb75e-0ba5-489c-bc1b-435481a08164 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.299 removal of all classes in Zinc-HTTP-Deprecated - ZnClientOld - ZnFixedClient - ZnExtendedFixedClient - ZnUserAgent - ZnHttpClient - ZnUserAgentSettings as well as all their unit test classes On 23 Aug 2012, at 15:52, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > There is a class category called 'Zinc-HTTP-Deprecated'. It contains some old classes that were replaced/superceded by newer ones almost a year ago. > > I plan to actually delete these and their unit tests in a commit in the next couple of days. > > Specifically, the following classes will be removed: > > - ZnClientOld > - ZnFixedClient > - ZnExtendedFixedClient > - ZnUserAgent > - ZnHttpClient > - ZnUserAgentSettings > > I hope nobody uses these anymore. > > > Sven > > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by S Krish

Now with this one change: You can do this on Athens rendering morphs or on the clock. #stepTime at 1000 ms it runs at about 6% CPU.. at 100 ms it runs up about 40%.. and for 20 ms.. that is more or less immediate rendering.. I see about 15 ms is consumed even if you set the stepTime to 1. the CPU usage peaks to 80%+... On Wed, Sep 5, 2012 at 4:37 PM, S Krish <krishnamachari.sudhakar(a)gmail.com>wrote: > Call it error / removable property rendering on drawOn: > > For: > > #stepTime > > ^5000. > > > #drawOn: aCanvas > > super drawOn: aCanvas. > > "Other draw routines: draw other submorphs, lines etc.. " > > * **self borderStyle: aStyleSetBasedOnTime *. > > * "This one statement makes it draw immediately.. for all morphs remove > this it works like a charm rendering only every 5 seconds..stupid and > obviously not a big need.. but in case needed.. better not placed here.."* > * > * > > Are there any other caveats is not known for now.. but its ok for now... > > > > > On Wed, Sep 5, 2012 at 11:58 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> Also, check the implementors of stepTime. >> >> e.g. in Balloon: >> >> BalloonMorph>>stepTime >> ^ 0 "every cycle" >> >> Ouch. >> >> Athens may have something similar. >> >> Philippe Back >> >> 2012/9/5 S Krish <krishnamachari.sudhakar(a)gmail.com>: >> > >> > I understand the impact of rendering every millisecond.. >> > >> > >> > TestAnimationClock >> > #drawOn: aCanvas >> > >> > I have to dig in a bit more.. is the issue here.. not NB/ VGTigerDemo. >> > >> > Normally all of Morphic rendering is I presume , premised on the >> invocation >> > of this method recursively on all submorphs till all of them are >> rendered.. >> > for all morphs on screen. >> > >> > TestAnimationClockPanel: Also I have a similar override.. and it does >> not >> > give me any overhead.. though all it has is one Text.. string. >> > >> > Why should only Clock have such an overhead.. : is because of >> calculating >> > the hour/minute/hand vector .. ? >> > >> > Will dig in more and try to understand this for optimizations. >> > >> > >> > ********** >> > PS: I am not using the startStepping / stop.. mechanism as yet in >> these.. >> > >> > Maybe I am naive.. about presuming.. >> > >> > On Wed, Sep 5, 2012 at 3:36 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> On 4 September 2012 16:18, S Krish <krishnamachari.sudhakar(a)gmail.com> >> >> wrote: >> >> > As an screenshot should explain it better.. >> >> > >> >> > This is now pushing the CPU to 66 - 90%+ almost all the time.. and as >> >> > the >> >> > top hogger of CPU constantly.. >> >> > >> >> hmm, what did you expected there? Cairo uses CPU for rendering. It is >> >> faster than balloon, must faster >> >> but sure thing if you run animation which renders new frame as soon as >> >> it finished previous one, >> >> it will consume full available CPU resources. >> >> >> >> >> >> > Not having VGTigerDemo does not alter it much.. so its not >> NativeBoost >> >> > at >> >> > fault per se.. >> >> > >> >> > Kill the clock and the VGTiger it comes down to a nice 4% CPU >> >> > >> >> >> >> >> >> >> >> >> >> > On Tue, Sep 4, 2012 at 7:08 PM, S Krish >> >> > <krishnamachari.sudhakar(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> If we override #drawOn: and implement custom logic to draw.. every >> few >> >> >> milliseconds as it gets called the CPU usage shoots to available >> max.. >> >> >> >> >> >> Run four instances of the same class that overrides and does some >> >> >> moderately complex draw routine of say : CircleMorph with border >> set, >> >> >> few >> >> >> lines, color rendering.. >> >> >> >> >> >> I will send in the .st file later .. that can be tested against.. >> >> >> >> >> >> >> >> >> Is this expected or what are the ways to avoid this CPU overhead... >> >> >> >> >> >> >> >> >> NativeBoost animation, far more responsive.. also goes up very >> >> >> similarly. >> >> >> but little more tolerable... VGTigerMorph... more so than >> FlakesDemo... >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> >

Sept. 5, 2012

Re: [Pharo-users] Max CPU usage when #drawOn: is overridden

by S Krish

Call it error / removable property rendering on drawOn: For: #stepTime ^5000. #drawOn: aCanvas super drawOn: aCanvas. "Other draw routines: draw other submorphs, lines etc.. " * **self borderStyle: aStyleSetBasedOnTime *. * "This one statement makes it draw immediately.. for all morphs remove this it works like a charm rendering only every 5 seconds..stupid and obviously not a big need.. but in case needed.. better not placed here.."* * * Are there any other caveats is not known for now.. but its ok for now... On Wed, Sep 5, 2012 at 11:58 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Also, check the implementors of stepTime. > > e.g. in Balloon: > > BalloonMorph>>stepTime > ^ 0 "every cycle" > > Ouch. > > Athens may have something similar. > > Philippe Back > > 2012/9/5 S Krish <krishnamachari.sudhakar(a)gmail.com>: > > > > I understand the impact of rendering every millisecond.. > > > > > > TestAnimationClock > > #drawOn: aCanvas > > > > I have to dig in a bit more.. is the issue here.. not NB/ VGTigerDemo. > > > > Normally all of Morphic rendering is I presume , premised on the > invocation > > of this method recursively on all submorphs till all of them are > rendered.. > > for all morphs on screen. > > > > TestAnimationClockPanel: Also I have a similar override.. and it does not > > give me any overhead.. though all it has is one Text.. string. > > > > Why should only Clock have such an overhead.. : is because of calculating > > the hour/minute/hand vector .. ? > > > > Will dig in more and try to understand this for optimizations. > > > > > > ********** > > PS: I am not using the startStepping / stop.. mechanism as yet in > these.. > > > > Maybe I am naive.. about presuming.. > > > > On Wed, Sep 5, 2012 at 3:36 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 4 September 2012 16:18, S Krish <krishnamachari.sudhakar(a)gmail.com> > >> wrote: > >> > As an screenshot should explain it better.. > >> > > >> > This is now pushing the CPU to 66 - 90%+ almost all the time.. and as > >> > the > >> > top hogger of CPU constantly.. > >> > > >> hmm, what did you expected there? Cairo uses CPU for rendering. It is > >> faster than balloon, must faster > >> but sure thing if you run animation which renders new frame as soon as > >> it finished previous one, > >> it will consume full available CPU resources. > >> > >> > >> > Not having VGTigerDemo does not alter it much.. so its not NativeBoost > >> > at > >> > fault per se.. > >> > > >> > Kill the clock and the VGTiger it comes down to a nice 4% CPU > >> > > >> > >> > >> > >> > >> > On Tue, Sep 4, 2012 at 7:08 PM, S Krish > >> > <krishnamachari.sudhakar(a)gmail.com> > >> > wrote: > >> >> > >> >> > >> >> > >> >> If we override #drawOn: and implement custom logic to draw.. every > few > >> >> milliseconds as it gets called the CPU usage shoots to available > max.. > >> >> > >> >> Run four instances of the same class that overrides and does some > >> >> moderately complex draw routine of say : CircleMorph with border set, > >> >> few > >> >> lines, color rendering.. > >> >> > >> >> I will send in the .st file later .. that can be tested against.. > >> >> > >> >> > >> >> Is this expected or what are the ways to avoid this CPU overhead... > >> >> > >> >> > >> >> NativeBoost animation, far more responsive.. also goes up very > >> >> similarly. > >> >> but little more tolerable... VGTigerMorph... more so than > FlakesDemo... > >> >> > >> >> > >> >> > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > >

Sept. 5, 2012

Re: [Pharo-users] Get the point of Intersection for Morphs

by Camillo Bruni

On 2012-09-05, at 01:22, irfankhan1 <irfankhan(a)hotmail.ca> wrote: > I have a new class for Circle Morph which has a step method that increases > the diameter. > > > step > > self extent: self extent +1. > (self extent )>(400@400) ifTrue: [self stopStepping] > > > b:=CircleAnimeMorph new // new class for Circle Morph > b openInWorld > b startStepping > b1:CircleAnimeMorph new > b1 openInWorld > b1 startStepping. > > > > > So when these both Circles meet i wanna get the Intersecting point,idk how > to implement this can any one help? see all the details here: http://mathworld.wolfram.com/Circle-CircleIntersection.html basically you first check if both radii overlap, once you know that you can do the detailed trigonometry to get the intersection points. As a first step I would implement a #intersectsCircle: aCircle method. The I think it makes most sense to put the two circles into a surrounding morph which will take care of the intersection check. Simply override the step method there and perform the tests.

Sept. 5, 2012