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

Re: [Pharo-project] PointerFinder & PointerExplorer

by StÃ©phane Ducasse

could you open a ticket for the next iteration (now that you have the idea fresh in your mind). I want that we get a really nice pointerExplorer tools. Stef On Jun 12, 2010, at 9:54 PM, Johan Brichau wrote: > Hi Mariano, > > Indeed, we intended to adopt that fix at first. Here's what we saw: > > PointerFinder works by following pointers forward from the global dictionary. > PointerExplorer works by following pointers backward from the inspected object, using #pointsTo: > > Matthew's fix includes an adaptation of #pointsTo: to include the 'pointer' from instances to their class, and renames the original #pointsTo: to #instVarsInclude: > In essence, this means: > > (#bar pointsTo: Symbol) == true > (#bar instVarInclude: Symbol) == false > > But: > > PointerFinder on: Symbol > -> opens an empty window... > > Which makes the two tools pretty inconsistent, imho. In addition, PointerFinder is rather weird in usage: showing you a single path at a time. So, we would rather prefer to keep the instance-to-class pointer out of the #pointsTo: implementation alltogether and only use PointerExplorer. > > Thinking a bit more about this, it would make sense to improve PointerExplorer such that the ideal use-case for PointerFinder is better supported: i.e. 'open all paths to global dictionary'. > I hope I'm making sense here :-) > > Johan > > On 12 Jun 2010, at 15:29, Mariano Martinez Peck wrote: > >> Hi Johan. Very nice you started with this. Once, I took that issue and understood what Mattew did in squeak: http://bugs.squeak.org/view.php?id=7158 >> >> I liked his solution but I was not completly agree, I don't remember why, thus. Did you look at it? any thoughts about that? >> >> cheers >> >> Mariano >> >> On Sat, Jun 12, 2010 at 10:33 AM, Johan Brichau <johan.brichau(a)uclouvain.be> wrote: >> Issue #156 (http://code.google.com/p/pharo/issues/detail?id=156) states that PointerFinder and PointerExplorer both have issues leaving out some pointers. >> >> Andy and I have been looking at the implementation of PointerFinder and PointerExplorer in Pharo1.1 to fix this. >> >> We came to the decision to throw out PointerFinder, replace its uses to uses of PointerExplorer and move PointerFinder's #pointersTo* class methods to ProtoObject because: >> - PointerFinder's (instance) behavior seems to be really old code that was not using the pointsTo: (primitive) method, while its #pointersTo* class methods were using the pointsTo: (primitive) method >> - It also seems the instance behavior of PointerFinder was wrong (it did not give us all pointers *at all*) >> - PointerExplorer offers the same functionality using a tree view and eventually used the #pointersTo* class methods of PointerFinder... >> >> The fix is in SLICE-PointerFinderRemove-AndyKellens.1 and should be for 1.2 >> >> Maybe anyone has another opinion? >> >> ---------------------------- >> Johan Brichau >> johan.brichau(a)uclouvain.be >> >> >> >> >> >> _______________________________________________ >> 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 > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 12, 2010

Re: [Pharo-project] PointerFinder & PointerExplorer

by Johan Brichau

Hi Mariano, Indeed, we intended to adopt that fix at first. Here's what we saw: PointerFinder works by following pointers forward from the global dictionary. PointerExplorer works by following pointers backward from the inspected object, using #pointsTo: Matthew's fix includes an adaptation of #pointsTo: to include the 'pointer' from instances to their class, and renames the original #pointsTo: to #instVarsInclude: In essence, this means: (#bar pointsTo: Symbol) == true (#bar instVarInclude: Symbol) == false But: PointerFinder on: Symbol -> opens an empty window... Which makes the two tools pretty inconsistent, imho. In addition, PointerFinder is rather weird in usage: showing you a single path at a time. So, we would rather prefer to keep the instance-to-class pointer out of the #pointsTo: implementation alltogether and only use PointerExplorer. Thinking a bit more about this, it would make sense to improve PointerExplorer such that the ideal use-case for PointerFinder is better supported: i.e. 'open all paths to global dictionary'. I hope I'm making sense here :-) Johan On 12 Jun 2010, at 15:29, Mariano Martinez Peck wrote: > Hi Johan. Very nice you started with this. Once, I took that issue and understood what Mattew did in squeak: http://bugs.squeak.org/view.php?id=7158 > > I liked his solution but I was not completly agree, I don't remember why, thus. Did you look at it? any thoughts about that? > > cheers > > Mariano > > On Sat, Jun 12, 2010 at 10:33 AM, Johan Brichau <johan.brichau(a)uclouvain.be> wrote: > Issue #156 (http://code.google.com/p/pharo/issues/detail?id=156) states that PointerFinder and PointerExplorer both have issues leaving out some pointers. > > Andy and I have been looking at the implementation of PointerFinder and PointerExplorer in Pharo1.1 to fix this. > > We came to the decision to throw out PointerFinder, replace its uses to uses of PointerExplorer and move PointerFinder's #pointersTo* class methods to ProtoObject because: > - PointerFinder's (instance) behavior seems to be really old code that was not using the pointsTo: (primitive) method, while its #pointersTo* class methods were using the pointsTo: (primitive) method > - It also seems the instance behavior of PointerFinder was wrong (it did not give us all pointers *at all*) > - PointerExplorer offers the same functionality using a tree view and eventually used the #pointersTo* class methods of PointerFinder... > > The fix is in SLICE-PointerFinderRemove-AndyKellens.1 and should be for 1.2 > > Maybe anyone has another opinion? > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > 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 ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

June 12, 2010

Re: [Pharo-project] Issue 2290: window placement strategy

by StÃ©phane Ducasse

Thanks jannik I will have a look On Jun 12, 2010, at 9:27 PM, Laval Jannik wrote: > Hi all, > > I made a setting for placement strategy. > By default, it is reversed stragger (which is the one by default since Pharo exists). > And I create one I have named "Cascade", which place the new window above the current active window, or if there is no active window, the window is placed at the cursor position. > > The change is available in SLICE-Issue-2290-windowsStrategy. > The setting is available in the SettingBrowser in Appearance>Morphic>Windows>Window position strategy. > > Now, it is possible to create new strategy positions by creating a new strategy in RealEstateAgent (category strategy - there is also three strategies), and by modifying the method RealEstateAgent >>usedStrategySettingsOn: to add an entry in the menu. > > I hope that this change will be integrated in 1.2. > > Cheers, > --- > Jannik Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 12, 2010

Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta

by StÃ©phane Ducasse

This is cool lukas. Let us know if you have any problem. we started to put pharo1.2 in our hudson server and it worked but now we ahve to understand why this does not work anymore. In any case getting an integration server is great since it will force us to think in another way that interactively. Stef On Jun 12, 2010, at 5:18 PM, Lukas Renggli wrote: >> You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present. > > The daily Seaside builds are based on PharoCore1.1rc1. > > http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifa… > > Lukas > > -- > Lukas Renggli > 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

June 12, 2010

Re: [Pharo-project] [ANN] Bytes, a convenience to print the size of things

by StÃ©phane Ducasse

neat :) May be you should create a metacello configuration for it. On Jun 12, 2010, at 5:03 PM, sebastian(a)flowingconcept.com wrote: > Hi there, > > I've published a package to help printing measures of bytes in a human readable fashion. > > Here is is: > http://www.squeaksource.com/Bytes > > Examples: > > 2 gigabytes asMegabyteString "will give you '2048 MB' if you print it" > > for those who have stored half of the galaxy its range goes from kilo to yatto > > enjoy > > sebastian > PS: it uses Aconcagua as foundation so be sure to install it first > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 12, 2010

[Pharo-project] Issue 2290: window placement strategy

by Laval Jannik

Hi all, I made a setting for placement strategy. By default, it is reversed stragger (which is the one by default since Pharo exists). And I create one I have named "Cascade", which place the new window above the current active window, or if there is no active window, the window is placed at the cursor position. The change is available in SLICE-Issue-2290-windowsStrategy. The setting is available in the SettingBrowser in Appearance>Morphic>Windows>Window position strategy. Now, it is possible to create new strategy positions by creating a new strategy in RealEstateAgent (category strategy - there is also three strategies), and by modifying the method RealEstateAgent >>usedStrategySettingsOn: to add an entry in the menu. I hope that this change will be integrated in 1.2. Cheers, --- Jannik Laval

June 12, 2010

Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta

by Schwab,Wilhelm K

Lukas, This is interesting. Is there any way to find the script that was run to build a particular image? What separates the successful and stable builds from the unstable ones? What (how bad) is a fail build? You load Shout (which is a must<g>). Otherwise, how similar is the image to Pharo-dev + Seaside? Is there a way to get the bleeding edge of Pharo and a stable version of Seaside? Is the reported "last duration" (41 min) the time it took to create the image? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Saturday, June 12, 2010 11:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta > You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present. The daily Seaside builds are based on PharoCore1.1rc1. http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifa… Lukas -- Lukas Renggli 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

June 12, 2010

Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta

by Schwab,Wilhelm K

Ok, maybe I *do* want to "retreat" to the Seaside images :) I will give it a try. My current code is based on Seaside 2.8, but a quick scan of the migration document does not appear terrifying (most of my Seaside code is pretty simple, I think). I could ask a bunch of questions, but a quick look will provide the answers. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] Sent: Saturday, June 12, 2010 11:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta > You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present. The daily Seaside builds are based on PharoCore1.1rc1. http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifa… Lukas -- Lukas Renggli 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

June 12, 2010

Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta

by Lukas Renggli

> You are already producing 1.2. Â The core is at 1.1 RC - that's great! Â But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Â Then I need a Seaside-enabled image on top of that. Â There is very little of value I can do with a release until Seaside is present. The daily Seaside builds are based on PharoCore1.1rc1. http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifa… Lukas -- Lukas Renggli www.lukas-renggli.ch

June 12, 2010

[Pharo-project] [ANN] Bytes, a convenience to print the size of things

by sebastian＠flowingconcept.com

Hi there, I've published a package to help printing measures of bytes in a human readable fashion. Here is is: http://www.squeaksource.com/Bytes Examples: 2 gigabytes asMegabyteString "will give you '2048 MB' if you print it" for those who have stored half of the galaxy its range goes from kilo to yatto enjoy sebastian PS: it uses Aconcagua as foundation so be sure to install it first

June 12, 2010