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

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

by Douglas Brebner

Keith Hodges wrote: > Stef if you want to load the source code direct from an mcz, Installer > can do it as in the following example. > > scriptUpgradeMonticelloBootstrap > > (Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base') > fileInSource. > (Installer url: > 'http://www.squeaksource.com/mc/System-PasswordManager') fileInSource. > (Installer url: 'http://www.squeaksource.com/mc/', self class > configMCVersion,'.mcz') fileInSource. > > This is available in Installer install: 'UpgradeMonticelloBootstrap'. > > Damien loads MC1.5 via... > > Installer install: 'LevelPlayingField' > > this doesnt include Installer-Launcher which causes the above problem. > > > I was able to load it in a 10379 image after upgrading Installer. Preferences enable: #allowBlockArgumentAssignment. Preferences disable: #raiseDepreciatedWarnings. Installer upgrade upgrade. Installer install: 'UpgradeMonticelloBootstrap'. Thanks to Keith :)

July 17, 2009

[Pharo-project] Where declared global reside... how can they be removed?

by John Escobedo

Hi everyone, I'm new to both Smalltalk and especially to Pharo (and this mailing list). I have a very basic question and would like to be directed to more info or a different mailing list if appropriate. For most tutorials (I'm using squeak tutorials), one does a lot of work in a workspace. If I make a new global variable such as: MySquare := Morph new ...once I define "MySquare" as a global variable I know I can send it many messages like: MySquare openInWorld MySquare color: Color yellow When I'm done and I close the workspace, save the image and save the image. When I open it again it will know what "MySquare" is known in any workspace. How do I remove "MySquare" and/or the associated object? How could I see or find other such global variables? - John

July 17, 2009

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

by Keith Hodges

StÃ©phane Ducasse wrote: > 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! > LPF files in the source first as a file in, then as an mc package Keith

July 17, 2009

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

by Keith Hodges

Douglas Brebner wrote: > Douglas Brebner wrote: > >> Stephane, if you set the following preferences >> raiseDepreciatedWarnings=disabled (causes problems due to the Author >> initials depreciation) >> allowBlockArgumentAssignment=enabled (Breaks a method called >> #unloadTraits. A convenience method that isn't used and isn't in the >> image after the install is finished) >> >> then you can load MC 1.5 (with updated Installer) by using Keiths LPF >> script. >> >> After setting the prefs, do the following: >> >> HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'. >> >> and it should just work. >> >> > I know it's bad form to reply to my own mail but there's minor breakage > in that ProjectLauncher>>#startUpAfterLogin throws a DNU by sending > #setupFlaps when you first click on the world after restarting the image. > > Stef if you want to load the source code direct from an mcz, Installer can do it as in the following example. scriptUpgradeMonticelloBootstrap (Installer url: 'http://www.squeaksource.com/mc/PackageInfo-Base') fileInSource. (Installer url: 'http://www.squeaksource.com/mc/System-PasswordManager') fileInSource. (Installer url: 'http://www.squeaksource.com/mc/', self class configMCVersion,'.mcz') fileInSource. This is available in Installer install: 'UpgradeMonticelloBootstrap'. Damien loads MC1.5 via... Installer install: 'LevelPlayingField' this doesnt include Installer-Launcher which causes the above problem. Keith

July 17, 2009

Re: [Pharo-project] Pharo-Dev/web Image slowness

by Douglas Brebner

StÃ©phane Ducasse wrote: > Ok we will fix that for 1.0 > right now we are not even in beta. > > As a minor point, running Pharo on a network drive is *horrifically* slow so don't do that :)

July 16, 2009

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

by Douglas Brebner

Douglas Brebner wrote: > Stephane, if you set the following preferences > raiseDepreciatedWarnings=disabled (causes problems due to the Author > initials depreciation) > allowBlockArgumentAssignment=enabled (Breaks a method called > #unloadTraits. A convenience method that isn't used and isn't in the > image after the install is finished) > > then you can load MC 1.5 (with updated Installer) by using Keiths LPF > script. > > After setting the prefs, do the following: > > HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'. > > and it should just work. > I know it's bad form to reply to my own mail but there's minor breakage in that ProjectLauncher>>#startUpAfterLogin throws a DNU by sending #setupFlaps when you first click on the world after restarting the image.

July 16, 2009

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

by Nicolas Cellier

2009/7/16 David Goehrig <dave(a)nexttolast.com>: > > 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). > Yeah, we have to find someone not caring too much for his shoes to kick these ball of mud! Nicolas

July 16, 2009

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

by Douglas Brebner

StÃ©phane Ducasse wrote: > 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! > Stephane, if you set the following preferences raiseDepreciatedWarnings=disabled (causes problems due to the Author initials depreciation) allowBlockArgumentAssignment=enabled (Breaks a method called #unloadTraits. A convenience method that isn't used and isn't in the image after the install is finished) then you can load MC 1.5 (with updated Installer) by using Keiths LPF script. After setting the prefs, do the following: HTTPSocket httpFileIn: 'ftp.squeak.org/3.11/scripts/LPF.st'. and it should just work.

July 16, 2009

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