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

[update 3.0] #30397

by Marcus Denker

30397 ----- 11602 No taskback icon for the debugger https://pharo.fogbugz.com/f/cases/11602 11589 Improve / Update GoferMetacelloLoad https://pharo.fogbugz.com/f/cases/11589 11584 Can not open Pharo if .changes has not write access https://pharo.fogbugz.com/f/cases/11584 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.9… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Polymorph-TaskbarIcons-Marcus… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Gofer-Core-MarcusDenker.206.d…

Sept. 14, 2013

Hierarchical Bundle Edges

by Alexandre Bergel

Hi! Some of you may have seen a glimpse of this at ESUG. Roassal now support Hierarchical Bundle Edge. It is a kind of line that follow a path to give a kind of organic connection between graph elements. Here is a screenshot Other screenshots are available on: https://www.facebook.com/media/set/?set=a.511442275609041.1073741827.340543… Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 14, 2013

[Seaside News] Smalltalkhub, ConfigurationOfSeaside3, Seaside3.1

by Johan Brichau

Hi Seasiders, The Seaside repository moved to Smalltalkhub, a new ConfigurationOfSeaside3 was created and Seaside 3.1 is in release candidate mode. Current stable release for all platforms is 3.0.8 (with a final bugfix release 3.0.9 coming up). Seaside 3.1 has all tests green on Pharo 1.4 and 2.0. We are working on Gemstone and Squeak Seaside and all Seaside team curated projects can be found here: http://www.smalltalkhub.com/#!/~Seaside We have grouped all Metacello configurations for these projects in a single repository: http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main Important: there now is a single configuration for both Seaside 3.0 and Seaside 3.1: ConfigurationOfSeaside3 To load current stable Seaside 3.0.8: Gofer new url: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; package: 'ConfigurationOfSeaside3'; load. ((Smalltalk at: #ConfigurationOfSeaside3) project version: #stable) load To load Seaside 3.1.0: ((Smalltalk at: #ConfigurationOfSeaside3) project version: '3.1.0') load Stay tuned for a follow-up email on Seaside3.1 For the Seaside team, Johan, Philippe, Dale, John

Sept. 14, 2013

Re: [Pharo-dev] Pharo Sprint in Buenos Aires - this saturday!

by StÃ©phane Ducasse

On Sep 13, 2013, at 11:54 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > One thing with RB environment scoping: RB selector environments are passive. The implementorsOf: environment just contains the result of the search, not the search query. If you create a new method of the same name, the environment won't see it, and the tools either since they can't ask the environment to re-run the query. Yes and this is why we should unify Enviromnet and ring since in ring could can specify if you want active method. We should do a pass on all that. > > Thierry > > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Date d'envoi : vendredi 13 septembre 2013 17:11 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Pharo Sprint in Buenos Aires - this saturday! > >> >> A RBEnvironment scoped version of my AltBrowser, with a bit of tree filtering on the display. > > Ok I see. > I want to have everytools working on environment so that we get scoping. > >> >> Finder is like the Finder plugin in Nautilus, except that it opens a scoped instance of the browser. >> >> MessageBrowser is replaced by a scoped instance of the browser. >> >> And the browser knows how to adjust the tree display depending on the scope (pruning the tree and adapting the display of items). >> >> Makes exploring code a lot easier mostly because of smart suggestions, otherwise I would do implementorsOf:, get the message browser, and use browse on each result one by one to open a new browser, and there have smart suggestions to do implementorsOf: to be able to follow a cascade of message sends :( >> >> I hated being in the finder, looking at the code pane and a multi arguments message and saying to myself 'but how will I do sendersOf or implementorsOf of that message?' > > Yes I understand. > >> >>>> , and I now have unified menus, shortcuts and smart suggestions and I find it really, really nice. >>> >>> do you have suggestion for the menus unification? >> >> Have a single code source editor* for all code panes, with the same menu building** code in each :) > > Oh yes!!!! > >> * This is probably the case in the old framework and the reason for having all thoses menu actions inside SmalltalkEditor. >> >> ** But something pluggable so that we may still be able to experiment! > > Yes. We should really revisit all the menus and get one way to build them and reuse them. > >> >> 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 >> <ScreenshotFinder.png> > > >

Sept. 14, 2013

Looks like RBPlatform and RBPharoPlatform can be easily removed

by StÃ©phane Ducasse

Hi Looks like RBPlatform and RBPharoPlatform can be easily removed since they define one single method. I will open a bug entry. Stef

Sept. 14, 2013

Re: [Pharo-dev] Pharo Sprint in Buenos Aires - this saturday!

by GOUBIER Thierry

One thing with RB environment scoping: RB selector environments are passive. The implementorsOf: environment just contains the result of the search, not the search query. If you create a new method of the same name, the environment won't see it, and the tools either since they can't ask the environment to re-run the query. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Date d'envoi : vendredi 13 septembre 2013 17:11 Ã : Pharo Development List Objet : Re: [Pharo-dev] Pharo Sprint in Buenos Aires - this saturday! > > A RBEnvironment scoped version of my AltBrowser, with a bit of tree filtering on the display. Ok I see. I want to have everytools working on environment so that we get scoping. > > Finder is like the Finder plugin in Nautilus, except that it opens a scoped instance of the browser. > > MessageBrowser is replaced by a scoped instance of the browser. > > And the browser knows how to adjust the tree display depending on the scope (pruning the tree and adapting the display of items). > > Makes exploring code a lot easier mostly because of smart suggestions, otherwise I would do implementorsOf:, get the message browser, and use browse on each result one by one to open a new browser, and there have smart suggestions to do implementorsOf: to be able to follow a cascade of message sends :( > > I hated being in the finder, looking at the code pane and a multi arguments message and saying to myself 'but how will I do sendersOf or implementorsOf of that message?' Yes I understand. > >>> , and I now have unified menus, shortcuts and smart suggestions and I find it really, really nice. >> >> do you have suggestion for the menus unification? > > Have a single code source editor* for all code panes, with the same menu building** code in each :) Oh yes!!!! > * This is probably the case in the old framework and the reason for having all thoses menu actions inside SmalltalkEditor. > > ** But something pluggable so that we may still be able to experiment! Yes. We should really revisit all the menus and get one way to build them and reuse them. > > 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 > <ScreenshotFinder.png>

Sept. 13, 2013

blog post on lazy become

by Eliot Miranda

Hi All, I've just published a blog post on lazy become and the partial read barrier<http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-re…>in Spur. I'd really appreciate criticism, preferrably as comments on the blog page. This is one of the riskier parts of the design so it really does need to be pounded on. -- thanks, Eliot

Sept. 13, 2013

Re: [Pharo-dev] Naming of Global Session

by Camillo Bruni

On 2013-09-13, at 12:09, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > so, if this is a class, would Session be an appropriate superclass for a > WebSession class? or any other type of Session class? I would say so. It is as generic as the name suggests. The class is lightweight and only contains the time when it was created. > That particular > name would seem to collide with other forms of Sessions, wouldn't it? Or > is this safely hidden in a Pharo Environment, so it won't collide elsewhere > (or entice other developers to try to use it for other Session style > objects)? It is a normal class, thus yes, collision is possible. Again, it can easily serve as a superclass for other session-like objects.

Sept. 13, 2013

Re: [Pharo-dev] Pharo Sprint in Buenos Aires - this saturday!

by StÃ©phane Ducasse

> > A RBEnvironment scoped version of my AltBrowser, with a bit of tree filtering on the display. Ok I see. I want to have everytools working on environment so that we get scoping. > > Finder is like the Finder plugin in Nautilus, except that it opens a scoped instance of the browser. > > MessageBrowser is replaced by a scoped instance of the browser. > > And the browser knows how to adjust the tree display depending on the scope (pruning the tree and adapting the display of items). > > Makes exploring code a lot easier mostly because of smart suggestions, otherwise I would do implementorsOf:, get the message browser, and use browse on each result one by one to open a new browser, and there have smart suggestions to do implementorsOf: to be able to follow a cascade of message sends :( > > I hated being in the finder, looking at the code pane and a multi arguments message and saying to myself 'but how will I do sendersOf or implementorsOf of that message?' Yes I understand. > >>> , and I now have unified menus, shortcuts and smart suggestions and I find it really, really nice. >> >> do you have suggestion for the menus unification? > > Have a single code source editor* for all code panes, with the same menu building** code in each :) Oh yes!!!! > * This is probably the case in the old framework and the reason for having all thoses menu actions inside SmalltalkEditor. > > ** But something pluggable so that we may still be able to experiment! Yes. We should really revisit all the menus and get one way to build them and reuse them. > > 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 > <ScreenshotFinder.png>

Sept. 13, 2013

Re: [Pharo-dev] Naming of Global Session

by Chris Cunningham

so, if this is a class, would Session be an appropriate superclass for a WebSession class? or any other type of Session class? That particular name would seem to collide with other forms of Sessions, wouldn't it? Or is this safely hidden in a Pharo Environment, so it won't collide elsewhere (or entice other developers to try to use it for other Session style objects)? On Fri, Sep 13, 2013 at 12:15 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > so could you do another iteration on it. > > Stef > > On Sep 13, 2013, at 1:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > Even more, it feels like we introducing another global (so users can write > 'Session current' , but why not just 'Session' then?) and so a step > backwards as to me. > Because we trying to get rid of all those Display, World, InputSensor , > ActiveHande etc globals for years. > > And last thing: there should be only one way to get current session > object. now there's two: > Smalltalk session > and > Session current > > and so, users now will inevitably raise the question: what is the right > 'true' API for accessing it? > and inevitably we will have two fighting camps, if we leave this thing in > image and be used in various projects. > > > > > On 13 September 2013 01:33, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> +1 too. >> Session is a bad name for a class. >> More than that, the people who introduced it, >> didn't care about: >> - removing unused session ivar from SmalltalkImage class >> - that putting #reset in Session class side, means exposing resetting >> mechanism to >> public, instead of keeping it private (and it is quite important to keep >> it private, >> because session should be reset once and only once and only in single , >> fully controllable place) >> >> from that perspective, i'd prefer using 'session' ivar in SmalltalkImage >> instead of >> 'current' in Session. >> >> >> >> >> On 12 September 2013 15:13, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: >> >>> +1 >>> >>> Very abstract names are fine when you have namespaces, otherwise I >>> rather chose more specific names. >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> >>> 2013/9/12 Torsten Bergmann <astares(a)gmx.de> >>> >>>> In Pharo 3.0 there is a new class "Session" - to represent the current >>>> smalltalk >>>> session. Using the term "Session" is very abstract. >>>> >>>> IMHO I would rather like to see it named more specific like >>>> "ImageSession", >>>> "PharoSession" or "SmalltalkSession" before it get used too much. >>>> >>>> Any comments? >>>> T. >>>> >>>> >>>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > > >

Sept. 13, 2013