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

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

by StÃ©phane Ducasse

+ 10000000000000000000000 > 2009/7/17 John Escobedo <letmeshowyou(a)gmail.com>: >> 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? >> > Smalltalk inspect - gives you all the globals :) > And to remove, as in any dictionary , use: > Smalltalk removeKey: #MyGlobal > but beware, if your global is a class, you'd better remove it using > tools (or specialized method for removing classes). > > My personal advice (or take it as a opinion) : > - NEVER USE any globals except from class names. > - try to avoid referencing "uncommon" globals directly in methods. > Better create an accessor method to it, and put a reference in there, > and then use this accessor in the rest of your methods. In this way, > if you would want to get rid of it, rename it, or refactor it - you > will know that all you need to do is to change a single method, rather > than 100000 of methods, which referencing this global. > > >> - John >> >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 17, 2009

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

by StÃ©phane Ducasse

Thanks Stef On Jul 17, 2009, at 12:29 AM, Douglas Brebner wrote: > 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. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 17, 2009

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

by StÃ©phane Ducasse

David may be you should try to use Moose (still a bit shaky) we will start to work on making it useable by others. Porting the code from VW and changing the source code meta model took us some time. but we do all the code analysis and after you a meta model of the code (with access, invocation....) and you can script mondrian to try it: ScriptLoader loadOB MooseLoader (in Moose squeaksource repository) MooseLoader load Stef On Jul 16, 2009, at 11:44 PM, David Goehrig wrote: > > > 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/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 17, 2009

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

by StÃ©phane Ducasse

>> >> 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! I think that we are doing that since Squeak 3.7 so we get used to and making progress

July 17, 2009

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

by Adrian Lienhard

Can you elaborate on what is slow? Is this only Pharo or also Squeak? Adrian On Jul 17, 2009, at 01:07 , Douglas Brebner wrote: > 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 :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 17, 2009

Re: [Pharo-project] default setting for Squeak-dev

by Damien Cassou

On Tue, Jul 14, 2009 at 2:53 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > could you bench if the browser is faster when you disable the dynamic > protocol? I can't feel any difference. If you want to do benchmarks, just disable them in the preferences browser. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

July 17, 2009

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

by Igor Stasenko

2009/7/17 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > John, > > As Sig already said, globals should be used sparingly. Â You should read about workspace variables. Â Personally, I can't stand them, but others like them and you might too. Â You can also define temporaries in a workspace, something like > > | mySquare | > mySquare := Morph new. > ... > > The problem (or feature, depending on your perspective) is that mySquare will go away as soon as the expressions are evaluated, unless you inspect it or otherwise take steps to keep it around. Â Workspace variables will stick around, which is why they end up irritating me. Â I also do not like the implicit definition of them; it's easy to slip spelling, and instead of getting a syntax error, you get broken code, which is the _real_ reason I do not like them. > yeah.. implicit temps - this is what i disabling at first place when using workspaces. IMO, it is very error prone feature. > Welcome to Smalltalk, and to the list. Â Enjoy! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Escobedo > Sent: Thursday, July 16, 2009 7:22 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Where declared global reside... how can they be removed? > > 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 > > _______________________________________________ > 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.

July 17, 2009

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

by Schwab,Wilhelm K

John, As Sig already said, globals should be used sparingly. You should read about workspace variables. Personally, I can't stand them, but others like them and you might too. You can also define temporaries in a workspace, something like | mySquare | mySquare := Morph new. ... The problem (or feature, depending on your perspective) is that mySquare will go away as soon as the expressions are evaluated, unless you inspect it or otherwise take steps to keep it around. Workspace variables will stick around, which is why they end up irritating me. I also do not like the implicit definition of them; it's easy to slip spelling, and instead of getting a syntax error, you get broken code, which is the _real_ reason I do not like them. Welcome to Smalltalk, and to the list. Enjoy! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Escobedo Sent: Thursday, July 16, 2009 7:22 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Where declared global reside... how can they be removed? 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 17, 2009

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

by Igor Stasenko

And few things about playing with morphs. Rather than doing this in workspace (and therefore inventing a ways how to get a reference to your morph), i think you'd better to do that in morph's inspector: Morph new inspect; openInWorld now, after you Doit the above, you'll have a new morph on screen and its inspector opened. In inspector's lower pane you can send any messages to morph using 'self' i.e.: instead of: MySquare color: Color yellow in workspace, write: self color: Color yellow in inspector. 2009/7/17 Igor Stasenko <siguctua(a)gmail.com>: > 2009/7/17 John Escobedo <letmeshowyou(a)gmail.com>: >> 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? >> > Smalltalk inspect - gives you all the globals :) > And to remove, as in any dictionary , use: > Smalltalk removeKey: #MyGlobal > but beware, if your global is a class, you'd better remove it using > tools (or specialized method for removing classes). > > My personal advice (or take it as a opinion) : > - NEVER USE any globals except from class names. > - try to avoid referencing "uncommon" globals directly in methods. > Better create an accessor method to it, and put a reference in there, > and then use this accessor in the rest of your methods. In this way, > if you would want to get rid of it, rename it, or refactor it - you > will know that all you need to do is to change a single method, rather > than 100000 of methods, which referencing this global. > > >> - John >> >> _______________________________________________ >> 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. > -- Best regards, Igor Stasenko AKA sig.

July 17, 2009

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

by Igor Stasenko

2009/7/17 John Escobedo <letmeshowyou(a)gmail.com>: > 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? > Smalltalk inspect - gives you all the globals :) And to remove, as in any dictionary , use: Smalltalk removeKey: #MyGlobal but beware, if your global is a class, you'd better remove it using tools (or specialized method for removing classes). My personal advice (or take it as a opinion) : - NEVER USE any globals except from class names. - try to avoid referencing "uncommon" globals directly in methods. Better create an accessor method to it, and put a reference in there, and then use this accessor in the rest of your methods. In this way, if you would want to get rid of it, rename it, or refactor it - you will know that all you need to do is to change a single method, rather than 100000 of methods, which referencing this global. > - John > > _______________________________________________ > 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.

July 17, 2009