- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SmallLint and Manifest

by Alexandre Bergel

I started to use it, and I will have suggestion on the GUI. Cheers, Alexandre On Sep 11, 2012, at 1:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > excellent! > Simon what about producing a video so that the world can see your nice tool in action. > > Stef > > > On Sep 11, 2012, at 4:21 PM, Simon Allier wrote: > >> I have fix the error found by Camillo, now it works with all packages and rules in the last pharo 2.0 image. >> >> On Sep 11, 2012, at 4:13 PM, Mariano Martinez Peck wrote: >> >>> >>> >>> On Mon, Sep 10, 2012 at 11:53 PM, Simon Allier <simon.allier(a)inria.fr> wrote: >>> Hi, >>> >>> I have published a new version of the Critics Browser (menuWorld > Tool > CriticBrowser). >>> The new version is >>> - refactoring friendly. Yes we listened to you :). >>> >>> hehehe I felt touched by that ;( >>> Thanks Simon, these are really great news because it doesn't mean we have to throw the manifiest away after a couple of refactors :) >>> I will re-run everything with Fuel soon and give you any feedback I have. >>> >>> - the browser has been improved. It works with the latest Spec. >>> >>> With the Critics browser you can inspect violations of the SmallLint rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. >>> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. >>> >>> In this new version the format of the manifest has changed to be compatible with tools refactoting, the rules are organized in a tree and itâs possible to adds comment when we mark a false positive or todo. >>> >>> We are writing a nice chapter on SmallLint, critics and other for the new book. Soon we will release it for reviews. >>> >>> Gofer >>> new >>> url: 'http://www.squeaksource.com/PharoTaskForces'; >>> package: 'ConfigurationOfManifest'; >>> load. >>> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load >>> >>> Simon >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2012

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

by GOUBIER Thierry

Cool. So far the only strange thing I see is with RPackage RPackages (:)). The RPackage package duplicates all extensions listed in RPackage-* packages. But this may be a problem with MC, not with RPackage in itself. I'll try a few extensions additions to check. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] Date d'envoi : mardi 11 septembre 2012 17:26 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] [update 2.0] #20279 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] SmallLint and Manifest

by StÃ©phane Ducasse

excellent! Simon what about producing a video so that the world can see your nice tool in action. Stef On Sep 11, 2012, at 4:21 PM, Simon Allier wrote: > I have fix the error found by Camillo, now it works with all packages and rules in the last pharo 2.0 image. > > On Sep 11, 2012, at 4:13 PM, Mariano Martinez Peck wrote: > >> >> >> On Mon, Sep 10, 2012 at 11:53 PM, Simon Allier <simon.allier(a)inria.fr> wrote: >> Hi, >> >> I have published a new version of the Critics Browser (menuWorld > Tool > CriticBrowser). >> The new version is >> - refactoring friendly. Yes we listened to you :). >> >> hehehe I felt touched by that ;( >> Thanks Simon, these are really great news because it doesn't mean we have to throw the manifiest away after a couple of refactors :) >> I will re-run everything with Fuel soon and give you any feedback I have. >> >> - the browser has been improved. It works with the latest Spec. >> >> With the Critics browser you can inspect violations of the SmallLint rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. >> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. >> >> In this new version the format of the manifest has changed to be compatible with tools refactoting, the rules are organized in a tree and itâs possible to adds comment when we mark a false positive or todo. >> >> We are writing a nice chapter on SmallLint, critics and other for the new book. Soon we will release it for reviews. >> >> Gofer >> new >> url: 'http://www.squeaksource.com/PharoTaskForces'; >> package: 'ConfigurationOfManifest'; >> load. >> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load >> >> Simon >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Sept. 11, 2012

Re: [Pharo-project] Event smell...

by Benjamin

On Sep 11, 2012, at 4:23 PM, Henrik Sperre Johansen wrote: > On 11.09.2012 15:41, Igor Stasenko wrote: >> On 11 September 2012 15:27, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> On 11.09.2012 14:35, StÃ©phane Ducasse wrote: >>>> Hi igor >>>> >>>> I started to reread again the code of EventModel that we started and I >>>> browse the rest of the systemâ¦. >>>> gloopsâ¦ >>>> >>>> DropEvent>>sentTo: anObject >>>> "Dispatch the receiver into anObject" >>>> self type == #dropEvent ifTrue:[^anObject handleDropMorph: self]. >>>> >>>> DropFilesEvent>>sentTo: anObject >>>> "Dispatch the receiver into anObject" >>>> self type == #dropFilesEvent ifTrue:[^anObject handleDropFiles: >>>> self]. >>>> >>>> it seems to me that sentTo: is a kind of double dispatch but not yet >>>> there. >>>> I do not see here the added value of the check except if this is to cancel >>>> event. >>>> >>>> Stef >>> I guess it's to be consistent with other types of events, and/or make it >>> easy to add a type instvar in the future... >>> Right now all three combinations of type instvar checks (KeyboardEvent), >>> subclassing (DropXEvents), or a mix of the two (MouseEvents) are in use >>> during the double dispatching of input events. >>> You might think subclassing was only used if additional state was needed, >>> but that's only true of MouseEvents, and not DropXEvents... >>> (So yeah, your observation that the type check in DropEvent is unneccesary >>> is correct) >>> >>> It might be nice with a rewrite to rely on subclassing alone, albeit >>> increaseing the number of event classes. (KeyUp, KeyDown, KeyPressed, >>> MouseOver, MouseEnter and MouseLeave for sure, potentially more depending on >>> what action in WindowEvent means) >>> >>> A benefit is you could rewrite processEvents loop to essentially read >>> event := MorphicEvent forBuffer: evtBuf. >>> self handleEvent: event >>> >> yes, that's the idea. but we didn't went further than passing events >> to HandMorph. >> At first stage we want to make sure a lower-level event handling >> (Sensor->World->HandMorph) >> can be replaced with new model, and then we can enter the morphic and >> clean it up more seriously. > Mmmmhmm, isn't it more accurate to say that events flow Sensor -> HandMorph -> World? > (Though, they get pulled in by the consuming world in a polling loop, rather than getting pushed from the flow source) > > Anyways, a proper input event modelling is really independent of Morphic, analogous to the WindowClosed/MorphicWindowClosed naming discussion. > (which also gives a third alternative to double dispatch/case, in that in use registering to them tend to look like case statements, but loosely coupled) > > Cheers, > Henry > > PS: Looking up an example WindowAnnouncement and ran across it; WTF does Nautilus need special NautilusWindowAnnouncement classes for? > As long as your announcer is a Nautilus-specific one rather than the default announcer, that's all the separation that's needed... > In other words; favour application-distinct announcers over duplicate Announcement types. I think it's just because I wasn't aware that this class existed :) I should fix that Ben

Sept. 11, 2012

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