January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] What about a little rename in MouseEvent?

by Nicolas Cellier

Sorry Fernando, The question is can we remove a level of indirection ? And to answer this, you have to consider these other questions: - what was the purpose of this level of indirection ? - do we still need it or not ? I don't feel like your yes/no answer is satisfying, please give more ellaborated arguments. Nicolas 2011/1/24 Fernando Olivero <fernando.olivero(a)usi.ch>: > I agree with the original proposal, because MouseEvents denote the > physical action performed by the user on the hardware, which evidently > has a left, a middle and a right section. Regardless of the action > Morphic associates with each click, #select, #menu, etc... > > Fernando > > On Mon, Jan 24, 2011 at 10:33 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 24 Jan 2011, at 08:25, Marcus Denker wrote: >> >>> On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: >>> >>>> I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. >>>> >>>> Why not lefClick, rightClick and "middleClick"? >>>> >>> >>> Yes. >>> >>> Back in the days, the color buttons where "holy cows". You just could not even suggest to >>> change it. >>> >>> For me, after 13 years of Squeak and later Pharo, I still have no clue which color means what... >>> they have no meaning. There is no green button on my mouse. >>> >>> Â Â Â Marcus >> >> #select, #menu and #extra ? >> >> Then again, touch UI is different again. >> >> Sven >> >> >> >> > >

Jan. 24, 2011

Re: [Pharo-project] splitters in table layout

by Gary Chambers

Well, that is the main intentional difference between having the fast dragging setting on or off ;-) Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, January 20, 2011 9:05 PM Subject: Re: [Pharo-project] splitters in table layout Hi Gary, Indeed, this stops the debugger popping out. However, resizing is not live (only when I mouseUp: does the scroll pane refresh). Is there a quick way to solve this issue, or should we just go with this fix for the moment? Cheers, Doru On 20 Jan 2011, at 12:43, Gary Chambers wrote: > The attached changeset will "fix" this, though perhaps not ideal... > > Perhaps it is time to refactor all the Resizer stuff! > > Regards, Gary > > > ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, January 20, 2011 11:17 AM > Subject: Re: [Pharo-project] splitters in table layout > > > What does this imply? > > Cheers, > Doru > > > On 20 Jan 2011, at 12:09, Gary Chambers wrote: > >> Missed the case where fast dragging setting is enabled.... >> >> Regards, Gary >> >> ----- Original Message ----- From: "Andreas Wacknitz" <a.wacknitz(a)gmx.de> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, January 18, 2011 8:33 PM >> Subject: Re: [Pharo-project] splitters in table layout >> >> >> >> Am 18.01.2011 um 20:58 schrieb Tudor Girba: >> >>> Yes, you missed a changeset Gary sent in the aligning morphs thread (he >>> actually sent two, and you should pick the second one). >>> >>> Cheers, >>> Doru >>> >> Ah, thank you. I have found two messages with changesets from January >> 11th, 2011. >> After I filein the second changeset alas I will get a DNU >> Morph>>doFastWindowReframe: when I move the splitter... >> >> Regards, >> Andreas >> >> >> > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > <EdgeGripFastReframeFix.1.cs> -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Jan. 24, 2011

Re: [Pharo-project] [squeak-dev] Xtreams up to date

by Hannes Hirzel

On 1/23/11, mkobetic(a)gmail.com <mkobetic(a)gmail.com> wrote: > OK, let's try something really simple. The wikipedia page shows a simple > arithmetic expression grammar. Hello Martin Thank you for working out the Wikipedia simple arithmetic expression grammar into a tutorial style text. I worked through it and understood it. I adapted the class names so that it runs in the current Squeak 4.2 out of the box. In addition I edited it slightly. I think it could be added as to the PEGParser class. Maybe somebody else like to check it in addition .... Additional example: Wiki text parsing In the previous mail you mentioned that you'll add the fileout of the class PEGWikiGenerator I did not get the fileout. --Hannes ============================================= PEGParser example Parsing simple arithmetic expressions The following may be copied into a workspace ============================================= "The wikipedia page shows a simple arithmetic expression grammar. Here it is transcribed for Xtreams:" simpleArithmeticExpressionGrammarDescription := ' Number <- [0-9]+ Parenthesised <- "(" Expr ")" Value <- Number / Parenthesised Product <- Value (("*" / "/") Value)* Sum <- Product (("+" / "-") Product)* Expr <- Sum '. "The Value from the wiki grammar was expanded into separate Number and Parethesised expression productions. It'll hopefully will be clear why shortly. You already know how to get a parser from grammar. That's always the same and for anything more complex you'll probably want to cache the parser instead of recreating it every time, but this will do fine for now:" parser := PEGParser parserPEG parse: 'Grammar' stream: simpleArithmeticExpressionGrammarDescription actor: PEGParserParser new. "If you parse the following expression and print the result you'll get" parser parse: 'Expr' stream: '3+4*(10-4)' reading actor: nil {{an OrderedCollection($3) . an OrderedCollection()} . an OrderedCollection({'+' . {an OrderedCollection($4) . an OrderedCollection({'*' . {'(' . {{an OrderedCollection($1 $0) . an OrderedCollection()} . an OrderedCollection({'-' . {an OrderedCollection($4) . an OrderedCollection()}})} . ')'}})}})} "which is roughly formatted manually to provide at least some resemblance of the expression tree" #( #(OrderedCollection ($3 "16r0033") OrderedCollection ()) OrderedCollection (# ('+' #(OrderedCollection ($4 "16r0034") OrderedCollection (# ('*' #( '(' #( #(OrderedCollection ($1 "16r0031" $0 "16r0030") OrderedCollection ()) OrderedCollection (# ('-' #(OrderedCollection ($4 "16r0034") OrderedCollection ())))) ')'))))))) "This not easy to take apart to work with. To do this you need an Actor that will receive rule specific callbacks and do whatever is needed. In this case we would like to evaluate the expression and return the result. We create a subclass of PEGActor called PEGSimpleArithmeticExpressionEvaluator. As we mentioned earlier, the Actor class provides a pragma based mechanism for expressing rule specific callbacks. So for programming the Evaluator class you simply need to write a method for each rule what should be done and annotate it with a pragma. Let's first fill in the 'Number' rule to deal convert the digit collections into numbers:" PEGSimpleArithmeticExpressionEvaluator>>Number: digits <action: 'Number'> ^digits inject: 0 into: [ :total :digit | total * 10 + ('0123456789' indexOf: digit) - 1 ] "With this you can parse numbers" parser parse: 'Expr' stream: '3456' reading actor: PEGSimpleArithmeticExpressionEvaluator new "Print it gives" {{3456 . an OrderedCollection()} . an OrderedCollection()} parser parse: 'Expr' stream: '3+4+5+6+7' reading actor: PEGSimpleArithmeticExpressionEvaluator new "So if you add a method for Sum, that's what it will need to deal with:" Sum: terms <action: 'Sum'> ^terms last inject: terms first into: [ :total :next | (next first = '+') ifTrue: [ total + next last ] ifFalse: [ total - next last ] ] "The Actor pragmas provide another convenience for taking more complex input apart. You can write the above as Sum: first rest: pairs <action: 'Sum' arguments: #(1 2)> ^pairs inject: first into: [ :total :pair | (pair first = '+') ifTrue: [ total + pair last ] ifFalse: [ total - pair last ] ] "The arguments: keyword simply says invoke this method with elements 1 and 2 of the rule input (terms) as arguments. Obviously the method must take the corresponding number of arguments as well. So with the above rules the addition expression should give you 25. " "The Product rule handling is analogous:" Product: first rest: pairs <action: 'Product' arguments: #(1 2)> ^pairs inject: first into: [ :total :pair | (pair first = '*') ifTrue: [ total * pair last ] ifFalse: [ total / pair last ] ] "Finally the parenthesised expression is rather simple:" Parenthesised: expression <action: 'Parenthesised' arguments: #(2)> ^expression "It receives a three element array: the left bracket, the expression inside and the right bracket. All we really need to do is return the expression in the middle. The above is using the arguments: pragma again to achieve that, the following would be equivalent:" Parenthesised: expression <action: 'Parenthesised'> ^expression at: 2 "By now is hopefully clearer why it was useful to factor the Value definition out into separate Number and Parenthesised rule. Otherwise we'd have to handle both cases in a single Value: method, which would make the code messier. A final parsing example" parser parse: 'Expr' stream: '((3+4)*2-4)/2' reading actor: PEGSimpleArithmeticExpressionEvaluator new 5

Jan. 24, 2011

[Pharo-project] Issue 3586 in pharo: Rename color buttons in MouseEvent

by pharo＠googlecode.com

Status: Accepted Owner: guillerm...(a)gmail.com New issue 3586 by guillerm...(a)gmail.com: Rename color buttons in MouseEvent http://code.google.com/p/pharo/issues/detail?id=3586 I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. Why not lefClick, rightClick and "middleClick"?

Jan. 24, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Alexandre Bergel

Thanks Marcus, Alexandre On 24 Jan 2011, at 07:01, Marcus Denker wrote: > On Thu, Jan 20, 2011 at 6:41 PM, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: >> Hello all, >> >> We are happy to introduce you Hapao, an innovative test coverage tool which >> gives you an intuitive graphical representation to visually assess the >> quality of the coverage. >> >> For more information and download you can visit us at: >> http://hapao.dcc.uchile.cl/ >> Of course, all feedback is always welcome :) >> > Very nice! > > One small thing: the dialog selecting the packages at the beginning should > label the button "continue"", not "terminate" (which sounds like cancel to me). > > I added a blog post: http://pharo-project.org/news > > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 24, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by Guillermo Polito

And if you swap mouse buttons, you are replacing left button by right button ;). I open a ticket. On Mon, Jan 24, 2011 at 7:51 AM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > I agree with the original proposal, because MouseEvents denote the > physical action performed by the user on the hardware, which evidently > has a left, a middle and a right section. Regardless of the action > Morphic associates with each click, #select, #menu, etc... > > Fernando > > On Mon, Jan 24, 2011 at 10:33 AM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > > > On 24 Jan 2011, at 08:25, Marcus Denker wrote: > > > >> On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: > >> > >>> I hate yellowButtonPressed and redButtonPressed and blueButtonPressed > messages. > >>> > >>> Why not lefClick, rightClick and "middleClick"? > >>> > >> > >> Yes. > >> > >> Back in the days, the color buttons where "holy cows". You just could > not even suggest to > >> change it. > >> > >> For me, after 13 years of Squeak and later Pharo, I still have no clue > which color means what... > >> they have no meaning. There is no green button on my mouse. > >> > >> Marcus > > > > #select, #menu and #extra ? > > > > Then again, touch UI is different again. > > > > Sven > > > > > > > > > >

Jan. 24, 2011

Re: [Pharo-project] Issue 3545 in pharo: FEATURE: Multiple Worlds

by pharo＠googlecode.com

Comment #7 on issue 3545 by sean.p.d...(a)gmail.com: FEATURE: Multiple Worlds http://code.google.com/p/pharo/issues/detail?id=3545 the changeset also includes a class comment for WorldManager that wasn't in the original SLICE

Jan. 24, 2011

Re: [Pharo-project] Issue 3545 in pharo: FEATURE: Multiple Worlds

by pharo＠googlecode.com

Comment #6 on issue 3545 by sean.p.d...(a)gmail.com: FEATURE: Multiple Worlds http://code.google.com/p/pharo/issues/detail?id=3545 I collected the changes into a changeset so people can play with it in 1.1.1. Maybe it'd be easier to integrate also. Attachments: MultipleWorlds.2.cs 3.5 KB

Jan. 24, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by Fernando Olivero

I agree with the original proposal, because MouseEvents denote the physical action performed by the user on the hardware, which evidently has a left, a middle and a right section. Regardless of the action Morphic associates with each click, #select, #menu, etc... Fernando On Mon, Jan 24, 2011 at 10:33 AM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 24 Jan 2011, at 08:25, Marcus Denker wrote: > >> On Jan 24, 2011, at 5:39 AM, Guillermo Polito wrote: >> >>> I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. >>> >>> Why not lefClick, rightClick and "middleClick"? >>> >> >> Yes. >> >> Back in the days, the color buttons where "holy cows". You just could not even suggest to >> change it. >> >> For me, after 13 years of Squeak and later Pharo, I still have no clue which color means what... >> they have no meaning. There is no green button on my mouse. >> >> Â Â Â Marcus > > #select, #menu and #extra ? > > Then again, touch UI is different again. > > Sven > > > >

Jan. 24, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by Nicolas Cellier

Don't take me wrong. I perfectly agree that colors have no meaning. They had once upon a time on the dorado, but we don't care. What I say is that there is a level of indirection between physical button and semantic buttons: (left, middle, right) -> logical buttons (whatever you call them) -> semantic buttons (operate, menu, extra) So either you keep the logical indirection, or you remove it. If you keep it, the naming is not that obvious and has to be abstract. So the colours are not a bad choice from this POV. Call it alpha, beta gamma if you will, but then you are changing things just for the sake of changing. If you remove the indirection, then you have to wonder if you don't loose something, and that was the meaning behind my post. I don't have the answer to this one, but you have to think of it. It's a bit boring to explain one's joke, sorry for that ;). Nicolas 2011/1/24 Marcus Denker <marcus.denker(a)inria.fr>: > > On Jan 24, 2011, at 9:36 AM, Nicolas Cellier wrote: > >> Sure, we got the right to change historical code. >> >> But beware, naming actions with physical button positioncould be misleading... >> ... it does not take into account the logical indirection. >> >> We could as well use intention revealing names like selectButton >> operateButton haloButton... >> .. Err, no more halo in Pharo, these names are prematurely frozen and >> don't take future evolutions into account. >> >> Oh, we need some more neutral naming scheme, but for sure, something >> less colorfull that these childish st-80 and e toys. >> I suggest you use whiteButton greyButton blackButton, or maybe >> paleBlueButton, lightCyanButton to be more inline with an aqua theme > > *no* Colors have no *meaning* in this context. I can not even tell you the > three colors we have now. And not at all which is supposed to be the middle one. > > Colors for buttons make no sense *at all* if your buttons have no colors. > > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Jan. 24, 2011