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

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