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

Re: [Pharo-dev] PharoCommandLineHandler

by Camillo Bruni

On 2013-10-04, at 14:54, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > It is not in the separate (or other) package so it still makes > problems for Kernel jobs (I have to remove this class before > shrinking). > This information from the documentation does not seem to be valid: > "It first checks if another handler is available. If so it will > activate the found handler." Indeed, it is not fully correct: ./pharo Pharo.image eval '1+2' will activates the EvaluateCommandLineHandler (after going through the PharoCommandLineHandler), whereas ./pharo Pharo.image --help only activates the PharoCommandLineHandler. feel free to update the comments

Oct. 4, 2013

[update 3.0] #30449

by Marcus Denker

30449 ----- 11777 Fix SpecTests https://pharo.fogbugz.com/f/cases/11777 11776 Fix Create action on #subclassResponsibility https://pharo.fogbugz.com/f/cases/11776 The debugger now displays the create button when an exception of type #subclassResponsibility is shown. However this action should only be shown if we are not working with an object of the abstract class (yes, normally it should not happen). Also all possible superclasses in which the method can be added should be displayed: for example consider this hierarchy: Parent -> Child1 -> Child11 -> Child111 and Parent>>doSomething self subclassResponsibility In this case 'Parent new doSomething' should not add a create action in the debugger. 'Child1 new doSomething' should automatically implement the method in the class Child1 'Child3 new doSomething' should allow the user to select if he wants to add the method in classes Child1, Child2 or Child3. In all cases traits should be taken into account. Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Tests-MarcusDenker.37.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.…

Oct. 4, 2013

Re: [Pharo-dev] PharoCommandLineHandler

by Pavel Krivanek

It is not in the separate (or other) package so it still makes problems for Kernel jobs (I have to remove this class before shrinking). This information from the documentation does not seem to be valid: "It first checks if another handler is available. If so it will activate the found handler." -- Pavel 2013/10/4 Camillo Bruni <camillobruni(a)gmail.com>: > We introduced this class because of the Kernel jobs (see the class comment). > > So yes, it is essential for the Pharo Image, not for the Kernel (as you can see by its superclass). > > On 2013-10-04, at 14:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> which pharo version? >> >> On 2013-10-04, at 14:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >>> PharoCommandLineHandler is strange. What is real purpose of this >>> class? Do we need it? It adds UsersManager dependency but I do not >>> think that it really stops the processing of arguments. >>> >>> -- Pavel >>> >> >

Oct. 4, 2013

Re: [Pharo-dev] PharoCommandLineHandler

by Camillo Bruni

We introduced this class because of the Kernel jobs (see the class comment). So yes, it is essential for the Pharo Image, not for the Kernel (as you can see by its superclass). On 2013-10-04, at 14:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > which pharo version? > > On 2013-10-04, at 14:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> PharoCommandLineHandler is strange. What is real purpose of this >> class? Do we need it? It adds UsersManager dependency but I do not >> think that it really stops the processing of arguments. >> >> -- Pavel >> >

Oct. 4, 2013

Re: [Pharo-dev] PharoCommandLineHandler

by Camillo Bruni

which pharo version? On 2013-10-04, at 14:42, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > PharoCommandLineHandler is strange. What is real purpose of this > class? Do we need it? It adds UsersManager dependency but I do not > think that it really stops the processing of arguments. > > -- Pavel >

Oct. 4, 2013

Re: [Pharo-dev] RPackage-SystemIntegration problem

by Pavel Krivanek

It helped, thanks. -- Pavel 2013/10/4 Marcus Denker <marcus.denker(a)inria.fr>: > > On Oct 4, 2013, at 11:46 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> When I look at the package RPackage-SystemIntegration (v. 173) and I >> do browse it in Monticello GUI, it doesn't contain the extension of >> the removed class ClassOrganizer. But when I do the same and I browse >> the this package in the same version from the Pharo repository, it >> does contain extension of the ClassOrganizer. >> As the result the job that tries to load Gofer to PharoKernel fails >> because the exported .st file contains extension of the nonexisting >> class. >> Can you, please, try to save the new version of the package or >> something like that to remove this extension from the package content? > > > Ok, I will do that with the next update. > >

Oct. 4, 2013

Re: [Pharo-dev] [ann] system attraction view

by Goubier Thierry

Le 04/10/2013 14:14, Tudor Girba a Ã©crit : > Hi, > > > On Fri, Oct 4, 2013 at 1:41 PM, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > Hi Tudor, > > I found your visualisation very interesting, and wondered about one > thing linked to your blog post and if I got it right. > > The visualisation you're showing is able to show, at the single > class level, if a class is more or less regular (i.e. tidy == well > designed?) but you show that it will loose very shortly it's tidy > shape if the classes it joins to are added to the visualisation. And > I wondered if this was a choice on the graph layout algorithm you've > choosen, i.e. that maintaining the tidiness of the class could be > done with a different layout algorithm? Maybe one which has a > measure of tidiness of the class at the local level, and weight it > against the position and attraction of its links to the other > components in the application? > > > My argumentation is that if we look at a class isolated it will have a > certain shape, and because we are exposed to this view (the IDE is > always showing me only that) all the time we will optimize it such that > the shape is tidy. But if we look at the class in the context of its > interactions the shape will be less recognizable. The chosen layout is a > very simple one, and the goal is not to say whether the structure is > good or bad. This is neither good nor bad. It simply argues how steering > the architecture has to take these forces into account. Hum, my point would be that a locally well designed class is a factor to strive for; also that the overall architecture has it's impact on it as well, but not so as to so easily erase the local good property when looking at the visualisation, otherwise the latter may not end up so usefull, that's all. I do agree with your point, I just believe the layout could carry a bit more insight in trying to both show the local property the code was trying to achieve (and areas where it failed) and the "emergence" of the architecture coupling on it. Your representation seemed to imply that local good design is unimportant in the architectural view, and I'm sure this is not what it is supposed to convey. > > In the mean time, I'm slowly discovering we have amazing software > architecture visualisation tools :) > > > They really are amazing :). If you want to get more information about > it, you can join the Moose mailing list: > http://www.moosetechnology.org/about/contact I'll do once I have a strong/practical incentive :) I know its there, StÃ©phane showed a lot of interesting things in it when he came here, but I didn't managed to organize things around that subject. > Would really like to setup a project on that if I get the chance. > > > What do you mean? What kind of a project? Collaborative R or R&D project :) Only way I can justify working on something like that... A good fit would be visualisation of large software in my lab expertise area : high performance and real time massively parallel software on embedded systems. 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

Oct. 4, 2013

PharoCommandLineHandler

by Pavel Krivanek

PharoCommandLineHandler is strange. What is real purpose of this class? Do we need it? It adds UsersManager dependency but I do not think that it really stops the processing of arguments. -- Pavel

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30446

by Clara Allende

Thank you all! :D On 4 October 2013 09:37, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Thanks for integrating it :) > > > On Fri, Oct 4, 2013 at 10:53 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >> 30446 >> ----- >> >> 11719 integrate all the changes from the repository of the new debugger >> https://pharo.fogbugz.com/f/cases/11719 >> >> This commit contains the following main changes: >> - debugging actions are first class entities; they are defined in >> separate classes. All actions from the toolbar are added dynamically based >> on pragmas. >> - separated the spec interface into multiple widgets: stack, toolbar, >> buttons >> - have dedicated filters to hide contexts from the stack >> >> Thanks to Clara Allende and Andrei Chis! >> >> >> Diff information: >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Settings-Tools-MarcusDenker.4… >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.76… >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.… >> >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerFilters-MarcusDenker.… >> >> >

Oct. 4, 2013

Re: [Pharo-dev] [update 3.0] #30446

by Andrei Chis

Thanks for integrating it :) On Fri, Oct 4, 2013 at 10:53 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 30446 > ----- > > 11719 integrate all the changes from the repository of the new debugger > https://pharo.fogbugz.com/f/cases/11719 > > This commit contains the following main changes: > - debugging actions are first class entities; they are defined in separate > classes. All actions from the toolbar are added dynamically based on > pragmas. > - separated the spec interface into multiple widgets: stack, toolbar, > buttons > - have dedicated filters to hide contexts from the stack > > Thanks to Clara Allende and Andrei Chis! > > > Diff information: > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.16… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/Settings-Tools-MarcusDenker.4… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.76… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerActions-MarcusDenker.… > > http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerFilters-MarcusDenker.… > >

Oct. 4, 2013