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

Re: [Pharo-dev] Kernel Discussion

by Frank Shearar

On 25 May 2013 12:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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). So if I'd read the entire thread before posting (who on earth does _that_?), I'd have read this. Yes, this is exactly what my mail meant. The low level packages can refer to _something_, and some higher level package can be plugged into _something_'s hole. frank > -- > Best regards, > Igor Stasenko. >

May 25, 2013

Re: [Pharo-dev] Kernel Discussion

by Frank Shearar

On 25 May 2013 11: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? Like Stef says, using #asClassIfPresent makes things worse because the dependency is still there, only harder to find. Returning nil adds another problem, in that you can end up with an UndefinedObject >> #doesNotUnderstand: far away from the cause of the problem. The first way I've worked with these is moving UnixResolver >> #nbGetNev: to the NativeBoost package. That means that NativeBoost -> UnixResolver, which at least is a dependency pointing in the right direction. (I'm ignoring the fact that in this case there's clearly a platform difference issue: UnixResolver makes no sense on a Windows machine, obviously.) Another approach is to have something like an AppRegistry subclass. This is a class that has a #register: method which lets you set the class of something. Maybe it's a mail client, maybe it's the main browser class. That provides in the lower packages a hook. Other packages can just refer to the hook, and the higher level packages can use that hook to get called, without lower level packages depending on those higher level packages. frank

May 25, 2013

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

by Sean P. DeNigris

Sean P. DeNigris wrote > Yes!!! From > http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4083086.html > : But IIRC ephemerons are needed for subscribing blocks that way... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Memory-leaks-with-Spec-tp4689839p4689854.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 25, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by kilon

ok i see, well I did not mean that we dont need platform specific code, of course we do. thanks for adding me. I will first try to contribute some example classes that show how nbopengl can be used in practice. And see if I can fix any of the bugs I find. No problem if you dont have time, I do and will HOPEFULLY be the very area will focus from now , so I am here to stay unless I hit a dead end and cant use opengl properly for some reason. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689853.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 25, 2013

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

by Sean P. DeNigris

stephane ducasse wrote > Igor I will use weak (may be weak should be default and we should propose > strong as an option) > but I do not understand since Yes!!! From http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4083086.html : > So it sounds like weak is the vast majority, so maybe have "announcer > on:..." which gives you weak subscriptions and "announcer strong on:..." > following "Make common things easy, rare things possible" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-Memory-leaks-with-Spec-tp4689839p4689852.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 25, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

Am 25.05.2013 um 13:22 schrieb Igor Stasenko <siguctua(a)gmail.com>: > On 25 May 2013 11:44, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>> so that means nobody *actually* loads code without tests? :D (evil laugh). >>> >>> But i do not argue about what is the be best deployment scenario. >>> >>> I am arguing about leaving developers to choose: >>> - if (s)he wants to deploy with tests or not, it should be up to him. >> >> it's also up to him to >> - write configurations >> - write tests >> - write documentation and examples >> - commit code to a repository >> - create jenkins jobs >> >> you see, there are many things that one can avoid to do in a project, yet it >> is a common standard to do ALL of these tasks for a project. Yet you have your >> liberty to ignore these things. > > It heavily depends what kind of project is it. > For small/tiny projects following all steps/recommendations may be not necessary > and actually cumbersome. Consider pilot projects as well. > For frameworks, mid to big projects or any project with intent to be > used by others, of course, building up an ecosystem (docs, tests, > examples etc) is necessary. > > >> It is about the good path and how you push people towards it. If you do not >> provide the tools for it we will be stuck in stone age forever. >> >> It has never been the liberty of ignoring things that brought a project forward, >> but the tools that open new possibilities. >> >> How does an ideal project look for you? > > Ideal project has tests, docs, examples books, flyers with ad, sales > managers and profit :) > But things are never ideal, and you always looking for a sweet spot between: > - time > - resources > - features > > and in situations when you lack of time & resources (usual for > open-source projects), you have to pick what features to implement > first, and which have to wait. You simply cannot afford to do > everything in time, and hence you need to prioritize things. Writing > documentation before 1st line of code, or otherwise? > > > But this is orthogonal to my point. I see little point in keeping > tests in deployed image. > It is good to have tests, and run them regularly while developing, > using SCM, continuous integration, writing docs, examples etc etc.. > > Consider deploying database application. To run all the tests for it > may take days, often will require setting up special testing > environment (outside of image) and many other things.. > That means , even if you will keep those tests in image, you will be > never able to run them in deployed environment, simply because this > will mean: stopping all services, changing configs, firewalls.. etc.. > So, do you really think that in such scenario (which actually typical > for most server-based applications), > having tests in deployed image makes any difference? Yes, yes and yes. I agree with everything you said. Norbert

May 25, 2013

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

by Igor Stasenko

On 25 May 2013 14:01, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Igor I will use weak (may be weak should be default and we should propose strong as an option) > but I do not understand since > >>> LoggerUI allInstances do: [ :each | >>> SystemAnnouncer uniqueInstance unsubscribe: each ] > > should unregister everything. > is it held only by announcer or something else? > Stef > > > 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. >> > > -- Best regards, Igor Stasenko.

May 25, 2013

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

by Esteban Lorenzano

yes, but rizel will give us a good comparison between different versions of our own systems, but now agains others (because rizel=interpreter=old and slow) :) not that it is bad, but I would prefer a dedicated machine. said so... I think if we have the benchmarks, I think we can annoy Stef enough to get a dedicated benchmark machine... not a terrible new one, but good enough :) but we need to have the benchmarks first, otherwise is loosing time, he. Esteban On May 25, 2013, at 1:47 PM, 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 > >

May 25, 2013

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

by stephane ducasse

On May 25, 2013, at 1:59 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > I am pretty sure to only use weak registration (why aren't all the registration weak btw ??) > > It may be a problem somewhere else :( Yes I'm trying to understand. > 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] Memory leaks with Spec?

by stephane ducasse

Igor I will use weak (may be weak should be default and we should propose strong as an option) but I do not understand since >> LoggerUI allInstances do: [ :each | >> SystemAnnouncer uniqueInstance unsubscribe: each ] should unregister everything. Stef 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