September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] feature idea - Watcher

by Igor Stasenko

On 11 September 2012 15:09, Ben Coman <btc(a)openinworld.com> wrote: > > One thing I remember from 25 years ago using Turbo Pascal is having an > "Expression Watcher" pane, where expressions could be defined that were > evaluated after each debugging step. With this you could drill down to a > particular interesting part of a data structure to observe how it changes > with time. I am reminded of this since just now, since I am finding each > time I rerun a test script and the debugger opens up at my 'halt' point, I > am repetitively having to 'inspect' from a root object through several > levels of components to compare the components of interest - before > continuing to step the code watching how these component values change in > relation to each other. > > For example if variable1 holds an OrderedCollection of five morphs and I > want to watch the 'bounds' of all five elements simultaneously as they > update at each debugging step - currently each time after the debugger opens > I have to inspect variable1, then Inspect each of the elements, the select > the 'bounds' instance variable in each Inspector window, then shrink the > size each inspector so that they don't obscure the screen, which is fairly > tedious to do each time. Further, with 'bounds' matching an instance > variable this is at least possible - once this is set up I can watch the > 'bounds' value change with each debug step. However if I want to observe how > the 'extent' of each morph changes with each debug step I am out of luck. > With my current knowledge, I would need to manually execute 'self extent' in > each of the five Inspectors after each debug step, > > It would be good if there were some way for expressions to be defined which > persist through debugger invocations that at each debug step are evaluated > on the instance variables available in the debugger at that time. > For the example above this might be defined of the form... <'label'> > <expression> <'extent1'> <(variable1 asArray at: 1) extent> <'extent2'> > <(variable1 asArray at: 2) extent> > <'extent3'> <(variable1 asArray at: 3) extent> > <'extent4'> <(variable1 asArray at: 4) extent> > <'extent5'> <(variable1 asArray at: 5) extent> > i don't think it worth spending time on implementing such complex definitions.. as to me, being able to simple re-evaluate and expression sent to some object(s) (and print its result , of course) at every debug step will be just enough. > Is there currently any way to do this, or would others find something like > this a useful feature ? > > cheers -ben > -- Best regards, Igor Stasenko.

Sept. 11, 2012

Re: [Pharo-project] SqueakSource3: ByteString(Object)>>doesNotUnderstand: #goferReferences

by Mariano Martinez Peck

On Tue, Sep 11, 2012 at 4:59 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > Marten, > see > http://code.google.com/p/squeaksource3/issues/detail?id=20 > > and > > http://code.google.com/p/pharo/issues/detail?id=4708 > > to be short, you should use url instead > > Gofer new > url: 'http://ss3.gemstone.com/ss/**ICU<http://ss3.gemstone.com/ss/ICU> > '; > > or #squeaksource3: 'ICU'; > package: 'ConfigurationOfICU'; > package: 'ICU-Core'; > package: 'ICU-NativeBoost-Core'; > package: 'ICU-Tests-Core'; > package: 'ICU-Tests-NativeBoost'; > load > > > > On Tue, Sep 11, 2012 at 11:37 AM, Marten Feldtmann <marten(a)schrievkrom.de>wrote: > >> When I copy the Gofer source (listed on the project pages) to a Pharo 1.4 >> and tries to execute stuff like: >> >> Gofer new >> repository: 'http://ss3.gemstone.com/ss/**ICU<http://ss3.gemstone.com/ss/ICU> >> '; >> package: 'ConfigurationOfICU'; >> package: 'ICU-Core'; >> package: 'ICU-NativeBoost-Core'; >> package: 'ICU-Tests-Core'; >> package: 'ICU-Tests-NativeBoost'; >> load >> >> I get an error message: >> >> ByteString(Object)>>**doesNotUnderstand: #goferReferences >> >> >> Marten >> > > > > -- > Bernardo E.C. > -- Mariano http://marianopeck.wordpress.com

Sept. 11, 2012

Re: [Pharo-project] Refactoring Tests

by Mariano Martinez Peck

On Tue, Sep 11, 2012 at 4:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ooops this is bad. > Now we never decided what to do with RB. > Yes....but the reality is that it is integrated since Nautilus was integrated. > Remember my mail where I ask where do we save changes? > > Stef > > > Cami, I think tests were never integrated in the image when RB was > integrated. > > I would check the ConfigurationOf, see where the tests came from, load > them in Pharo and then create an issue to integrate them. > > > > On Tue, Sep 11, 2012 at 3:29 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > Are there anywhere refactoring tests? > > Cause in the latest image I don't find any (maybe I just don't see > well)... > > > > > > best > > cami > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 11, 2012

Re: [Pharo-project] Refactoring Tests

by Mariano Martinez Peck

On Tue, Sep 11, 2012 at 4:50 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-09-11, at 16:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Ooops this is bad. > > Now we never decided what to do with RB. > > Remember my mail where I ask where do we save changes? > > No Problem, actually I can load all tests and except for the Environment > tests > everything passes (needed a minor refactoring to fix FileDirectory > stuff)... > > So I'll propose a bug issue to integrate them. > Yes, excellent :) > > >> Cami, I think tests were never integrated in the image when RB was > integrated. > >> I would check the ConfigurationOf, see where the tests came from, load > them in Pharo and then create an issue to integrate them. > >> > >> On Tue, Sep 11, 2012 at 3:29 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > >> Are there anywhere refactoring tests? > >> Cause in the latest image I don't find any (maybe I just don't see > well)... > >> > >> > >> best > >> cami > >> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > > > > -- Mariano http://marianopeck.wordpress.com

Sept. 11, 2012

Re: [Pharo-project] [update 2.0] #20279

by Esteban Lorenzano

yes it is :) On Sep 11, 2012, at 5:14 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 11/09/2012 16:18, Esteban Lorenzano a Ã©crit : >> 20279 >> ----- >> >> Issue 6654: Make one RPackage maps one PackageInfo >> http://code.google.com/p/pharo/issues/detail?id=6654 >> >> (pass 1) >> >> - Rollback Nautilus to a pre-tags version >> - initialize RPackageOrganizer from PackageInfos as before >> >> WARNING: This does not restores 2.0 stability, but it makes it a bit more usable... I'm working on the other issues. >> >> > Works for me. > > I see one RPackage for each system categories, not one RPackage per PackageInfo, and no RPackageSet yet. > > Is that what we should expect? > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Sept. 11, 2012

Re: [Pharo-project] [update 2.0] #20279

by Goubier Thierry

Le 11/09/2012 16:18, Esteban Lorenzano a Ã©crit : > 20279 > ----- > > Issue 6654: Make one RPackage maps one PackageInfo > http://code.google.com/p/pharo/issues/detail?id=6654 > > (pass 1) > > - Rollback Nautilus to a pre-tags version > - initialize RPackageOrganizer from PackageInfos as before > > WARNING: This does not restores 2.0 stability, but it makes it a bit more usable... I'm working on the other issues. > > Works for me. I see one RPackage for each system categories, not one RPackage per PackageInfo, and no RPackageSet yet. Is that what we should expect? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 11, 2012

Re: [Pharo-project] urgent rpackage fix

by Camillo Bruni

On 2012-09-11, at 16:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > but that's with the "old new implementation" > > in the "new new implementation", TestFoo in "Test-Foo-Bar" will produce: > > lookup? 'Tests-Foo-Bar' => success! > lookup? 'Tests-Foo' => fail! > lookup? 'Tests' => fail! > > but... RPackageSet ("Tests" or "Tests-Foo") lookup will succeed. > > That's why I asked you to wait... all changes you do now could have no sense or change tomorrow :) indeed for that fix I will wait. first I thought it's a local problem of not properly updating tags, but behold! there is more to it ;)

Sept. 11, 2012

Re: [Pharo-project] SqueakSource3: ByteString(Object)>>doesNotUnderstand: #goferReferences

by Bernardo Ezequiel Contreras

Marten, see http://code.google.com/p/squeaksource3/issues/detail?id=20 and http://code.google.com/p/pharo/issues/detail?id=4708 to be short, you should use url instead Gofer new url: 'http://ss3.gemstone.com/ss/**ICU <http://ss3.gemstone.com/ss/ICU> '; package: 'ConfigurationOfICU'; package: 'ICU-Core'; package: 'ICU-NativeBoost-Core'; package: 'ICU-Tests-Core'; package: 'ICU-Tests-NativeBoost'; load On Tue, Sep 11, 2012 at 11:37 AM, Marten Feldtmann <marten(a)schrievkrom.de>wrote: > When I copy the Gofer source (listed on the project pages) to a Pharo 1.4 > and tries to execute stuff like: > > Gofer new > repository: 'http://ss3.gemstone.com/ss/**ICU<http://ss3.gemstone.com/ss/ICU> > '; > package: 'ConfigurationOfICU'; > package: 'ICU-Core'; > package: 'ICU-NativeBoost-Core'; > package: 'ICU-Tests-Core'; > package: 'ICU-Tests-NativeBoost'; > load > > I get an error message: > > ByteString(Object)>>**doesNotUnderstand: #goferReferences > > > Marten > -- Bernardo E.C.

Sept. 11, 2012

Re: [Pharo-project] urgent rpackage fix

by Esteban Lorenzano

but that's with the "old new implementation" in the "new new implementation", TestFoo in "Test-Foo-Bar" will produce: lookup? 'Tests-Foo-Bar' => success! lookup? 'Tests-Foo' => fail! lookup? 'Tests' => fail! but... RPackageSet ("Tests" or "Tests-Foo") lookup will succeed. That's why I asked you to wait... all changes you do now could have no sense or change tomorrow :) Esteban On Sep 11, 2012, at 4:47 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2012-09-11, at 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> camillo >> >> what is "added hierarchical RPackage lookup" ? >> Why do we need that beast? > > Because right now RPackageOrganizer does a wrong lookup for classes > see RPackageOrganizer>>#systemClassRenamedActionFrom: > which does a > #packageNamed: class category > which fails if the class is not in a toplevel package. > > Let's say I refactor a class TestFoo in the category 'Tests-Foo-Bar' > the message send to #packageNamed: will try to find a package named > 'Tests-Foo-Bar' but the actual existing package is only 'Tests' and > the rest is the tag part. > > => you have to find the RPackage with the most common name > lookup? 'Tests-Foo-Bar' => fail! > lookup? 'Tests-Foo' => fail! > lookup? 'Tests' => success! > 'Tests' => lookup tag? 'Foo-Bar' => success!

Sept. 11, 2012

Re: [Pharo-project] urgent rpackage fix

by StÃ©phane Ducasse

On Sep 11, 2012, at 4:47 PM, Camillo Bruni wrote: > > On 2012-09-11, at 16:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> camillo >> >> what is "added hierarchical RPackage lookup" ? >> Why do we need that beast? > > Because right now RPackageOrganizer does a wrong lookup for classes > see RPackageOrganizer>>#systemClassRenamedActionFrom: > which does a > #packageNamed: class category > which fails if the class is not in a toplevel package. I see. and probably class category is not mapped to the correct place. > Let's say I refactor a class TestFoo in the category 'Tests-Foo-Bar' > the message send to #packageNamed: will try to find a package named > 'Tests-Foo-Bar' but the actual existing package is only 'Tests' and > the rest is the tag part. Yes bitten by the pattern shit again. > => you have to find the RPackage with the most common name > lookup? 'Tests-Foo-Bar' => fail! > lookup? 'Tests-Foo' => fail! > lookup? 'Tests' => success! > 'Tests' => lookup tag? 'Foo-Bar' => success! I hate that! Fucking extra complexity. Tx that you fix it. This is exactly what I want to remove. So in Pharo 3.0 I will kill this lookup. Stef

Sept. 11, 2012