October 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.2] #12165

by StÃ©phane Ducasse

12165 ----- - Issue 3010: Create button of debugger does not appear when doing step into and step over. Thanks Hernan Wilkinson and Luc Fabresse and Jean-Baptiste Arnaud. - Issue 3011: Create button fails when the doesNotUnderstand: context is not selected. Thanks Hernan Wilkinson and Luc Fabresse and Jean-Baptiste Arnaud. - Issue 965: Messages send but not implemented. Thanks Luc Fabresse Stef

Oct. 1, 2010

Re: [Pharo-project] [update 1.2] #12161 - #12172

by Igor Stasenko

Oh crap.. the problem is not in that. MC produces huge weak-key dictionary during updates for instance 12159 -> 12162 produces dictionary with 14k entries, which sits in #FinalizationDependents array and scanned after each GC. And during scanning, its using block closures (and each push of block closure consuming memory), so it big enough to trigger another GC. And its self-supporting process of wasting CPU cycles just for nothing... Here some numbers: (note, i din't installed new finalization code yet) MCMethodDefinition cachedDefinitions size 14987 [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun 10 so, it spends 10 ms dueing each GC cycle for scanning it. So, the quest is to avoid using block closures during scanning it, so it won't produce garbage. -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

[Pharo-project] [update 1.2] #12164

by StÃ©phane Ducasse

12164 ----- - Issue 3040: Launch change sorter in Pharo 12162 throws DNU. Thanks Luc Fabresse. - Issue 3020: Monticello uses a lot of Smalltalk instead of Smalltalk globals. Thanks Nicolas Paez Stef

Oct. 1, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by Matt Kennedy

Hi everyone, On Oct 1, 2010, at 8:10 AM, Lukas Renggli wrote: > Wow, very impressive. > > What I would like to see is some kind of high-level API for convenient > access to all features. Something along > > response := ZnHttp new > url: 'http://www.foo.com'; > userAgent: 'FakeAgent'; > cookieAt: 'something' put: '123'; > parameterAt: 'q' put: 'smalltalk'; > onFailure: [ :error | self inform: 'failed' ]; > onProgress: [ :status | ... ]; > get > > Lukas > This is actually where I'd like to head with the client API. I had started my own HTTP client about 2 days before Sven announced Zinc, so it made more sense contribute to his project. My initial work was a subclass off of ProtocolClient and was kind of monolithic, so my first steps have been to make things mesh nicely with Zinc. My initial prototype before I started working on Zinc had a very similar API to your example, so my thoughts are definitely aimed for that direction. Matt

Oct. 1, 2010

[Pharo-project] [update 1.2] #12163

by StÃ©phane Ducasse

12163 ----- - Issue 3035: Workspace(Object)>>doesNotUnderstand: #spawn:. Thanks mariano Martinez-Peck - Issue 3032: Memory consuption of Objects. Thanks mariano Martinez-Peck - Issue 3037: SpaceTally should use #instancesSizeInMemory. Thanks mariano Martinez-Peck

Oct. 1, 2010

Re: [Pharo-project] [squeak-dev] Multiple finalizers per single object

by Henrik Johansen

I sort of disagree, in that it's neat to have a way for objects to be notified when other objects die, without that object necessarily having to know about all objects that may be interested in its death. (Like, in Leventes case which triggered their creation in the first place, objects which are weakly registered to one or more announcers) I don't really see the benefit in constraining an existing, flexible mechanic to only cover the common use case. If multiple finalizers are removed, at least so should Object>>toFinalizeSend:to:with: (and potentially other spots, I haven't checked exactly) leaving Object >> finalize as the only place where finalization actions take place. (Which is where the actions Igor are talking about should be happening in the first place) Cheers, Henry On Sep 23, 2010, at 10:36 27PM, Chris Muller wrote: > I agree that multiple finalizers per object seems unnecessary and, as > you pointed out, potentially confusing, if not also conflicting. > TSTTCPW seems appropriate in this case. > > On Thu, Sep 23, 2010 at 3:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hello, >> >> i'd like to raise this subject once more, because i don't like it (or >> don't understand?). >> >> In all scenarios, where i met the need to use finalization, a single >> finalizer is sufficient. >> Moreover, there is always a single object who controls a weak >> reference, and it never leaks it out, to prevent >> the case, when some other object may obtain a strong reference on it, >> making it permanently held in object memory. >> >> Multiple different finalizers for single object, from design point of >> view, means that you having two different, not related frameworks, >> which using same object, and want to do something when it dies. >> A scenario, where its possible and userful, still don't comes into my mind. >> In contrary, whenever i see a use of finalizers, its in most cases >> about graceful control over external resource, such as: >> - file >> - socket >> - external memory >> >> and i really don't see how multiple finalizers per single resource >> could do any good. >> >> Suppose one finalizer closing a file handle, while another one >> flushing it buffer cache. >> Now, how you going to ensure, that one finalizer will execute first, >> before another one? >> And what if third framework comes into play and wants to add another >> finalizer on top of that, which should do something in the middle >> between flushing a cache and closing file handle? >> >>> From the above, the only conclusion can be made: use a single >> finalizer, and put all logic & operation ordering into it. >> And also, prevent leakage of object pointer (such as file handle) >> outside of your model, otherwise it may cause harm. >> >> That's why i think a current WeakRegistry model provoking bad design practices. >> I think a better behavior would be to raise an error, if something >> wants to register finalizer twice for a single object. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2010

[Pharo-project] ToolBuilderTests>>testGetButtonSideEffects seems to be wrong

by Cyrille Delaunay

if you look at the code of ToolBuilderTests>>testGetButtonSideEffects: testGetButtonSideEffects self makeButton. queries := IdentitySet new. self changed: #testSignalWithNoDiscernableEffect. self expectedButtonSideEffects do:[:sym| self assert: (queries includes: sym). queries remove: sym. ]. .... the variable queries is never fill in, therefore I don't understand how the assertion could pass. In pharo 1.2-12159 the test fail for the class MorphicToolBuilderTests for which 'expectedButtonSideEffects' return a non-empty collection (unlike ToolBuilderTests). I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3038

Oct. 1, 2010

[Pharo-project] [update 1.2] #12162

by StÃ©phane Ducasse

12162 ----- Issue 2713: Changelist deserves some fixes Issue 3030: Remove Explain... code (again) Issue 3023: change the initial windows position strategy Issue 3028: PluggableListMorphByItem >> getCurrentSelectionIndex access directly a non-initailized instance variable Stef

Oct. 1, 2010

[Pharo-project] Issue 3036: SUnit Refactoring

by Sean P. DeNigris

In the course of working through A Mentoring Course on Smalltalk, I applied some small refactorings to SUnit. Issue: http://code.google.com/p/pharo/issues/detail?id=3036 Fix in inbox: SUnit-SeanDeNigris.114 * TestCase now uses class>>suiteClass instead of referencing the class name directly * TestSuite now uses #resultClass instead of referencing the class name directly Also, 114 is a merge of SUnit-StephaneDucasse.113 and SUnit-SeanDeNigris.106 (a package saved in my local cache). Should I upload SUnit-SeanDeNigris.106 also? Thanks. Sean -- View this message in context: http://forum.world.st/Issue-3036-SUnit-Refactoring-tp2914375p2914375.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 1, 2010

Re: [Pharo-project] [update 1.2] #12161 - #12172

by Igor Stasenko

2010/10/1 Levente Uzonyi <leves(a)elte.hu>: > On Fri, 1 Oct 2010, Igor Stasenko wrote: > >> On 1 October 2010 16:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> Igor >> >> I was thinking to rollback now because we cannot do anything. >> Is is ok for you? >> And after we can include everything. >> > > Sure, no problem. It should not behave like that. > There could be some very little speed degradation, but not like you > describing. > > I found that after update 12172->12174 > a FinalizationDependents in WeakArray > held 4 weak registries before, > but after update it also holds a WeakIdentityKeyDictionary with 9387 > elements. > > This is something from monticello cache, but it screwed somehow.. > I were able to delete it from weakdependents,manually, Â like in this script: > > arr := (WeakArray classPool at: #FinalizationDependents ). > arr > withIndexDo: [:e :i | > Â Â Â Â e class == WeakRegistry ifFalse: [ arr at: i put: nil > Â Â Â Â ]] > > After that, everything vent back to normal. > > This dictionary comes from MCMethodDefinition Definitions class var. > So you can simply do: > > MCMethodDefinition shutDown > > to stop CPU hogging. > > But i wonder, if this is just one-time issue, or it will repeat again, > after update. > > During writing this, i found that you already rewinded update, so i > was unable to check if > it will start consuming CPU on new code loaded, or its just some > tension between MC and > my migration procedure, which can be healed by > MCMethodDefinition shutDown. > > > IIRC the WeakKeyDictionary is Pharo doesn't work (doesn't free slots or so) > if it's not registered to the finalization process, but Henrik will correct > me if I'm wrong. > It marks associations whose keys became nil as expired ones (association key: association). So, then associations get reused when new entries added. But i tricked myself by using #allAssociationsDo: , which were wiping out associations, before sending #finalize to their values... so, no finalization were run. Somehow, this lead to blowing up an MC method definitions cache. > > Levente > >> Stef >> >> On Oct 1, 2010, at 3:08 PM, Igor Stasenko wrote: >> >>> On 1 October 2010 15:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> >>>> Igor >>>> Can you have a look because right now in 12174 I cannot >>>> do any update anymore so >>>> Â Â Â Â - either we fix it now >>>> Â Â Â Â or we have to rollbakc to 12161. >>>> >>> I will take a look >>>> >>>> Thanks. >>>> >>>> >>>> On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: >>>> >>>>> 2010/10/1 Levente Uzonyi <leves(a)elte.hu>: >>>>>> >>>>>> On Fri, 1 Oct 2010, Igor Stasenko wrote: >>>>>> >>>>>>> On 1 October 2010 12:06, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>>>> On Fri, 1 Oct 2010, Marcus Denker wrote: >>>>>>> >>>>>>>> Issue 3002: Â Â A new finalization code ready for integration in >>>>>>>> Pharo >>>>>>>> Issue 3026: after 12172, sync with repository and reload >>>>>>> >>>>>>> If you didn't fix the migration code, then WeakFinalizationRegistry >>>>>>> is >>>>>>> still >>>>>>> in the system. Details here: >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/15400… >>>>>>> >>>>>> You mean this not work: >>>>>> Â Â Â Â Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. >>>>>> >>>>>> should be >>>>>> Â Â Â Â Smalltalk forgetClass: WeakFinalizationRegistry logged: false. >>>>>> >>>>>> right? >>>>>> >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>> Thanks for noticing. >>>>> >>>>>> Levente >>>>>> >>>>>>> >>>>>>> Levente >>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Marcus Denker Â -- http://www.marcusdenker.de >>>>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010