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

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

I just tried to update image with old cache: [ Utilities updateFromServer] timeToRun 397707 and without it: [ Utilities updateFromServer] timeToRun 347708 397707 / 347708 asFloat 1.143795943722894 so, roughly 14% of CPU time (about 50 seconds) wasted on scanning the cache at each GC. Of course this measure a bit dirty, because there a network activity involved . On 1 October 2010 20:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > Here the simple fix for it. > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

Re: [Pharo-project] [squeak-dev] Re: Help is now able to define where subbooks are placed

by Hannes Hirzel

Yes, this is very useful for me. Thank you Enrico and Thorsten! --Hannes On 10/1/10, Enrico Spinielli <enrico.spinielli(a)googlemail.com> wrote: > Torsten, > all thanks go to you for having thought/designed/implemented _and_ for > following HelpSystem up! > > Well done > Bye > Enrico > > On Fri, Oct 1, 2010 at 00:19, Torsten Bergmann <astares(a)gmx.de> wrote: >> Hi Enrico, >> >> found the time this evening to integrate your idea >> that custom help books should be able to define >> where subbooks should be placed/displayed: >> >> Â Â #pages >> Â Â Â ^(firstPage MyAppSubTutorial secondPage thirdPage) >> >> >> Just update your Squeak image to #10565 and you dont >> need to workaround this problem using a custom >> builder anymore. >> >> It is now also mentioned in the help systems help >> itself. See chapter "STEP 7 - TIPS AND TRICKS". >> >> I've also opened an issue together with the >> changeset for Pharo 1.2 so that it will be >> integrated in one of the next pharo updates. >> >> http://code.google.com/p/pharo/issues/detail?id=3022 >> >> Thanks for the idea and initial code! >> >> Bye >> T. >> -- >> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail >> > > > > -- > Enrico Spinielli > "Do Androids dream of electric sheep?"â Philip K. Dick > "Hear and forget; see and remember;do and understand."âMitchel Resnick > >

Oct. 1, 2010

Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1

by Bart Gauquie

Great, gave it a try, loaded my app I was developing, and the page rendering speed in Seaside has dropped from 15-20 msecs to 5-10 :-). And all my tests are green! keep them coming! Regards, Bart 2010/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo > 1.1 but based on PharoCore 1.1.1. The versions of the external packages is > the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has > integrated some fixes and the support for CogVM. This means that > Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For > CogVM we recommend to use the last binaries that can be found in > http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is > http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ > > This CogVM version fixes the problem with "Objects as methods", and thus, > all the #run:with:with are working. This means that tools like TestCoverage > and AutoTest are working correctly with CogVM. > > The link to the image is: > https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip > > Cheers > > Mariano > > _______________________________________________ > 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

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

Here the simple fix for it. -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

Re: [Pharo-project] Base64MimeConverterTest>>#testOnByteArray raise an error

by Pavel Krivanek

The problem is that when the method base64Encoded was moved, packages Collections and Network were marked as dirty but not the package MimeConverter so the new version was not sent to the repository. -- Pavel 2010/10/1 Cyrille Delaunay <cy.delaunay(a)gmail.com> > ByteArray >> base64Encoded is no longer defined in Pharo 1.2, but used in the test Base64MimeConverterTest>>#testOnByteArray. It raise a DNU message. > > I opened an Issue: > http://code.google.com/p/pharo/issues/detail?id=3027&q=base64Encoded&colspe… > > > > _______________________________________________ > 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

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

On 1 October 2010 20:05, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 1 Oct 2010, Igor Stasenko wrote: > >> I uploaded new changesets to >> http://code.google.com/p/pharo/issues/detail?id=3002 >> >> >> I tested applying them in Pharo-Core-#12159 >> and then updating an image after that. >> >> After update: >> MCMethodDefinition cachedDefinitions size is 18668 >> >> But image don't feels slow. >> >> As a side note, i recommend to review the MC caching mechanism towards >> avoiding putting so much load >> on finalization process (such as scanning 18k entries to find dead >> objects). >> >> This is actually the purpose of new finalization scheme: >> - it allows to avoid scanning whole weak dictionary in order to get >> rid of expired associations. > > WeakKeyDictionaries shouldn't be added to the finalization process at all. > In the current case there's no finalization action at all, so it's totally > pointless IMO. And these dictionaries are not thread-safe, so bad things can > happen if they are registered with the finalization process. > well..then we probably should fix this: MCMethodDefinition>>cachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions >> >> I'm already implemented a variant of self-cleaning weak dictionary for >> Magma, >> which using new finalization scheme, and avoids scanning huge number >> of entries to discover few of them, >> which became garbage. > > Squeak's WeakKeyDictionaries are self cleaning, though the there's no > guarantee that finalization action is performed when the key is GC'd. > it depends how badly you need to keep things clean as soon as its possible :) It is really not necessary to add cachedDefinitions to weakdependets and check them each time after GC. In case of MC, i think a dead-keys cleanup should be triggered only after package loading/unloading, but not during each GC. > > Levente > >> >> >> -- >> 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

Re: [Pharo-project] [Metacello] Re: loading groups with metacello

by Dale Henrichs

Mariano Martinez Peck wrote: > > > On Fri, Oct 1, 2010 at 2:16 PM, Veronica Isabel Uquillas Gomez > <vuquilla(a)vub.ac.be <mailto:vuquilla@vub.ac.be>> wrote: > > Hi Mariano, > > You already saw my problem. > > With this you can check what is happening: (ConfigurationOfGlamour > project version: 'default') record: #('Core' 'Tests' 'Extras') > > > I don't understand why this loads Grease for example. Dale any idea? > I checked loadDirective but I didn't understand. > > Cheers > > Mariano > > > all the pre-requisites are being loaded and not only the groups. > > > Regards, Veronica _______________________________________________ > Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Okay, Here's the printString of the loadDirectives: linear load : linear load : default [ConfigurationOfGlamour] load : ConfigurationOfGrease linear load : default [ConfigurationOfGlamour] load : ConfigurationOfMondrian atomic load : default [ConfigurationOfGlamour] load : Glamour-Announcements load : Glamour-Helpers load : Glamour-Core load : Glamour-Presentations load : Glamour-Browsers load : Glamour-Tests-Core load : Glamour-Morphic-Theme load : Glamour-Examples load : Glamour-Tools linear load : default [ConfigurationOfMondrian] load : ConfigurationOfHealthReportProducer linear load : default [ConfigurationOfMondrian] load : ConfigurationOfProfStef atomic load : default [ConfigurationOfMondrian] linear load : 1.3 [ConfigurationOfProfStef] load : ConfigurationOfShout linear load : 1.3 [ConfigurationOfProfStef] linear load : 1.1.1 [ConfigurationOfShout] load : Shout-lr.90 load : ShoutWorkspace.pharo-1-1-SeanDeNigris.6 load : ProfStef-Core-LaurentLaffont.11 load : ProfStefBrowser-LaurentLaffont.26 load : ProfStef-Tests-LaurentLaffont.8 load : ProfStef-Help-LaurentLaffont.1 load : Mondrian load : CollectionExtensions atomic load : 0.1-baseline [ConfigurationOfHealthReportProducer] load : HealthReportProducer load : Glamour-Scripting linear load : 1.0-alpha9.1 [ConfigurationOfGrease] load : ConfigurationOfRefactoringBrowser linear load : 1.0-alpha9.1 [ConfigurationOfGrease] load : Grease-Core-lr.37 load : Grease-Pharo-Core-jok.18 linear load : 1.3 [ConfigurationOfRefactoringBrowser] load : AST-Core-lr.73 load : Refactoring-Core-lr.136 load : Grease-Slime-jok.5 load : Magritte-Model load : Magritte-Morph load : Glamour-Morphic-Renderer load : Glamour-Tests-Morphic and here's the section related to Grease (very end of directives): load : Glamour-Scripting linear load : 1.0-alpha9.1 [ConfigurationOfGrease] load : ConfigurationOfRefactoringBrowser linear load : 1.0-alpha9.1 [ConfigurationOfGrease] load : Grease-Core-lr.37 load : Grease-Pharo-Core-jok.18 linear load : 1.3 [ConfigurationOfRefactoringBrowser] load : AST-Core-lr.73 load : Refactoring-Core-lr.136 load : Grease-Slime-jok.5 load : Magritte-Model load : Magritte-Morph load : Glamour-Morphic-Renderer load : Glamour-Tests-Morphic The load directive is in "load order" which is "reverse prerequisite order". In other words, the clue for why Grease is loaded lies in the directives _following_ the Grease directives... In this case Magritte-Model immediately follows the loading of Grease implying that Magritte-Model, requires Grease (and then confirmed by looking at the configuration) Reading on: Magritte-Morph requires Magritte-Model, Glamour-Morphic-Renderer requires Magritte-Morph and Glamour-Tests-Morphic requires Glamour-Morphic-Renderer. From the configuration, Glamour-Tests-Morphic is a member of Tests and Tests is being loaded (or recorded in this case). Does this help? Note that ConfigurationOfGlamour is not using ConfigurationOfMagritte2. I think that is because of problems with earlier versions of the CofigurationOfMagritte2, when seaside30 was loaded when you tried to load Magritte. The latest ConfigurationOfMagritte2 doesn't have that problem anymore, Glamour could be using ConfigurationOfMagritte2 now. Dale

Oct. 1, 2010

Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Levente Uzonyi

On Fri, 1 Oct 2010, Igor Stasenko wrote: > I uploaded new changesets to > http://code.google.com/p/pharo/issues/detail?id=3002 > > > I tested applying them in Pharo-Core-#12159 > and then updating an image after that. > > After update: > MCMethodDefinition cachedDefinitions size is 18668 > > But image don't feels slow. > > As a side note, i recommend to review the MC caching mechanism towards > avoiding putting so much load > on finalization process (such as scanning 18k entries to find dead objects). > > This is actually the purpose of new finalization scheme: > - it allows to avoid scanning whole weak dictionary in order to get > rid of expired associations. WeakKeyDictionaries shouldn't be added to the finalization process at all. In the current case there's no finalization action at all, so it's totally pointless IMO. And these dictionaries are not thread-safe, so bad things can happen if they are registered with the finalization process. > > I'm already implemented a variant of self-cleaning weak dictionary for Magma, > which using new finalization scheme, and avoids scanning huge number > of entries to discover few of them, > which became garbage. Squeak's WeakKeyDictionaries are self cleaning, though the there's no guarantee that finalization action is performed when the key is GC'd. Levente > > > -- > 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] Issue 3047: REFACTOR: Added intention revealing helper method to AppRegistry class>>register:

by Sean P. DeNigris

http://code.google.com/p/pharo/issues/detail?id=3047 Old: register: aProviderClass ... default := nil. "so it'll ask for a new default..." ... New: ... self askForNewDefaultOnNextRequest. ... Fix in inbox: System-Applications-SeanDeNigris.15 -- View this message in context: http://forum.world.st/Issue-3047-REFACTOR-Added-intention-revealing-helper-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 1, 2010

[Pharo-project] Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph

by Sean P. DeNigris

http://code.google.com/p/pharo/issues/detail?id=3046 Fix in inbox: Morphic-SeanDeNigris.625 LineMorph class>>from:to:color:width: changed to return a LineMorph Sean -- View this message in context: http://forum.world.st/Issue-3046-BUG-LineMorph-class-from-to-color-width-re… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 1, 2010

[Pharo-project] Issue 3045: DOCUMENTATION: Added comment to RBMethodNode>>methodComments

by Sean P. DeNigris

Added comment to RBMethodNode>>methodComments indicating that what gets returned is a collection of index intervals, not the actual comment strings http://code.google.com/p/pharo/issues/detail?id=3045 Fix in Inbox: AST-Core-SeanDeNigris.80 -- View this message in context: http://forum.world.st/Issue-3045-DOCUMENTATION-Added-comment-to-RBMethodNod… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 1, 2010

[Pharo-project] Issue 3044: Method editor failing

by NicolÃ¡s Paez

*http://code.google.com/p/pharo/issues/detail?id=3044* *Steps to reproduce:* 1. Create a method 2. Declare a temp (i.e. myVariable) 3. Write some code sending a message to a non-existing temp with a name similar to the one you declared (i.e. myVar) 4. Try to save. You should get a suggestion to change myVar -> myVariable. 5. Accept the suggestion 6. Your code will be modify in a wrong way: intead of getting "myVariable" you will get "myVariableiable" Saludos! Nico. blog: nicopaez.wordpress.com

Oct. 1, 2010

[Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)

by Igor Stasenko

I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002 I tested applying them in Pharo-Core-#12159 and then updating an image after that. After update: MCMethodDefinition cachedDefinitions size is 18668 But image don't feels slow. As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects). This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations. I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage. -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

[Pharo-project] [update 1.2] #12166

by StÃ©phane Ducasse

12166 ----- Issue 2943: SUnit 4. Thanks Jannik Laval and Nicolas Anquetil

Oct. 1, 2010

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

by Igor Stasenko

Here what happens: Original method WeakKeyDictionary>>finalizeValues WeakKeyDictionary>>finalizeValues "Clear all associations with nil keys" array do:[:assoc| 1 to: array size do:[:i | | assoc | assoc := array at: i. assoc ifNotNil:[ assoc expire ifTrue:[ expired := expired + 1. tally := tally - 1. ]. ]. ]. And i noticed that after recompilation of this method, it starts spending much more time to scan 14k entries: [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun 167 (my guess that this method was never recompiled with new Eliot's closures). Now, if i change it to: finalizeValues "Clear all associations with nil keys" 1 to: array size do:[:i | | assoc | assoc := array at: i. array do:[:assoc| assoc ifNotNil:[ assoc expire ifTrue:[ expired := expired + 1. tally := tally - 1. ]. ]. ]. so, #to:do: is inlined by compiler, then numbers is much better: [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun 4 Just try it yourself, if you not believe. -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2010

[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