- Pharo-dev - lists.pharo.org

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

by David Goehrig

On Thu, Jul 16, 2009 at 4:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi david > > Cool. > BTW if you want to experiment with other visualization you also have > mondrian which starts to work well on pharo. For some reason it doesn't load in any of my images, but I think that has more to do more with my images being highly non-standard for other reasons. > > Yes! What is the direction of the dependency > The circle in the middle has literal reference to the other that > surround it? Yes. The idea is each circle's represents the number of methods that class has defined in itself (not through inheritance). I then walk through all of the literals and look for variable bindings that refer to a top level class defined in the Smalltalk SystemDictionary. They're arrayed around the one you're currently inspecting in a circle for now. > because in that case it would be interesting to investigate why there > is reference to RBParser Well specifically.. RBParser is there due to this comment in the code of my image: parseTreeFor: aSymbol self flag: #FIXME. "UGLY hack for beeing able to share AST package with Persephone... this needs to be fixed later". Smalltalk at: #ReflectiveMethod ifPresent: [:cls | | method | method := self compiledMethodAt: aSymbol. method hasReflectiveMethod ifTrue: [^method reflectiveMethod methodNode]. ]. ^RBParser parseMethod: (self sourceCodeAt: aSymbol) onError: [:aString :pos | ^nil] I don't know if anyone has already taken care of that, my image is based on an older Pharo image. > Do you take into account extensions? > There's a lot of things I'm not taking into account right now. For the time being I'm inspecting the inside of CompiledMethods, and tracking what's getting compiled into them. Anything that affects compilation will be displayed. I'm not terribly interested in doing any source analysis :) > We want to apply a dependency structural matrix on the complete pharo image > to also get an idea of the cyclic > dependencies. I get the feeling playing around with this right now that there are quite a few. Array <-> Compiler are cyclic. String <-> Time are cyclic. Actually the whole Time, TimeAndDate, Date, Duration mess is one giant clusterf*ck. After when I looked at the collaborators of Behavior I do not see a > bad guy for now. I've got few more images up on my blog with my off the cuff impressions of what is going on. http://blog.dloh.org/2009/07/visualizing-squeak.html Hopefully tomorrow I'll find some time to polish off the method <-> class linking code, and polish it up enough that other people could import it into their images and start playing. I'm currently relying on a few language extensions in my image that aren't suitable for general consumption. ( like implicit symbols, super-overloaded comma, and default DNU returns nil). -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

July 16, 2009

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

by Nicolas Cellier

Current policy is to cleanup before saving, and reconnect after saving as if a fresh startup occured As you seem to suggest, a possible alternative without using fork would be to: 1) distinguish whether this is a newly restarted image (primSnapshot returning true or false...) 2) perform all the clean-ups at startup if newly restarted image 3) rely on the process exit() to perform required resource clean-up in case we quit (or let a self aboutToQuit do some) Step 2) would deserve great care, any unprotected access to an uninitialized pointer of the old image would crash or trash memory... Nicolas 2009/7/16 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > 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 > > _______________________________________________ > 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

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