June 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #12012

by StÃ©phane Ducasse

12012 ----- - Issue 2582: Rearrange World Menu - Issue 2069: Be able to load DummyUIManager in a Pharo image. Part One - Issue 2558: ScriptLoader could automatically fetch the latest update-list

June 22, 2010

Re: [Pharo-project] CogVM

by Laval Jannik

Thanks Levente, Now, I continue to try Cog, and I have different bugs: - graphical bug: someties, when I move a window, text disappears during the move. (I put a screenshot in attachement) - Metacello/Monticello bug: I cannot reproduce it easily. When I load my metacello Script (ConfigurationOfO2 and ConfigurationOfMoose for example), sometimes the VM crash. For information, I use the latest Pharo core (12011) with the cog changes integrated. Cheers, Jannik On Jun 22, 2010, at 08:49 , StÃ©phane Ducasse wrote: > Thanks levente > > http://code.google.com/p/pharo/issues/detail?id=2583 > > > On Jun 22, 2010, at 12:42 AM, Levente Uzonyi wrote: > >> On Mon, 21 Jun 2010, Laval Jannik wrote: >> >>> Hi all, >>> >>> I just try the new Cog VM, >>> I have a bug with MessageTally. >>> >>> You can reproduce it with: >>> "MessageTally spyOn:[1]" >>> >>> It does not understand "-". >>> Could someone reproduce it and have an idea to fix it ? >> >> It's easy to fix it, just replace code like this: >> >> SmalltalkImage current getVMParameters keysAndValuesDo: [ :idx :gcVal | >> gcStats at: idx put: (gcVal - (gcStats at: idx))]. >> >> with this: >> >> Smalltalk getVMParameters keysAndValuesDo: [ :idx :gcVal | >> gcVal ifNotNil: [ gcStats at: idx put: (gcVal - (gcStats at: idx)) ] ]. >> >> in MessageTally's #spyAllEvery:on:, #spyEvery:on: and #spyEvery:onProcess:forMilliseconds: (I think these are the same in Pharo and Squeak. If not, then just look at the senders of #getVMParameters). >> >> >> Levente >> >>> >>> Cheers, >>> Jannik >>> >>> On Jun 21, 2010, at 18:04 , Serge Stinckwich wrote: >>> >>>> On Mon, Jun 21, 2010 at 10:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> Some people asked me how I got Pharo to run on Cog on OS X. Here's how: >>>>> >>>>> 1. Download the Cog source-code from >>>>> <http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz>, open the Xcode >>>>> project CoreVM.xcodeproj, and compile the thing. For those who want to >>>>> skip this step I've put the resulting binaries here: >>>>> <http://www.lukas-renggli.ch/dropbox/cog-osx.zip>. >>>>> >>>>> 2. Open a (copy of a) Pharo image in an **old** VM and file-in the >>>>> appropriate change-set (there is one for Pharo 1.0 and one for Pharo >>>>> 1.1) from the following issue report: >>>>> <http://code.google.com/p/pharo/issues/detail?id=2579>. Save the image >>>>> and quit. >>>>> >>>>> 3. Open the image in the Cog VM. Note that if you safe the image, you >>>>> won't be able to open it again in a non-Cog VM. >>>>> >>>>> Hopefully John will provide a properly built binary soon :-) >>>> >>>> Thank you Lukas ! >>>> >>>> Quite impressive in some of my highly CPU-intensive robot simulations !!! >>>> Strange that the VM Cog icon is Croquet ;-) >>>> >>>> -- >>>> Serge Stinckwich >>>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>>> Every DSL ends up being Smalltalk >>>> http://doesnotunderstand.org/ >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> --- >>> Jannik Laval >>> >>> >>> _______________________________________________ >>> 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 --- Jannik Laval

June 22, 2010

Re: [Pharo-project] [update 1.1] #11401

by Adrian Lienhard

Thanks Laurent One thing that needs being adapted as well is the Mac host menu. Since it depends on the world menu structure it is broken now. Cheers, Adrian On Jun 22, 2010, at 08:55 , StÃ©phane Ducasse wrote: > 11401 > ----- > > - Issue 2582: Rearrange World Menu. Thanks Laurent. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 22, 2010

Re: [Pharo-project] Getting all senders of a CompiledMethod, best solution ?

by StÃ©phane Ducasse

> Thanks. Adding > > CompiledMethod>>allSenders > ^ SystemNavigation default allSendersOf: self selector not in compiled method but methodreference or in method method extensions with the package that contains SystemNavigation (probably better solution) Stef > > is OK too ? > > Laurent > > > Stef > > On Jun 22, 2010, at 8:10 AM, laurent laffont wrote: > > > Any hacker to start a code kata here ? :) > > > > Laurent > > > > On Fri, Jun 18, 2010 at 6:33 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > Hi, > > > > I have this method in AutotestFinder, I don't like it, someone has better code ? > > > > AutotestFinder>>allSendersOf: aCompiledMethod > > "Returns all senders as a collection of CompiledMethod" > > | methodReferences senders | > > methodReferences := (SystemNavigation default allSendersOf: aCompiledMethod selector). > > senders := methodReferences collect: > > [:aMethodReference | > > aMethodReference actualClass > > lookupSelector: aMethodReference selector]. > > ^ senders select: [:sender| sender isNil not]. "Why senders contains nil sometimes ?" > > > > What it does: > > > > AutotestFinder new allSendersOf: (ProfStef lookupSelector: #go) > > > > answers: > > > > an OrderedCollection((ProfStef>>#go "a CompiledMethod(10485760)") (ProtoObject>>#initialize "a CompiledMethod(326631424)") (ProfStef class>>#go "a CompiledMethod(49807360)") (ProfStef class>>#initialize "a CompiledMethod(1060634624)") (ProfStefBrowser class>>#menuCommandOn: "a CompiledMethod(340262912)") (ProfStefTestGo>>#testGoOpenSmalltalkSyntaxTutorial "a CompiledMethod(249823232)")) > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > _______________________________________________ > > 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

June 22, 2010

Re: [Pharo-project] Getting all senders of a CompiledMethod, best solution ?

by laurent laffont

On Tue, Jun 22, 2010 at 8:35 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > may be defining a method > aMethodReference actualClass lookupSelector: aMethodReference > selector > on methodReference would laready help > Thanks. Adding CompiledMethod>>allSenders ^ SystemNavigation default allSendersOf: self selector is OK too ? Laurent > > Stef > > On Jun 22, 2010, at 8:10 AM, laurent laffont wrote: > > > Any hacker to start a code kata here ? :) > > > > Laurent > > > > On Fri, Jun 18, 2010 at 6:33 PM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > > Hi, > > > > I have this method in AutotestFinder, I don't like it, someone has better > code ? > > > > AutotestFinder>>allSendersOf: aCompiledMethod > > "Returns all senders as a collection of CompiledMethod" > > | methodReferences senders | > > methodReferences := (SystemNavigation default allSendersOf: > aCompiledMethod selector). > > senders := methodReferences collect: > > [:aMethodReference | > > aMethodReference actualClass > > lookupSelector: > aMethodReference selector]. > > ^ senders select: [:sender| sender isNil not]. "Why senders > contains nil sometimes ?" > > > > What it does: > > > > AutotestFinder new allSendersOf: (ProfStef lookupSelector: #go) > > > > answers: > > > > an OrderedCollection((ProfStef>>#go "a CompiledMethod(10485760)") > (ProtoObject>>#initialize "a CompiledMethod(326631424)") (ProfStef > class>>#go "a CompiledMethod(49807360)") (ProfStef class>>#initialize "a > CompiledMethod(1060634624)") (ProfStefBrowser class>>#menuCommandOn: "a > CompiledMethod(340262912)") > (ProfStefTestGo>>#testGoOpenSmalltalkSyntaxTutorial "a > CompiledMethod(249823232)")) > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > _______________________________________________ > > 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 >

June 22, 2010

[Pharo-project] [update 1.1] #11401

by StÃ©phane Ducasse

11401 ----- - Issue 2582: Rearrange World Menu. Thanks Laurent. Stef

June 22, 2010

Re: [Pharo-project] CogVM

by StÃ©phane Ducasse

Thanks levente http://code.google.com/p/pharo/issues/detail?id=2583 On Jun 22, 2010, at 12:42 AM, Levente Uzonyi wrote: > On Mon, 21 Jun 2010, Laval Jannik wrote: > >> Hi all, >> >> I just try the new Cog VM, >> I have a bug with MessageTally. >> >> You can reproduce it with: >> "MessageTally spyOn:[1]" >> >> It does not understand "-". >> Could someone reproduce it and have an idea to fix it ? > > It's easy to fix it, just replace code like this: > > SmalltalkImage current getVMParameters keysAndValuesDo: [ :idx :gcVal | > gcStats at: idx put: (gcVal - (gcStats at: idx))]. > > with this: > > Smalltalk getVMParameters keysAndValuesDo: [ :idx :gcVal | > gcVal ifNotNil: [ gcStats at: idx put: (gcVal - (gcStats at: idx)) ] ]. > > in MessageTally's #spyAllEvery:on:, #spyEvery:on: and #spyEvery:onProcess:forMilliseconds: (I think these are the same in Pharo and Squeak. If not, then just look at the senders of #getVMParameters). > > > Levente > >> >> Cheers, >> Jannik >> >> On Jun 21, 2010, at 18:04 , Serge Stinckwich wrote: >> >>> On Mon, Jun 21, 2010 at 10:44 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> Some people asked me how I got Pharo to run on Cog on OS X. Here's how: >>>> >>>> 1. Download the Cog source-code from >>>> <http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz>, open the Xcode >>>> project CoreVM.xcodeproj, and compile the thing. For those who want to >>>> skip this step I've put the resulting binaries here: >>>> <http://www.lukas-renggli.ch/dropbox/cog-osx.zip>. >>>> >>>> 2. Open a (copy of a) Pharo image in an **old** VM and file-in the >>>> appropriate change-set (there is one for Pharo 1.0 and one for Pharo >>>> 1.1) from the following issue report: >>>> <http://code.google.com/p/pharo/issues/detail?id=2579>. Save the image >>>> and quit. >>>> >>>> 3. Open the image in the Cog VM. Note that if you safe the image, you >>>> won't be able to open it again in a non-Cog VM. >>>> >>>> Hopefully John will provide a properly built binary soon :-) >>> >>> Thank you Lukas ! >>> >>> Quite impressive in some of my highly CPU-intensive robot simulations !!! >>> Strange that the VM Cog icon is Croquet ;-) >>> >>> -- >>> Serge Stinckwich >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >>> Every DSL ends up being Smalltalk >>> http://doesnotunderstand.org/ >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> --- >> Jannik Laval >> >> >> _______________________________________________ >> 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

June 22, 2010

Re: [Pharo-project] Getting all senders of a CompiledMethod, best solution ?

by StÃ©phane Ducasse

may be defining a method aMethodReference actualClass lookupSelector: aMethodReference selector on methodReference would laready help Stef On Jun 22, 2010, at 8:10 AM, laurent laffont wrote: > Any hacker to start a code kata here ? :) > > Laurent > > On Fri, Jun 18, 2010 at 6:33 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Hi, > > I have this method in AutotestFinder, I don't like it, someone has better code ? > > AutotestFinder>>allSendersOf: aCompiledMethod > "Returns all senders as a collection of CompiledMethod" > | methodReferences senders | > methodReferences := (SystemNavigation default allSendersOf: aCompiledMethod selector). > senders := methodReferences collect: > [:aMethodReference | > aMethodReference actualClass > lookupSelector: aMethodReference selector]. > ^ senders select: [:sender| sender isNil not]. "Why senders contains nil sometimes ?" > > What it does: > > AutotestFinder new allSendersOf: (ProfStef lookupSelector: #go) > > answers: > > an OrderedCollection((ProfStef>>#go "a CompiledMethod(10485760)") (ProtoObject>>#initialize "a CompiledMethod(326631424)") (ProfStef class>>#go "a CompiledMethod(49807360)") (ProfStef class>>#initialize "a CompiledMethod(1060634624)") (ProfStefBrowser class>>#menuCommandOn: "a CompiledMethod(340262912)") (ProfStefTestGo>>#testGoOpenSmalltalkSyntaxTutorial "a CompiledMethod(249823232)")) > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 22, 2010

Re: [Pharo-project] Getting all senders of a CompiledMethod, best solution ?

by laurent laffont

Any hacker to start a code kata here ? :) Laurent On Fri, Jun 18, 2010 at 6:33 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > I have this method in AutotestFinder, I don't like it, someone has better > code ? > > AutotestFinder>>allSendersOf: aCompiledMethod > "Returns all senders as a collection of CompiledMethod" > | methodReferences senders | > methodReferences := (SystemNavigation default allSendersOf: aCompiledMethod > selector). > senders := methodReferences collect: > [:aMethodReference | > aMethodReference actualClass > lookupSelector: aMethodReference selector]. > ^ senders select: [:sender| sender isNil not]. "Why senders contains nil > sometimes ?" > > What it does: > > AutotestFinder new allSendersOf: (ProfStef lookupSelector: #go) > > answers: > > an OrderedCollection((ProfStef>>#go "a CompiledMethod(10485760)") > (ProtoObject>>#initialize "a CompiledMethod(326631424)") (ProfStef > class>>#go "a CompiledMethod(49807360)") (ProfStef class>>#initialize "a > CompiledMethod(1060634624)") (ProfStefBrowser class>>#menuCommandOn: "a > CompiledMethod(340262912)") > (ProfStefTestGo>>#testGoOpenSmalltalkSyntaxTutorial "a > CompiledMethod(249823232)")) > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ >

June 22, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Julian Fitzell

Sure, but the issue is not just figuring out which package to load. We have to either branch the packages or create several different packages which have overlapping code in them. Either way, this becomes increasingly complex from a development point of view (testing, merging, backporting, copying code between packages, and so on). As I said, it may be unavoidable, but I'm not looking forward to it. Julian On Mon, Jun 21, 2010 at 1:16 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Julian, > > I am very close to adding version specific attributes for Pharo1.0 and > Pharo1.1 to make this sort of specialization a little easier, but even now > an individual project can add fine-grained attributes that could allow code > to be conditional on a build by build basis ... if needed. > > Dale > > Julian Fitzell wrote: >> >> Hmm... Why did I only receive this email today...? >> >> Anyway, I agree that those methods should probably be in the >> platform-specific package. I guess we were originally trying to >> minimize the amount of implementation required on each platform. As >> long as no platform implements a method and the implementation is the >> same on all platforms, it is convenient to have it in only one place. >> As soon as a platform chooses to implement it, though, we will simply >> have to move it to the platform-specific package. At this point we run >> into the issue of having different platform packages for, say, Pharo >> 1.1 and 1.2. >> >> Perhaps in the end it is simpler just to keep extensions always in the >> platform packages and insist that the generic packages contain only >> GR* classes and grease* extension methods. >> >> I'm not sure about Grease providing reference implementations of all >> methods it tests, though. I'm not convinced that a "gold standard" >> always exists, nor that it will necessarily be implemented by Grease. >> In many cases, we have standardized on methods that already exist in >> Squeak/Pharo or in some other platform. >> >> On Thu, Jun 17, 2010 at 9:30 AM, Dale Henrichs <dhenrich(a)vmware.com> >> wrote: >>> >>> Julian, >>> >>> The Grease-Core package contains a mixture of things (for convenience): >>> the >>> GR* family of classes using a naming convention that is unlikely to >>> collide >>> with platform classes and a collection of extensions to well-known >>> classes >>> using names that could very easily collide with platform methods (or >>> prevent >>> a platform from implementing that method in their base system). >>> >>> The well-known class extension methods could easily be moved to the >>> platform-side, then as platforms adopt the Grease extensions (an obvious >>> goal of Grease in the first place) the platform extensions can be >>> adjusted >>> accordingly...the Grease-Tests for those methods should remain so that >>> from >>> the Grease-Users perspective the behavior for those methods will remain >>> consistent (relative to Grease) over time... >>> >>> It _would be convenient_ to preserve the current well-known class >>> extension >>> method implementations so that when Grease is ported to a new platform >>> the >>> "standard implementation" can be used as a bootstrap. In fact if the >>> well-known class extension methods were moved into a separate platform >>> package, then you'd have the gold standard implementation and the initial >>> pharo/squeak implementation rolled into one. >>> >>> In the end this doesn't sound that awful... >>> >>> Dale >>> >>> Julian Fitzell wrote: >>>> >>>> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>>>> >>>>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>>>> >>>>> - If included with Pharo I suggest to rename all the methods, >>>>> otherwise we will run into big troubles with Seaside and other >>>>> projects that depend on Grease. >>>>> >>>>> >>>>> From a philosophical standpoint, I *hate* that. this means that as a >>>>> plattform, we can not >>>>> grow and improve our libraris anymore? >>>>> Shouldn't be the goal that useful extensions gets adopted by the core? >>>> >>>> We will need to find a way to allow platforms to adopt Grease methods >>>> - I do think this is the end goal. It's a bit of a nightmare from our >>>> point of view because we end up having to have different Grease >>>> versions for different versions of the platforms, but isn't that sort >>>> of unavoidable in the long run anyway? Part of the reason that's so >>>> awful is simply due to the lack of good branching and management tools >>>> in our version control systems... >>>> >>>> Julian >>>> >>>> _______________________________________________ >>>> 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 >

June 22, 2010