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

Re: [Pharo-dev] are there benchmarks like deltablue and richards for Pharo?

by stephane ducasse

>> > > yeah.. that what we actually wanted to do since a while.. when we > first started using CI.. > Unfortunately for that we need a fully controllable environment: no > virtualization, sorry.. > If we could have a fully dedicated machine for that, setting things up > wouldn't be that hard. We can have a machine for this job wihtout problem.

May 25, 2013

Re: [Pharo-dev] Memory leaks with Spec?

by Benjamin

I am pretty sure to only use weak registration (why aren't all the registration weak btw ??) It may be a problem somewhere else :( Ben On May 25, 2013, at 1:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 May 2013 13:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> this is strange I cannot get rid of Spec based ui instances. >> I tried many >> >> LoggerUI allInstances do: [ :each | >> SystemAnnouncer uniqueInstance unsubscribe: each ] >> >> LoggerUI allInstances do: #delete. >> >> Smalltalk garbageCollect >> >> Nothing changes. Each time I create and close it does not get garbage collected. >> I remove all the announcement registration from my code but nothing changes. >> > > That's why it is preferable to always use weak subscriptions: > > announcer weak on: Foo send: #bar to: theGuyWhoWillBeHeldWeakly > > then: > 1. you don't have to unsubscribe > 2. even if you still have memory leaks, you can exclude announcer from equation > >> Stef >> >> > > > > -- > Best regards, > Igor Stasenko. >

May 25, 2013

Re: [Pharo-dev] Kernel Discussion

by stephane ducasse

On May 25, 2013, at 12:55 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I've seen a lot of progress for the Pharo Kernel by Pavel recently and I > really appreciate his work. But I have some questions I think we should discuss. > > There have been quite a few changes to make code work in the Kernel and to > reduce dependencies between packages. But I really have the impression that > many of these changes are of bad quality :/. > > I do not want to offend people, but this is fairly important if we want to > have a nice code base. > > Example: > ======== > UnixResolver >> nbGetEnv: str > #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. > ^ nil > > The goal of this code is to conditionally do something in the main image but > continue to work in the kernel. > > Observations: > ============= > - #asClassIfPresent: and Co are bad Yes I do not like this pattern that because if just hide the problem > - Why do we clutter the main image if the kernel should change? > - Can't we solve these things by having proper other objects? > - Is the UnixResolver really needed in the Kernel? > > I worked with Esteban last week on a similar case in the CommandLineHandler and we ended up introducing a minimal superclass. I guess this goes much in the direction of having proper NullObjects. > > I really think we should not add these little nasty changes, but rather introduce proper > new classes that can be unloaded if needed. > > What do you think?

May 25, 2013

Re: [Pharo-dev] Memory leaks with Spec?

by Igor Stasenko

On 25 May 2013 13:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > this is strange I cannot get rid of Spec based ui instances. > I tried many > > LoggerUI allInstances do: [ :each | > SystemAnnouncer uniqueInstance unsubscribe: each ] > > LoggerUI allInstances do: #delete. > > Smalltalk garbageCollect > > Nothing changes. Each time I create and close it does not get garbage collected. > I remove all the announcement registration from my code but nothing changes. > That's why it is preferable to always use weak subscriptions: announcer weak on: Foo send: #bar to: theGuyWhoWillBeHeldWeakly then: 1. you don't have to unsubscribe 2. even if you still have memory leaks, you can exclude announcer from equation > Stef > > -- Best regards, Igor Stasenko.

May 25, 2013

Re: [Pharo-dev] Spec and list item size

by stephane ducasse

On May 25, 2013, at 1:38 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > PluggableListMorph do not support that Ok thanks. Arghhhh Stef > > Ben > > On May 25, 2013, at 8:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi >> >> How can I specify that the size of a liste element is two lines? >> >> Stef >> >

May 25, 2013

Re: [Pharo-dev] are there benchmarks like deltablue and richards for Pharo?

by Igor Stasenko

On 25 May 2013 13:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-25, at 13:46, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 25 May 2013 13:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> On 2013-05-25, at 13:14, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> >>>> On May 25, 2013, at 1:05 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>>> A couple of them are in Smark >>>>> >>>>> http://smalltalkhub.com/#!/~StefanMarr/SMark >>>>> >>>>> >>>>> On 2013-05-25, at 12:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> I wonder if there are benchmarks around. >>>>>> Also I wonder if there would be useful :) >>>>>> For "marketing" purposes I think yes: if we can put in the web page that we are running those benchmarks, it is cool for "seriousness" (that, of course, assuming the results will not be terribly bad :P) >>>>> >>>>> I know I am a major pain in the ass, but where do you plan to run these tests? >>>> >>>> yes, you are ;) >>>> nah, I do not have any idea where to run them... I even doesn't know if I will, I was just thinking in loud. >>>> but yes, I think it would be good if we can have recurrent (and reliable) benchmarks to show :) >>> >>> >>> We ran a couple of benchmarks with the FulltextSearch project using the rizel command line handler: https://ci.inria.fr/rmod/job/FullTextSearch/plot/? >>> >>> ./pharo $JOB_NAME.image rizel --packagesMatching='FullTextSearch*' --reporter=RizelXMLReporter >> rizel.xml >>> >>> so basically everything is there :) >> >> yeah.. that what we actually wanted to do since a while.. when we >> first started using CI.. >> Unfortunately for that we need a fully controllable environment: no >> virtualization, sorry.. > > well you can perfectly use Rizel in a virtualized environment You mean to count stats in number of "message sends/bytecodes"? Yeah, could do.. but i was more about benchmarking VM itself... -- Best regards, Igor Stasenko.

May 25, 2013

Memory leaks with Spec?

by StÃ©phane Ducasse

Hi guys this is strange I cannot get rid of Spec based ui instances. I tried many LoggerUI allInstances do: [ :each | SystemAnnouncer uniqueInstance unsubscribe: each ] LoggerUI allInstances do: #delete. Smalltalk garbageCollect Nothing changes. Each time I create and close it does not get garbage collected. I remove all the announcement registration from my code but nothing changes. Stef

May 25, 2013

Re: [Pharo-dev] are there benchmarks like deltablue and richards for Pharo?

by Camillo Bruni

On 2013-05-25, at 13:46, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 May 2013 13:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2013-05-25, at 13:14, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On May 25, 2013, at 1:05 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> A couple of them are in Smark >>>> >>>> http://smalltalkhub.com/#!/~StefanMarr/SMark >>>> >>>> >>>> On 2013-05-25, at 12:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> I wonder if there are benchmarks around. >>>>> Also I wonder if there would be useful :) >>>>> For "marketing" purposes I think yes: if we can put in the web page that we are running those benchmarks, it is cool for "seriousness" (that, of course, assuming the results will not be terribly bad :P) >>>> >>>> I know I am a major pain in the ass, but where do you plan to run these tests? >>> >>> yes, you are ;) >>> nah, I do not have any idea where to run them... I even doesn't know if I will, I was just thinking in loud. >>> but yes, I think it would be good if we can have recurrent (and reliable) benchmarks to show :) >> >> >> We ran a couple of benchmarks with the FulltextSearch project using the rizel command line handler: https://ci.inria.fr/rmod/job/FullTextSearch/plot/? >> >> ./pharo $JOB_NAME.image rizel --packagesMatching='FullTextSearch*' --reporter=RizelXMLReporter >> rizel.xml >> >> so basically everything is there :) > > yeah.. that what we actually wanted to do since a while.. when we > first started using CI.. > Unfortunately for that we need a fully controllable environment: no > virtualization, sorry.. well you can perfectly use Rizel in a virtualized environment

May 25, 2013

Re: [Pharo-dev] are there benchmarks like deltablue and richards for Pharo?

by Igor Stasenko

On 25 May 2013 13:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-25, at 13:14, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On May 25, 2013, at 1:05 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> A couple of them are in Smark >>> >>> http://smalltalkhub.com/#!/~StefanMarr/SMark >>> >>> >>> On 2013-05-25, at 12:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> I wonder if there are benchmarks around. >>>> Also I wonder if there would be useful :) >>>> For "marketing" purposes I think yes: if we can put in the web page that we are running those benchmarks, it is cool for "seriousness" (that, of course, assuming the results will not be terribly bad :P) >>> >>> I know I am a major pain in the ass, but where do you plan to run these tests? >> >> yes, you are ;) >> nah, I do not have any idea where to run them... I even doesn't know if I will, I was just thinking in loud. >> but yes, I think it would be good if we can have recurrent (and reliable) benchmarks to show :) > > > We ran a couple of benchmarks with the FulltextSearch project using the rizel command line handler: https://ci.inria.fr/rmod/job/FullTextSearch/plot/? > > ./pharo $JOB_NAME.image rizel --packagesMatching='FullTextSearch*' --reporter=RizelXMLReporter >> rizel.xml > > so basically everything is there :) yeah.. that what we actually wanted to do since a while.. when we first started using CI.. Unfortunately for that we need a fully controllable environment: no virtualization, sorry.. If we could have a fully dedicated machine for that, setting things up wouldn't be that hard. -- Best regards, Igor Stasenko.

May 25, 2013

Re: [Pharo-dev] Kernel Discussion

by Igor Stasenko

On 25 May 2013 12:55, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I've seen a lot of progress for the Pharo Kernel by Pavel recently and I > really appreciate his work. But I have some questions I think we should discuss. > > There have been quite a few changes to make code work in the Kernel and to > reduce dependencies between packages. But I really have the impression that > many of these changes are of bad quality :/. > > I do not want to offend people, but this is fairly important if we want to > have a nice code base. > > Example: > ======== > UnixResolver >> nbGetEnv: str > #NativeBoost asClassIfPresent: [ ^ self privNbGetEnv: str ]. > ^ nil > > The goal of this code is to conditionally do something in the main image but > continue to work in the kernel. > > Observations: > ============= > - #asClassIfPresent: and Co are bad > - Why do we clutter the main image if the kernel should change? > - Can't we solve these things by having proper other objects? > - Is the UnixResolver really needed in the Kernel? > > I worked with Esteban last week on a similar case in the CommandLineHandler and we ended up introducing a minimal superclass. I guess this goes much in the direction of having proper NullObjects. > > I really think we should not add these little nasty changes, but rather introduce proper > new classes that can be unloaded if needed. > > What do you think? hmm.. what about factoring out this functionality in separate package, say "Kernel-Extras" and keep dependencies there. Another approach is using delegates, e.g. when kernel class provides an API while concrete implementation is provided in separate package. That i think same idea as with superclass, which defines common/required interface, and then self-configuring itself depending on what packages are in system and what services registered by them. Then, of course, you need to provide either fallback code or stub code (null pattern). -- Best regards, Igor Stasenko.

May 25, 2013