- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20279
by Esteban Lorenzano Sept. 11, 2012

Sept. 11, 2012

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.

5 5

[Pharo-project] feature idea - Watcher
by Ben Coman Sept. 11, 2012

Sept. 11, 2012

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> Is there currently any way to do this, or would others find something like this a useful feature ? cheers -ben

3 2

[Pharo-project] SqueakSource3: ByteString(Object)>>doesNotUnderstand: #goferReferences
by Marten Feldtmann Sept. 11, 2012

Sept. 11, 2012

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'; 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

3 2

[Pharo-project] Refactoring Tests
by Camillo Bruni Sept. 11, 2012

Sept. 11, 2012

Are there anywhere refactoring tests? Cause in the latest image I don't find any (maybe I just don't see well)... best cami

3 7

[Pharo-project] urgent rpackage fix
by Camillo Bruni Sept. 11, 2012

Sept. 11, 2012

please include ASAP https://code.google.com/p/pharo/issues/detail?id=6648 fixes broken classtag updates when performing a refactoring

3 5

[Pharo-project] Making Pharo 2.0 usable
by Alexandre Bergel Sept. 11, 2012

Sept. 11, 2012

Hi! I will be happy to see Pharo 2.0 usable. A lot of things happens and I cannot benefit from them. At the next ESUG I will invite the one who make Pharo 2.0 usable to a restaurant / plenty of beers. Go go go! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

[Pharo-project] RE : Re: RE : RE : NewClassOrganizer
by Philippe Back Sept. 9, 2012

Sept. 9, 2012

Cami, A general ordering of standard (so to speak) protocols would be nice indeed. But what about pretty local protocols? Like things in PetitParser for example. Alphabetical would be a nuisance. Philippe Back Camillo Bruni <camillobruni(a)gmail.com> a Ã©crit : On 2012-09-09, at 13:39, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > You are a very directive kind of person, when it comes to thoses things... > If a user want it classified his way, who am I to change his ordering ? You got me wrong there, I am talking about a user defined / preference dict. It's like choosing your preferred font. Of course this solution is very simplistic only holding up to a single global order. The other solution might be to simply replace the Dictionary in the new class organizer by something like an OrderedKeyDictionary plus a Nautilus plugin, DONE If you want my very personal opinion, I think it's not really helpful to have anything but alphabetic sorting. I use the new shortcuts in 2.0 to simply jump to the category I want, that saves me some couple of 100ms visual perception time on each selection. > No, the solution isn't yet another level of ill-defined "pattern matching" to try to get that result. Smalltalk has, from the beginning, been able to show good practice by letting it's developpers set well though-out conventions themselves, and by giving them the freedom to do so (maybe not consciously in some cases, but still). Regressing on that isn't good. Well, I personnaly will rebuilt yet another RPackage like system to get what I need, obviously. I don't see any problem there. > By the way, have you noticed that on some systems, Pharo 2.0 starts to feel slow to use ? in regard to what? I would say if you do a DeltaSlowness / AddedFeaturesIn2.0 you end up with something close to 0...

3 2

[Pharo-project] Configuration loading 1.4 vs 2.0
by Camillo Bruni Sept. 9, 2012

Sept. 9, 2012

After Igor's remark about the loading speed of configs in 2.0 I ran twice the same configuration in 1.4 and 2.0 and things load incredibly slow under 2.0 Subjectively it seems that 2.0 spends ages loading Metacello / Gofer stuff. I'll dive a bit into it to see if somethings stands out... The two images with the Profiler opened: http://dl.dropbox.com/u/18184943/LoadConfig1.4.zip http://dl.dropbox.com/u/18184943/LoadConfig2.0.zip

2 1

Re: [Pharo-project] Configuration loading 1.4 vs 2.0
by Camillo Bruni Sept. 9, 2012

Sept. 9, 2012

On 2012-09-09, at 14:24, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I guess you tried both with an empty package-cache, right? yes, not much of a diff...

2 8

Re: [Pharo-project] Configuration loading 1.4 vs 2.0
by Camillo Bruni Sept. 9, 2012

Sept. 9, 2012

On 2012-09-09, at 14:14, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I think it has to do with the change in #readableFileNames Indeed it metacello does this big mistake of gathering all the local gofer-references first. But that would mean on an empty package-cache it should load the same way, but even then it's still considerably slower in 2.0 There's also an additional overhead by the announcement system for recategorizing methods..

1 0