July 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Call for testers of a faster MC

by StÃ©phane Ducasse

thanks mariano and kirtai. On Jul 16, 2009, at 10:39 PM, Mariano Martinez Peck wrote: > Stef....Kirtai was looking you in IRC > > [16:39] <Kirtai> is stephanes problem with loading mc due to non- > atomicloading changing a method then using it before another method > it depends on is compiled? > [17:06] <marianopeck> Kirtai: stef isn't in IRC most of the time > [17:07] <marianopeck> it would be better to send him an email > [17:07] <Kirtai> I'm just lookin at the problem > [17:07] <Kirtai> seems that MCMethodDefinition>>actualClass is > calling MCMethodDefinition>>actualClassIn: after actualClass is > recompiled but before actualClassIn: is installed argh! > > > Mariano > > On Thu, Jul 16, 2009 at 7:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > apparently the UI gets stuck during the cleaning phase when I try to > load moose :( > > On Jul 16, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: > > > Hi guys > > > > thanks to matthew I finally understood his optimization. > > The entry point is MCPackage>>snapshot > > > > I published a slice in the inbox. > > If you can try it, look at the changes and let me know. > > > > I did some experiences and could load moose which start to be > complex > > but I may have done some mistakes. > > > > Stef > > > > PS: having real package will really make all that much faster. > > I will regularly to the TaskForces the code for a new package class. > > > > _______________________________________________ > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] Call for testers of a faster MC

by Mariano Martinez Peck

Stef....Kirtai was looking you in IRC [16:39] <Kirtai> is stephanes problem with loading mc due to non-atomicloading changing a method then using it before another method it depends on is compiled? [17:06] <marianopeck> Kirtai: stef isn't in IRC most of the time [17:07] <marianopeck> it would be better to send him an email [17:07] <Kirtai> I'm just lookin at the problem [17:07] <Kirtai> seems that MCMethodDefinition>>actualClass is calling MCMethodDefinition>>actualClassIn: after actualClass is recompiled but before actualClassIn: is installed Mariano On Thu, Jul 16, 2009 at 7:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > apparently the UI gets stuck during the cleaning phase when I try to > load moose :( > > On Jul 16, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: > > > Hi guys > > > > thanks to matthew I finally understood his optimization. > > The entry point is MCPackage>>snapshot > > > > I published a slice in the inbox. > > If you can try it, look at the changes and let me know. > > > > I did some experiences and could load moose which start to be complex > > but I may have done some mistakes. > > > > Stef > > > > PS: having real package will really make all that much faster. > > I will regularly to the TaskForces the code for a new package class. > > > > _______________________________________________ > > 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 >

July 16, 2009

Re: [Pharo-project] KnownLands: a Class dependency explorer

by StÃ©phane Ducasse

Hi david > Hey Pharoers, > > I've been working on a little project for the past couple days, and > now that I have something of a tangible result, I'm going to share > the first screen grab. > > What I've been working on is a visualization tool for analyzing the > relationships between Classes and the contents of their > CompiledMethods. Cool. BTW if you want to experiment with other visualization you also have mondrian which starts to work well on pharo. > > In the attached screen shot, the TPureBehavior circle in the middle > is the root node, and all of the radial nodes are Classes referred > to by the CompiledMethods associated with TPureBehavior. Each of > these classes is bound to a literal in one of the CompiledMethods. > The radius of the circle is directly proportional to the number of > methods that Class has. IdentitySet has 2 compiled methods for > example, whereas ChangeSet has 124 methods. > > Once I get collapsing working, and add some trace lines (so that > when you've expanded and expanded and expanded it is obvious who is > connected to who), I'll post this code somewhere. But what is > incredible is how quickly things get really really deeply > interconnected things get. Yes! What is the direction of the dependency The circle in the middle has literal reference to the other that surround it? because in that case it would be interesting to investigate why there is reference to RBParser Do you take into account extensions? We want to apply a dependency structural matrix on the complete pharo image to also get an idea of the cyclic dependencies. After when I looked at the collaborators of Behavior I do not see a bad guy for now. > > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] Call for testers of a faster MC

by StÃ©phane Ducasse

apparently the UI gets stuck during the cleaning phase when I try to load moose :( On Jul 16, 2009, at 8:49 PM, StÃ©phane Ducasse wrote: > Hi guys > > thanks to matthew I finally understood his optimization. > The entry point is MCPackage>>snapshot > > I published a slice in the inbox. > If you can try it, look at the changes and let me know. > > I did some experiences and could load moose which start to be complex > but I may have done some mistakes. > > Stef > > PS: having real package will really make all that much faster. > I will regularly to the TaskForces the code for a new package class. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 16, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Schwab,Wilhelm K

Nicolas, One thing I forgot to mention: thread safety??? IIRC, Dolphin triggers startup events, and all external resources clear pointers then (though they will release on shutdown, not image saving) to force a lazy connection. I see why, absent help from the vm, the image does not know when it starts and stops. What I do not get is why the vm does not tell it. If it did, I _think_ we could clean all of this up. Sometimes the truth hurts though, so please find any faults in my logic (or lack thereof). Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Thursday, July 16, 2009 3:11 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? Yes, it would require a small vm change to fork. To be more accurate here's a simplified draft of my proposition: The fork has one bit different, so let it be a prilmitive returning true or false: primFork "return true if we are in the forked image, false in the original" <primitive: XXX> snapshot self primFork ifTrue: [ self aboutToSnapshot. self primSaveAndQuit. self returnFromSnapshot]. Nicolas 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > I'm all for doing this better, and have watched for a while as (it appears to me at least) Squeak got ever closer to having formal startup and shutdown code. Â However, the idea that Squeak "just runs" persists, perhaps for the good. Â It strikes me that we can do better, but it would require image and vm changes. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Nicolas Cellier > Sent: Thursday, July 16, 2009 2:10 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? > > Does that really has to be so ? > An alternative would be to clone the process (fork) and do a snapshotAndQuit in the clone. > > Nicolas > > 2009/7/16 Lukas Renggli <renggli(a)gmail.com>: >>>Â These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. >> >> It is correct that these scripts are run after a snapshot, because >> when the image is saved it has to be shutdown so that it can come up >> correctly again. I guess Dolphin works exactly the same. The problem >> in Pharo/Squeak is that some of shutdown and startup scripts might >> not really be necessary to run in the case of a save without quit, so >> feel free to submit optimizations in this area. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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

July 16, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Nicolas Cellier

Yes, it would require a small vm change to fork. To be more accurate here's a simplified draft of my proposition: The fork has one bit different, so let it be a prilmitive returning true or false: primFork "return true if we are in the forked image, false in the original" <primitive: XXX> snapshot self primFork ifTrue: [ self aboutToSnapshot. self primSaveAndQuit. self returnFromSnapshot]. Nicolas 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > I'm all for doing this better, and have watched for a while as (it appears to me at least) Squeak got ever closer to having formal startup and shutdown code. Â However, the idea that Squeak "just runs" persists, perhaps for the good. Â It strikes me that we can do better, but it would require image and vm changes. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > Sent: Thursday, July 16, 2009 2:10 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? > > Does that really has to be so ? > An alternative would be to clone the process (fork) and do a snapshotAndQuit in the clone. > > Nicolas > > 2009/7/16 Lukas Renggli <renggli(a)gmail.com>: >>>Â These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. >> >> It is correct that these scripts are run after a snapshot, because >> when the image is saved it has to be shutdown so that it can come up >> correctly again. I guess Dolphin works exactly the same. The problem >> in Pharo/Squeak is that some of shutdown and startup scripts might not >> really be necessary to run in the case of a save without quit, so feel >> free to submit optimizations in this area. >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 16, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Schwab,Wilhelm K

Nicolas, I'm all for doing this better, and have watched for a while as (it appears to me at least) Squeak got ever closer to having formal startup and shutdown code. However, the idea that Squeak "just runs" persists, perhaps for the good. It strikes me that we can do better, but it would require image and vm changes. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Thursday, July 16, 2009 2:10 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Save and quit vs. Save - a clue to performance??? Does that really has to be so ? An alternative would be to clone the process (fork) and do a snapshotAndQuit in the clone. Nicolas 2009/7/16 Lukas Renggli <renggli(a)gmail.com>: >>Â These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. > > It is correct that these scripts are run after a snapshot, because > when the image is saved it has to be shutdown so that it can come up > correctly again. I guess Dolphin works exactly the same. The problem > in Pharo/Squeak is that some of shutdown and startup scripts might not > really be necessary to run in the case of a save without quit, so feel > free to submit optimizations in this area. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > 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

July 16, 2009

Re: [Pharo-project] Save and quit vs. Save - a clue to performance???

by Nicolas Cellier

Does that really has to be so ? An alternative would be to clone the process (fork) and do a snapshotAndQuit in the clone. Nicolas 2009/7/16 Lukas Renggli <renggli(a)gmail.com>: >>Â These things happen when they should, and do not happen when they should not, as apparently is the case for Squeak/Pharo. > > It is correct that these scripts are run after a snapshot, because > when the image is saved it has to be shutdown so that it can come up > correctly again. I guess Dolphin works exactly the same. The problem > in Pharo/Squeak is that some of shutdown and startup scripts might not > really be necessary to run in the case of a save without quit, so feel > free to submit optimizations in this area. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 16, 2009

[Pharo-project] KnownLands: a Class dependency explorer

by David Goehrig

Hey Pharoers, I've been working on a little project for the past couple days, and now that I have something of a tangible result, I'm going to share the first screen grab. What I've been working on is a visualization tool for analyzing the relationships between Classes and the contents of their CompiledMethods. In the attached screen shot, the TPureBehavior circle in the middle is the root node, and all of the radial nodes are Classes referred to by the CompiledMethods associated with TPureBehavior. Each of these classes is bound to a literal in one of the CompiledMethods. The radius of the circle is directly proportional to the number of methods that Class has. IdentitySet has 2 compiled methods for example, whereas ChangeSet has 124 methods. Once I get collapsing working, and add some trace lines (so that when you've expanded and expanded and expanded it is obvious who is connected to who), I'll post this code somewhere. But what is incredible is how quickly things get really really deeply interconnected things get. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 16, 2009

[Pharo-project] Date formatting - Chronos, other?

by Schwab,Wilhelm K

Hello all, What is the best option for converting dates to text and vise versa? Is Chronos the right choice? Bill

July 16, 2009