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

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

by Igor Stasenko

On 11 September 2012 14:35, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> 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. > rofl.. you managed to force me to say "wtf" loudly, just after i seen these two methods. Congratulations! :) And after looking at those classes, i found that those checks is completely useless because they are always yielding true: DropEvent>>type ^#dropEvent DropFilesEvent>>type ^#dropFilesEvent and dispatch is always performed. And i don't see why would anyone want to cancel event in such fashion, because if you don't wanna handle it, then just don't send #sentTo: or make sure that end receiver of double-dispatch just ignores such kind of events. I must admit, that a double-dispatch is one of my favorite hammers i use , because i think it one of the best ways for dealing with polymorphism. But before i started using smalltalk i almost never used double-dispatch in my code, and in other places where i found it , was confusing me a lot.. This is because in other languages you tend to use case statements instead, because the amount of coding to implement double-dispatch is too verbose comparing to little case-statement .. this is of course says a lot about expressive power of smalltalk.. and of course, it would be much more difficult to determine if given piece of code actually a double-dispatch or not, unless you can see all implementors & senders using browser, but instead will have to go through multiple files to determine that (because again, most so-called OO languages best practices saying that you should use one file per class). -- Best regards, Igor Stasenko.

Sept. 11, 2012

[Pharo-project] Refactoring Tests

by Camillo Bruni

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

Sept. 11, 2012

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

by Henrik Sperre Johansen

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 (What is recorded in recentModifiers should be queried directly from event during handling, not through HandMorph) And it would also make rewriting handleEvent: to something less... intrusive wrt Event modelling a much simpler task later on. Cheers, Henry

Sept. 11, 2012

[Pharo-project] feature idea - Watcher

by Ben Coman

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

Sept. 11, 2012

[Pharo-project] Keymapping KMShortcut combining

by Goubier Thierry

Hi, Is it possible in Keymapping to have an alternative as shortcut ? I would like to map Tab/Shift Tab and Ctrl Tab/Shift Ctrl Tab to get next/previous focus to work with Spec, and I would like to be able to return a keystroke as Character tab | Character tab ctrl. For those interested, I'm trying to look at http://code.google.com/p/pharo/issues/detail?id=6657 and: http://code.google.com/p/pharo/issues/detail?id=6656 I have solutions for both : code that does 6657, and a way to disable all legacy shortcuts for 6656 for Spec applications on a per instance basis, without overriding or removing any existing code. 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] Making Pharo 2.0 usable

by Alexandre Bergel

>> 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. > > it's hardly a one-man job, nevertheless motivation is always nice! I do not think so :-) This mailing list is full of smart young guys who dream about a better World! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2012

Re: [Pharo-project] Making Pharo 2.0 usable

by Camillo Bruni

On 2012-09-11, at 14:47, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > 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. it's hardly a one-man job, nevertheless motivation is always nice!

Sept. 11, 2012

Re: [Pharo-project] SmallLint and Manifest

by Camillo Bruni

On 2012-09-11, at 13:46, Simon Allier <simon.allier(a)inria.fr> wrote: > Thank for the feedback. > On Sep 11, 2012, at 12:06 PM, Camillo Bruni wrote: > >> hey, I almost got it running :) >> >> - I got an error on ConfigurationOfRefactoringBrowser in the latest 2.0 image. >> However if I manually load all the packages from the squeaksource repos it works :) >> > I dont have any problem for loading the configuration in the last pharo 2.0. sorry, you're right must be some strange image setup of mine...

Sept. 11, 2012

[Pharo-project] Making Pharo 2.0 usable

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 11, 2012

[Pharo-project] Event smell...

by StÃ©phane Ducasse

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

Sept. 11, 2012