- Pharo-dev - lists.pharo.org

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