- Pharo-dev - lists.pharo.org

Also "create method" in traits

by Martin Dias

Hi I informally reported this "feature requirement" today to Sebastian, but I wanted to post it to all. When the debugger is shown after a MNU, the developer can press the button "Create method". A list of the superclasses is shown to the developer, so he/she can choose in which class crate the method. In addition to superclasses, it would be nice to show the traits that the classes use, since developer might want to create the method there. Cheers, MartÃn

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Otto Behrens

It feels to me as if this code wants to be on the temp. So perhaps, > | temp | > temp := <a long expression>. > temp <aComplexTest> > ifTrue: [ temp <something> ] > ifFalse: [ temp <something else> ]. can become <a long expression> doSomething and on Temp: doSomething self <aComplexTest> ifTrue: [ self <something> ] ifFalse: [ self <something else> ] It often works out nicer if you move the code around closer to where it belongs. Make <a long expression> a method somewhere and it may end up being simpler. my2c

June 18, 2013

Re: [Pharo-dev] how to define menu in spec

by Benjamin

For menus, there is nothing spec related here (yet). If you use pragmas, for defining your menus/shortcuts, there is (or was) a specific registration class supporting made for defining both in one. It was never adopted, so I do not know where to find it again, sorry Ben On Jun 18, 2013, at 1:48 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi StÃ©phane, > > look into the AltBrowser code. You'll find commands that are both shortcuts and menu items (subclasses of AltCommand). > > https://github.com/ThierryGoubier/AltBrowser/blob/master/Alt-Browser.packag… > > https://github.com/ThierryGoubier/AltBrowser/blob/master/Alt-Browser.packag… > > And it's more or less lifted from the OmniBrowser code, by the way. > > (Kind of convenient to link to st code from github) > > Thierry > > Le 18/06/2013 13:34, StÃ©phane Ducasse a Ã©crit : >> Hi ben >> >> I want to define some menu for my logging Tool UI. And I was wondering how >> >> - define menu >> - avoid duplication with shortcut >> >> I looked at the EyeInspector but it is not clear to me. Do you have a >> better example I could read? >> >> Stef >> >> >> > > -- > 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 >

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Benjamin

You may not be the only one, but you probably are the only whose job is to address Pharo issues :) Ben On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 June 2013 11:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Once igor finishes the TxModel and Athens it was planned to address the Delay problem. >> > > I don't think i am the only one who capable to fix it. :) > > Something broken in restoring Delay(s) after image restart (they > hanging for too far in the future). > That's my impression. > From other side, i do not see why Cookie should use [ Delay forEons wait] fork. > Instead, i would just replace implementation with code which checks > the time before giving answer > of cookie value. > So, if you won't use cookie value in heavy numerical-crunchy > calculations, this is completely fine. > >> Stef > > > > > -- > Best regards, > Igor Stasenko. >

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by Esteban Lorenzano

On Jun 18, 2013, at 1:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 June 2013 13:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> >> >> On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> well... afaik, no one outside pharo community is using the configurations, >>> the other guys on vm-dev prefer the old way of doing things. >>> >>> also, the group "pharo" is intended to include the things necessary to >>> produce a "pharo vm"... this is what time ago was in the >>> ConfigurationOfPharoVM. That means: you can produce a CogVM without loading >>> group "pharo", but not a Pharo VM. >> >> >> so so... Because without the compatibility package the configuration does >> not even load in Pharo, and then you can build air only :). >> > > and even more, your changes imply that code will be loaded into Pharo > image with FS. > So, there's two concerns: > - whether ConfigurationOfCog should load cleanly on squeak image(s) honestly, we should not take that into account. Squeak guys are not using configuration to build their VMs, and then we should not care about keeping it compatible (in fact, I doubt is compatible now). Not that I would not like that they use it, but if they don't, I prefer to use the few time we all have into something more productive :) > - whether you can use loaded stuff to produce non-pharo VM yes this is an issue, but as the configurations are made, if you are able to build a pharovm, you are also able to build a cogvm. > > for first one, i don't remember when the last time i tried it and it > will probably won't work, so no big deal > for second one, it is important to keep lettling people choose what > they want to build. exactly :) Esteban > > > > -- > Best regards, > Igor Stasenko. >

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by Igor Stasenko

On 18 June 2013 13:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> well... afaik, no one outside pharo community is using the configurations, >> the other guys on vm-dev prefer the old way of doing things. >> >> also, the group "pharo" is intended to include the things necessary to >> produce a "pharo vm"... this is what time ago was in the >> ConfigurationOfPharoVM. That means: you can produce a CogVM without loading >> group "pharo", but not a Pharo VM. > > > so so... Because without the compatibility package the configuration does > not even load in Pharo, and then you can build air only :). > and even more, your changes imply that code will be loaded into Pharo image with FS. So, there's two concerns: - whether ConfigurationOfCog should load cleanly on squeak image(s) - whether you can use loaded stuff to produce non-pharo VM for first one, i don't remember when the last time i tried it and it will probably won't work, so no big deal for second one, it is important to keep lettling people choose what they want to build. -- Best regards, Igor Stasenko.

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Goubier Thierry

Le 18/06/2013 13:41, Frank Shearar a Ã©crit : > On 18 June 2013 12:35, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 18/06/2013 13:09, Esteban Lorenzano a Ã©crit : >> >>> I do not like it :) >>> >>> also, you already have #in: >>> which is more generic and allows simplifications: >>> >>> <my complex expression> in: [ :blah | >>> blah = myTest >>> ifTrue: [ blah some ] ] >>> ifFalse: [ blah other ] ] >> >> >> This is cool :) Didn't knew about this one. > > It's a lot like `let` in other languages (Haskell, the Lisps, and so on). Yes, of course, but I was nicely surprised to see it here :) >> Could we use do: in the same way ? Because in: is in a way the same as >> >> {<my complex expression>} do: [ :blah | >> >> blah = myTest >> ifTrue: [ blah some ] >> ifFalse: [ blah other ] ] >> >> With a different return value. > > No: #do: signals that you're doing something entirely for a side > effect. But if you said `{<my complex expression} collect: [:blah | > ...]` then I'd agree with you. Yes. I'd even use`({<my complex expression>} collect: [:blah | > ...]) first` just to be sure ! 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

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by Camillo Bruni

On 2013-06-18, at 13:26, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> well... afaik, no one outside pharo community is using the configurations, >> the other guys on vm-dev prefer the old way of doing things. >> >> also, the group "pharo" is intended to include the things necessary to >> produce a "pharo vm"... this is what time ago was in the >> ConfigurationOfPharoVM. That means: you can produce a CogVM without loading >> group "pharo", but not a Pharo VM. >> > > so so... Because without the compatibility package the configuration does > not even load in Pharo, and then you can build air only :). that's cool I like that you pushed this for 2.0 :)

June 18, 2013

Re: [Pharo-dev] how to define menu in spec

by Goubier Thierry

Hi StÃ©phane, look into the AltBrowser code. You'll find commands that are both shortcuts and menu items (subclasses of AltCommand). https://github.com/ThierryGoubier/AltBrowser/blob/master/Alt-Browser.packag… https://github.com/ThierryGoubier/AltBrowser/blob/master/Alt-Browser.packag… And it's more or less lifted from the OmniBrowser code, by the way. (Kind of convenient to link to st code from github) Thierry Le 18/06/2013 13:34, StÃ©phane Ducasse a Ã©crit : > Hi ben > > I want to define some menu for my logging Tool UI. And I was wondering how > > - define menu > - avoid duplication with shortcut > > I looked at the EyeInspector but it is not clear to me. Do you have a > better example I could read? > > Stef > > > -- 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

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Frank Shearar

On 18 June 2013 12:35, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 18/06/2013 13:09, Esteban Lorenzano a Ã©crit : > >> I do not like it :) >> >> also, you already have #in: >> which is more generic and allows simplifications: >> >> <my complex expression> in: [ :blah | >> blah = myTest >> ifTrue: [ blah some ] ] >> ifFalse: [ blah other ] ] > > > This is cool :) Didn't knew about this one. It's a lot like `let` in other languages (Haskell, the Lisps, and so on). > Could we use do: in the same way ? Because in: is in a way the same as > > {<my complex expression>} do: [ :blah | > > blah = myTest > ifTrue: [ blah some ] > ifFalse: [ blah other ] ] > > With a different return value. No: #do: signals that you're doing something entirely for a side effect. But if you said `{<my complex expression} collect: [:blah | ...]` then I'd agree with you. > Thierry > > >> and also the advantage is that you are not restricted to #ifTrue:ifFalse: >> >> Esteban >> >> On Jun 18, 2013, at 1:05 PM, Goubier Thierry <thierry.goubier(a)cea.fr> >> wrote: >> >>> >>> >>> Le 18/06/2013 12:27, Camille Teruel a Ã©crit : >>>> >>>> >>>> On 18 juin 2013, at 11:20, Goubier Thierry wrote: >>>> >>>>> Hi Camille, >>>>> >>>>> It's not bad as things goes, because it does look a bit like >>>>> non-smalltalk code (i.e. the if then else structure) except that the >>>>> precise meaning is very much Smalltalk : >>>> >>>> >>>> Ok the name may be confusing. >>>> So if you rename it to something like #if:do:elseDo:, it would be more >>>> smalltalkish and there is no confusion with classical if-then-else. >>> >>> >>> Maybe, that would help. >>> >>>>> if: has a receiver, and there is a not so intuitive relationship >>>>> between the bloc parameters and the receiver. >>>> >>>> >>>> Talking to an arbitrary object is the goal, since booleans are not very >>>> talkative kind of object. >>>> Compare >>>> >>>> | temp | >>>> temp := <complexExpression> >>>> temp isNil ifTrue: [...] ifFalse: [... temp ...] >>>> >>>> with: >>>> >>>> <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] >>>> >>>> ifNil:ifNotNil: is not better only because it is shorter, it is better >>>> because I am talking to the object I am auditing, not a stupid boolean >>>> that knows nothing else but its truth value. >>> >>> >>> Yes, but I know firsthand (because I used Smalltalk before that idiom was >>> introduced) that it represent one more idiom to learn, and it's still not >>> familiar. >>> >>> The same goes with withStreamDo: or what is that idiom again I sometimes >>> encounter. >>> >>>>> Honestly, as far as code reviews goes, I'll prefer the temp >>>>> refactoring. Understandable without having to search for the >>>>> implementors of #if:then:else: >>>> >>>> >>>> I know this would break a long time tradition and people may not like >>>> it, so that's a question of taste and style, not understandability. >>>> There would be only one implementor, the implementation is really simple >>>> and the selector is explicit. >>> >>> >>>> Anyone can get use to it in less than 2 min. >>> >>> >>> It's one more thing to get used to and to explain to beginners in say 10 >>> minutes per idiom... (describe, give an example, let them practice, rinse >>> and repeat for each idiom). >>> >>> Add all the new idioms and, instead of explaining Smalltalk in half a >>> day, you spend a few days doing explaining all those idioms and not doing >>> more interesting stuff. >>> >>> Soon, you end up like ocaml, where your minimum introduction time is a >>> week, not half a day. >>> >>>> Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: >>>> ,... every time? >>> >>> >>>> No because people learned what they do when they learned Smalltalk, and >>>> I'm sure it didn't get them more than a few minutes. >>> >>> >>> Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, your >>> variant of if-else, and, and ... On some of those, I have to look for the >>> implementors, and I'm really happy to benefit from the smart suggestions in >>> the new browsers. (Additionally, code patterns using cull: in pharo more >>> often than not are very poorly documented about the arguments that are given >>> to the block). >>> >>> Smalltalk is disruptive enough as it is (and still is after all those >>> years) to try not to make it more complex. I'd prefer efforts making obvious >>> really complex patterns instead of idioms with a not so great cognitive load >>> to effectiveness. >>> >>> I'd be happy to have a shorter list of methods and extensions on Object, >>> as well :) >>> >>> 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 >>> >> >> >> >> > > -- > 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 >

June 18, 2013