March 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Damien Pollet

On 19 March 2018 at 13:40, Petr Fischer <petr.fischer(a)me.com> wrote: > > How would you define the semantics of > > > > 123 ifTrue: [ ... ] > > 123 is not "true", so, ignore the block. > What anout 123 ifFalse: [ â¦ ], then, given that 123 is not false either?

March 19, 2018

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Petr Fischer

> Infinite recursion ? > > You use #ifTrue: in your implementation of Object>>#ifTrue: > > Plus, non-booleans cannot meaningfully respond. > > How would you define the semantics of > > 123 ifTrue: [ ... ] 123 is not "true", so, ignore the block. Do the ifTrue block only if the receiver is instance of True (true). Everything else is not "true" :) I missed the recursion, yes, but it could be done another way. > > > On 19 Mar 2018, at 10:18, Petr Fischer <petr.fischer(a)me.com> wrote: > > > > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: implementation. > > > > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True and False classes, so, we can send this message to the boolean expressions (instances) only, otherwise DND occurs. > > > > But we can also define one universal ifTrue: right in the Object class, in this style: > > > > Object>>ifTrue: .... > > (self = true) ifTrue: [ ... ]. > > > > then, we can send ifTrue: message to ANY object and it will work correctly without DND exception on non-boolean objects. > > > > Is something bad about this idea? > > > > Thanks! pf > > > >

March 19, 2018

Re: [Pharo-users] Disabling GTSpotter dive in

by Ben Coman

On 19 March 2018 at 16:05, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Certainly. > > Basically I want to avoid a situation, where diving in would result in an > empty spotter: > > > > > > So instead I would like to remove the dive in capability (both the icon, > and the action), when the result will be empty. (And of course keep it if > there will be something). > Rather than removing the icon, please consider modifying the icon to include a red cross or similar, with a tooltip indicating no results. I believe that is more explicit than an absent icon. cheers -ben > > Ideally it should be possible to define it in the "parent" step, because > sometimes I know there will be no further steps, and sometimes the result > is simply empty (in which case I might still want to show that there are > zero children). > > Thanks, > Peter > > On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi, >> >> I am not sure I understand the issue. Can you re-explain it please? >> >> Cheers, >> Doru >> >> >> > On Mar 16, 2018, at 8:02 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > >> > correction: spotterForRenderingShapesFor: is not in Pharo 6.1 (it's >> added by Roassal2GT) >> > >> > On Fri, Mar 16, 2018 at 8:01 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > Hi, >> > >> > is it possible to disable GTSpotter dive in functionality when the >> result would be empty? >> > >> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no >> matter what there will be at least one processor (at least the "parent" >> one, which is weird). >> > >> > Also there are two spotter extensions directly on Object (Pharo 6.1) >> > * spotterForRenderingShapesFor: >> > * spotterRePropertiesFor: >> > >> > which are always applied... but canDiveIn: was returing true even when >> I disabled them. >> > >> > Thanks, >> > Peter >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> >> >

March 19, 2018

Re: [Pharo-users] inquiring question about ifTrue: implementation

by Sven Van Caekenberghe

Infinite recursion ? You use #ifTrue: in your implementation of Object>>#ifTrue: Plus, non-booleans cannot meaningfully respond. How would you define the semantics of 123 ifTrue: [ ... ] > On 19 Mar 2018, at 10:18, Petr Fischer <petr.fischer(a)me.com> wrote: > > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: implementation. > > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True and False classes, so, we can send this message to the boolean expressions (instances) only, otherwise DND occurs. > > But we can also define one universal ifTrue: right in the Object class, in this style: > > Object>>ifTrue: .... > (self = true) ifTrue: [ ... ]. > > then, we can send ifTrue: message to ANY object and it will work correctly without DND exception on non-boolean objects. > > Is something bad about this idea? > > Thanks! pf >

March 19, 2018

inquiring question about ifTrue: implementation

by Petr Fischer

Hello, I have some sort of philosophical question about ifTrue:/ifFalse: implementation. Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in True and False classes, so, we can send this message to the boolean expressions (instances) only, otherwise DND occurs. But we can also define one universal ifTrue: right in the Object class, in this style: Object>>ifTrue: .... (self = true) ifTrue: [ ... ]. then, we can send ifTrue: message to ANY object and it will work correctly without DND exception on non-boolean objects. Is something bad about this idea? Thanks! pf

March 19, 2018

Re: [Pharo-users] Disabling GTSpotter dive in

by Tudor Girba

That can be an option. Doru > On Mar 19, 2018, at 9:52 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > So I imagine something like the following > > spotterFieldsFor: aStep > <spotterOrder: 20> > ^ aStep listProcessor > title: 'Fields'; > canDiveIn: [ false "or some dynamic condition" ]; > ... > > On Mon, Mar 19, 2018 at 9:05 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Certainly. > > Basically I want to avoid a situation, where diving in would result in an empty spotter: > > <image.png> > > <image.png> > > > So instead I would like to remove the dive in capability (both the icon, and the action), when the result will be empty. (And of course keep it if there will be something). > > Ideally it should be possible to define it in the "parent" step, because sometimes I know there will be no further steps, and sometimes the result is simply empty (in which case I might still want to show that there are zero children). > > Thanks, > Peter > > On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am not sure I understand the issue. Can you re-explain it please? > > Cheers, > Doru > > > > On Mar 16, 2018, at 8:02 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > correction: spotterForRenderingShapesFor: is not in Pharo 6.1 (it's added by Roassal2GT) > > > > On Fri, Mar 16, 2018 at 8:01 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > > > is it possible to disable GTSpotter dive in functionality when the result would be empty? > > > > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no matter what there will be at least one processor (at least the "parent" one, which is weird). > > > > Also there are two spotter extensions directly on Object (Pharo 6.1) > > * spotterForRenderingShapesFor: > > * spotterRePropertiesFor: > > > > which are always applied... but canDiveIn: was returing true even when I disabled them. > > > > Thanks, > > Peter > > > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > > > -- www.tudorgirba.com www.feenk.com âThe smaller and more pervasive the hardware becomes, the more physical the software gets."

March 19, 2018

Re: [Pharo-users] Disabling GTSpotter dive in

by Peter UhnÃ¡k

So I imagine something like the following spotterFieldsFor: aStep <spotterOrder: 20> ^ aStep listProcessor title: 'Fields'; *canDiveIn: [ false "or some dynamic condition" ];* ... On Mon, Mar 19, 2018 at 9:05 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Certainly. > > Basically I want to avoid a situation, where diving in would result in an > empty spotter: > > > > > > So instead I would like to remove the dive in capability (both the icon, > and the action), when the result will be empty. (And of course keep it if > there will be something). > > Ideally it should be possible to define it in the "parent" step, because > sometimes I know there will be no further steps, and sometimes the result > is simply empty (in which case I might still want to show that there are > zero children). > > Thanks, > Peter > > On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi, >> >> I am not sure I understand the issue. Can you re-explain it please? >> >> Cheers, >> Doru >> >> >> > On Mar 16, 2018, at 8:02 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > >> > correction: spotterForRenderingShapesFor: is not in Pharo 6.1 (it's >> added by Roassal2GT) >> > >> > On Fri, Mar 16, 2018 at 8:01 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> > Hi, >> > >> > is it possible to disable GTSpotter dive in functionality when the >> result would be empty? >> > >> > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no >> matter what there will be at least one processor (at least the "parent" >> one, which is weird). >> > >> > Also there are two spotter extensions directly on Object (Pharo 6.1) >> > * spotterForRenderingShapesFor: >> > * spotterRePropertiesFor: >> > >> > which are always applied... but canDiveIn: was returing true even when >> I disabled them. >> > >> > Thanks, >> > Peter >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> >> >

March 19, 2018

Re: [Pharo-users] Disabling GTSpotter dive in

by Peter UhnÃ¡k

Certainly. Basically I want to avoid a situation, where diving in would result in an empty spotter: So instead I would like to remove the dive in capability (both the icon, and the action), when the result will be empty. (And of course keep it if there will be something). Ideally it should be possible to define it in the "parent" step, because sometimes I know there will be no further steps, and sometimes the result is simply empty (in which case I might still want to show that there are zero children). Thanks, Peter On Sun, Mar 18, 2018 at 10:01 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am not sure I understand the issue. Can you re-explain it please? > > Cheers, > Doru > > > > On Mar 16, 2018, at 8:02 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > correction: spotterForRenderingShapesFor: is not in Pharo 6.1 (it's > added by Roassal2GT) > > > > On Fri, Mar 16, 2018 at 8:01 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > > > is it possible to disable GTSpotter dive in functionality when the > result would be empty? > > > > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no > matter what there will be at least one processor (at least the "parent" > one, which is weird). > > > > Also there are two spotter extensions directly on Object (Pharo 6.1) > > * spotterForRenderingShapesFor: > > * spotterRePropertiesFor: > > > > which are always applied... but canDiveIn: was returing true even when I > disabled them. > > > > Thanks, > > Peter > > > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things are difficult to teach." > > > > > >

March 19, 2018

Re: [Pharo-users] Disabling GTSpotter dive in

by Tudor Girba

Hi, I am not sure I understand the issue. Can you re-explain it please? Cheers, Doru > On Mar 16, 2018, at 8:02 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > correction: spotterForRenderingShapesFor: is not in Pharo 6.1 (it's added by Roassal2GT) > > On Fri, Mar 16, 2018 at 8:01 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is it possible to disable GTSpotter dive in functionality when the result would be empty? > > I've tried looking at GTSpotterStep>>canDiveIn: but it seems that no matter what there will be at least one processor (at least the "parent" one, which is weird). > > Also there are two spotter extensions directly on Object (Pharo 6.1) > * spotterForRenderingShapesFor: > * spotterRePropertiesFor: > > which are always applied... but canDiveIn: was returing true even when I disabled them. > > Thanks, > Peter > -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

March 18, 2018

Re: [Pharo-users] MiniScheme in Pharo

by Cyril Ferlicot

On dim. 18 mars 2018 at 16:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote > > I would like to get feedback and fix > > what can be fixed. > > Is there a public link to the source? It would be easiest to submit fixes > via PRs instead of ML :) > > Probably https://github.com/SquareBracketAssociates/Booklet-AMiniSchemeInPharo > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > -- Cyril Ferlicot https://ferlicot.fr

March 18, 2018