Connectors for 4.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Connectors for 4.2

Ken G. Brown
I see after doing some followup after a note from Ken Causey on #squeak that the 4.2-Full-Install on squeaksource <http://squeaksource.com/Connectors/4.2-Full-Install.mcm> installs 'Connectors-cmm.193' but the one on SqueakMap <http://map.squeak.org/package/e0dd4a24-c004-4e98-848e-251bd1229d81/autoversion/5> uses 'Connectors-cmm.196', otherwise they are the same.

Looks like perhaps <http://squeaksource.com/Connectors/4.2-Full-Install.mcm> should be updated?

Looks like currently the Installer command for installing the latest Connectors into Squeak 4.2 then is:

Installer sm install: 'Connectors(4.2)'.

Ken

Reply | Threaded
Open this post in threaded view
|

Re: Connectors for 4.2

Göran Krampe
On 02/10/2011 01:46 AM, Ken G. Brown wrote:
> I see after doing some followup after a note from Ken Causey on #squeak that the 4.2-Full-Install on squeaksource<http://squeaksource.com/Connectors/4.2-Full-Install.mcm>  installs 'Connectors-cmm.193' but the one on SqueakMap<http://map.squeak.org/package/e0dd4a24-c004-4e98-848e-251bd1229d81/autoversion/5>  uses 'Connectors-cmm.196', otherwise they are the same.
>
> Looks like perhaps<http://squeaksource.com/Connectors/4.2-Full-Install.mcm>  should be updated?
>
> Looks like currently the Installer command for installing the latest Connectors into Squeak 4.2 then is:
>
> Installer sm install: 'Connectors(4.2)'.

Yeah, this package is actaully the first added using a nice scheme
hacked up by Chris Muller in SqueakMap - but he should be the one who
tells us more of it. :)

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Object>>is:

David T. Lewis
We had a good deal of discussion earlier about adding Object>>is:
with an inconclusive outcome:
  http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html

Igor's original proposal is:
  http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html

I have been tinkering around with Juan's SimpleMorphic in hopes of
getting it running in Squeak alongside MVC and Morphic, and it would
be convenient to have the default implementation of #is: in the image
so I don't have to put it in a package override.

Any strong objections?

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Igor Stasenko
On 11 February 2011 02:28, David T. Lewis <[hidden email]> wrote:

> We had a good deal of discussion earlier about adding Object>>is:
> with an inconclusive outcome:
>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html
>
> Igor's original proposal is:
>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html
>
> I have been tinkering around with Juan's SimpleMorphic in hopes of
> getting it running in Squeak alongside MVC and Morphic, and it would
> be convenient to have the default implementation of #is: in the image
> so I don't have to put it in a package override.
>

Just yesterday i had  discussion about this with people in the lab. I
can't say that i heard something new regarding this,
and not saying that i'd like to resurrect the discussion.
So, in short: there was no objection concerning getting rid of isXXX
in favor of using #is: method.
The only thing which still looks controversial is too simple default
implementation which answers false.

To my current opinion, Juan's variant is preferable. :) Yes. it should
answer false and don't contain any extra logic , like trying to follow
class hierarchy etc.
Because it serves to replace isXXXX pattern, and not adding something
new (i.e. more 'userful'). So, answering false for Object class fits
well for this purpose.

And of course solution to that problem is simple:
 - avoid writing code in style, which require isXXX tests and then
branching. Nicely written code should use message dispatch instead.
Too bad, we are not living in perfect world :)

> Any strong objections?
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Levente Uzonyi-2
On Fri, 11 Feb 2011, Igor Stasenko wrote:

> On 11 February 2011 02:28, David T. Lewis <[hidden email]> wrote:
>> We had a good deal of discussion earlier about adding Object>>is:
>> with an inconclusive outcome:
>>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html
>>
>> Igor's original proposal is:
>>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html
>>
>> I have been tinkering around with Juan's SimpleMorphic in hopes of
>> getting it running in Squeak alongside MVC and Morphic, and it would
>> be convenient to have the default implementation of #is: in the image
>> so I don't have to put it in a package override.
>>
>
> Just yesterday i had  discussion about this with people in the lab. I
> can't say that i heard something new regarding this,
> and not saying that i'd like to resurrect the discussion.
> So, in short: there was no objection concerning getting rid of isXXX
> in favor of using #is: method.
What about performance?

> The only thing which still looks controversial is too simple default
> implementation which answers false.
>
> To my current opinion, Juan's variant is preferable. :) Yes. it should
> answer false and don't contain any extra logic , like trying to follow
> class hierarchy etc.
> Because it serves to replace isXXXX pattern, and not adding something
> new (i.e. more 'userful'). So, answering false for Object class fits
> well for this purpose.
>
> And of course solution to that problem is simple:
> - avoid writing code in style, which require isXXX tests and then
> branching. Nicely written code should use message dispatch instead.
> Too bad, we are not living in perfect world :)
Is it better to flood superclasses with no-op extension methods?


Levente

>
>> Any strong objections?
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

David T. Lewis
On Fri, Feb 11, 2011 at 02:51:26AM +0100, Levente Uzonyi wrote:

> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>
> >On 11 February 2011 02:28, David T. Lewis <[hidden email]> wrote:
> >>We had a good deal of discussion earlier about adding Object>>is:
> >>with an inconclusive outcome:
> >>?http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html
> >>
> >>Igor's original proposal is:
> >>?http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html
> >>
> >>I have been tinkering around with Juan's SimpleMorphic in hopes of
> >>getting it running in Squeak alongside MVC and Morphic, and it would
> >>be convenient to have the default implementation of #is: in the image
> >>so I don't have to put it in a package override.
> >>
> >
> >Just yesterday i had  discussion about this with people in the lab. I
> >can't say that i heard something new regarding this,
> >and not saying that i'd like to resurrect the discussion.
> >So, in short: there was no objection concerning getting rid of isXXX
> >in favor of using #is: method.
>
> What about performance?

I do not think that Juan would have chosen to use the #is: idiom for
his Cuis Morphic implementation if he thought that performance would
be a problem. It seems to work well.

>
> >The only thing which still looks controversial is too simple default
> >implementation which answers false.
> >
> >To my current opinion, Juan's variant is preferable. :) Yes. it should
> >answer false and don't contain any extra logic , like trying to follow
> >class hierarchy etc.

My intention is to include the method copied directly from Cuis, which is:

is: aSymbol
        "A means for cleanly replacing all isXXX like methods.
        Please use judiciously!
        Suggested by Igor Stasenko at
        http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html"

        ^false

> >Because it serves to replace isXXXX pattern, and not adding something
> >new (i.e. more 'userful'). So, answering false for Object class fits
> >well for this purpose.
> >
> >And of course solution to that problem is simple:
> >- avoid writing code in style, which require isXXX tests and then
> >branching. Nicely written code should use message dispatch instead.
> >Too bad, we are not living in perfect world :)
>
> Is it better to flood superclasses with no-op extension methods?
>

Absolutely no. But the proposal is from June 2009 and was supported
by Andreas, whose judgement I trust a lot. This is the first time in
over 10 years of squeaking that I have ever suggested adding a method
to Object, so it's really not too much of a flood. And I promise
never to do it again ;-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Levente Uzonyi-2
On Thu, 10 Feb 2011, David T. Lewis wrote:

> On Fri, Feb 11, 2011 at 02:51:26AM +0100, Levente Uzonyi wrote:
>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>
>>> On 11 February 2011 02:28, David T. Lewis <[hidden email]> wrote:
>>>> We had a good deal of discussion earlier about adding Object>>is:
>>>> with an inconclusive outcome:
>>>> ?http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html
>>>>
>>>> Igor's original proposal is:
>>>> ?http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html
>>>>
>>>> I have been tinkering around with Juan's SimpleMorphic in hopes of
>>>> getting it running in Squeak alongside MVC and Morphic, and it would
>>>> be convenient to have the default implementation of #is: in the image
>>>> so I don't have to put it in a package override.
>>>>
>>>
>>> Just yesterday i had  discussion about this with people in the lab. I
>>> can't say that i heard something new regarding this,
>>> and not saying that i'd like to resurrect the discussion.
>>> So, in short: there was no objection concerning getting rid of isXXX
>>> in favor of using #is: method.
>>
>> What about performance?
>
> I do not think that Juan would have chosen to use the #is: idiom for
> his Cuis Morphic implementation if he thought that performance would
> be a problem. It seems to work well.

You're right, it's pretty fast, but methods that return only a boolean
and have no arguments are special methods, which is true for almost every
#is* methods. I did a quick benchmark to see the effects of the change:

Object
  compile: 'is: aSymbol

  ^false'
  classified: 'testing'.
Morph
  compile: 'is: aSymbol

  ^aSymbol == #Morph or: [ super is: aSymbol ]'
  classified: 'testing'.
{
  [
  Smalltalk garbageCollect.
  (1 to: 5) collect: [ :run |
  [ SystemNavigation default allObjectsDo: [ :each | ] ] timeToRun ] ].
  [
  Smalltalk garbageCollect.
  (1 to: 5) collect: [ :run |
  [ SystemNavigation default allObjectsDo: [ :each | each isMorph ] ] timeToRun ] ].
  [
  Smalltalk garbageCollect.
  (1 to: 5) collect: [ :run |
  [ SystemNavigation default allObjectsDo: [ :each | each is: #Morph ] ] timeToRun ] ] }
  collect: [ :each | each value ].

With SqueakVM (4.0.3 windows VM), I got the following results:
  #(#(43 44 45 44 44) #(53 53 54 53 54) #(64 64 64 64 64)).
So using #is: #Morph instead of #isMorph is 2.13x slower in this case.

With CogVM (r2361 on windows), I got these (after a few runs that ensure
that Cog compiles the code to machine code):
  #(#(16 17 16 16 16) #(20 14 27 19 20) #(27 20 21 20 20))
So using #is: #Morph instead of #isMorph is 1.42x slower in this case.

I calculated the speedup with the following method (replace the array to
the other case's to get the other result):

#(#(16 17 16 16 16) #(20 14 27 19 20) #(27 20 21 20 20))in: [ :results |
  (results third average - results first average / (results second average - results first average)) asFloat ].

The difference for Cog is not significant, maybe just noise, but it's
clear that using #is: is slower with SqueakVM.

Let's see a bit larger scale benchmark: SmalltalkImage >>
#cleanUpUndoCommands. Note that this method is a "heavy user" of #is*.

(1 to: 5) collect: [ :run |
  Smalltalk garbageCollect.
  [ Smalltalk cleanUpUndoCommands ] timeToRun ].

With SqueakVM:
#isMorph : #(68 68 69 68 68)
#is: #Morph : #(83 83 90 82 83)

The difference is still there, but obviously smaller.

With CogVM (I couldn't force it to compile the method to machine code):
#isMorph : #(101 101 103 103 103)
#is: #Morph : #(103 102 103 103 104)

No real difference.

So code that uses #is* methods in tight loops may be slower with SqueakVM,
but probably won't with CogVM. The change probably won't have measurable
effect on other code.

>
>>
>>> The only thing which still looks controversial is too simple default
>>> implementation which answers false.
>>>
>>> To my current opinion, Juan's variant is preferable. :) Yes. it should
>>> answer false and don't contain any extra logic , like trying to follow
>>> class hierarchy etc.
>
> My intention is to include the method copied directly from Cuis, which is:
>
> is: aSymbol
> "A means for cleanly replacing all isXXX like methods.
> Please use judiciously!
> Suggested by Igor Stasenko at
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html"
>
> ^false

Okay.

>
>>> Because it serves to replace isXXXX pattern, and not adding something
>>> new (i.e. more 'userful'). So, answering false for Object class fits
>>> well for this purpose.
>>>
>>> And of course solution to that problem is simple:
>>> - avoid writing code in style, which require isXXX tests and then
>>> branching. Nicely written code should use message dispatch instead.
>>> Too bad, we are not living in perfect world :)
>>
>> Is it better to flood superclasses with no-op extension methods?
>>
>
> Absolutely no. But the proposal is from June 2009 and was supported
> by Andreas, whose judgement I trust a lot. This is the first time in
> over 10 years of squeaking that I have ever suggested adding a method
> to Object, so it's really not too much of a flood. And I promise
> never to do it again ;-)

The flooding is unrelated to #is:. It would be the side effect of Igor's
suggestion: "- avoid writing code in style, which require isXXX tests and
then branching.".
Let's see the above example: SmalltalkImage >> #cleanUpUndoCommands. It
sends #isMorph to all objects and then does something if the result is
true.
How could it be modified to satisfy Igor's suggestion?
Implement Object >> #cleanUpUndoCommands which does nothing (this is the
bloat) and implement Morph >> #cleanUpUndoCommands which does the real
work. Then send this method from SmalltalkImage's method to all objects.
No branching on the result of a #is* method, but an extra method for
Object. Why is this worse than using #isMorph? Because this method is
hardly useful from any other code, but #isMorph is.


Levente

>
> Dave
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Igor Stasenko
On 11 February 2011 15:06, Levente Uzonyi <[hidden email]> wrote:

> On Thu, 10 Feb 2011, David T. Lewis wrote:
>
>> On Fri, Feb 11, 2011 at 02:51:26AM +0100, Levente Uzonyi wrote:
>>>
>>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>>
>>>> On 11 February 2011 02:28, David T. Lewis <[hidden email]> wrote:
>>>>>
>>>>> We had a good deal of discussion earlier about adding Object>>is:
>>>>> with an inconclusive outcome:
>>>>>
>>>>> ?http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148501.html
>>>>>
>>>>> Igor's original proposal is:
>>>>>
>>>>> ?http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html
>>>>>
>>>>> I have been tinkering around with Juan's SimpleMorphic in hopes of
>>>>> getting it running in Squeak alongside MVC and Morphic, and it would
>>>>> be convenient to have the default implementation of #is: in the image
>>>>> so I don't have to put it in a package override.
>>>>>
>>>>
>>>> Just yesterday i had  discussion about this with people in the lab. I
>>>> can't say that i heard something new regarding this,
>>>> and not saying that i'd like to resurrect the discussion.
>>>> So, in short: there was no objection concerning getting rid of isXXX
>>>> in favor of using #is: method.
>>>
>>> What about performance?
>>
>> I do not think that Juan would have chosen to use the #is: idiom for
>> his Cuis Morphic implementation if he thought that performance would
>> be a problem. It seems to work well.
>
> You're right, it's pretty fast, but methods that return only a boolean and
> have no arguments are special methods, which is true for almost every #is*
> methods. I did a quick benchmark to see the effects of the change:
>
> Object
>        compile: 'is: aSymbol
>
>                ^false'
>        classified: 'testing'.
> Morph
>        compile: 'is: aSymbol
>
>                ^aSymbol == #Morph or: [ super is: aSymbol ]'
>        classified: 'testing'.
> {
>        [
>                Smalltalk garbageCollect.
>                (1 to: 5) collect: [ :run |
>                        [ SystemNavigation default allObjectsDo: [ :each | ]
> ] timeToRun ] ].
>        [
>                Smalltalk garbageCollect.
>                (1 to: 5) collect: [ :run |
>                        [ SystemNavigation default allObjectsDo: [ :each |
> each isMorph ] ] timeToRun ] ].
>        [
>                Smalltalk garbageCollect.
>                (1 to: 5) collect: [ :run |
>                        [ SystemNavigation default allObjectsDo: [ :each |
> each is: #Morph ] ] timeToRun ] ] }
>        collect: [ :each | each value ].
>
> With SqueakVM (4.0.3 windows VM), I got the following results:
>  #(#(43 44 45 44 44) #(53 53 54 53 54) #(64 64 64 64 64)).
> So using #is: #Morph instead of #isMorph is 2.13x slower in this case.
>
> With CogVM (r2361 on windows), I got these (after a few runs that ensure
> that Cog compiles the code to machine code):
>  #(#(16 17 16 16 16) #(20 14 27 19 20) #(27 20 21 20 20))
> So using #is: #Morph instead of #isMorph is 1.42x slower in this case.
>
> I calculated the speedup with the following method (replace the array to the
> other case's to get the other result):
>
> #(#(16 17 16 16 16) #(20 14 27 19 20) #(27 20 21 20 20))in: [ :results |
>        (results third average - results first average / (results second
> average - results first average)) asFloat ].
>
> The difference for Cog is not significant, maybe just noise, but it's clear
> that using #is: is slower with SqueakVM.
>
> Let's see a bit larger scale benchmark: SmalltalkImage >>
> #cleanUpUndoCommands. Note that this method is a "heavy user" of #is*.
>
> (1 to: 5) collect: [ :run |
>        Smalltalk garbageCollect.
>        [ Smalltalk cleanUpUndoCommands ] timeToRun ].
>
> With SqueakVM:
> #isMorph : #(68 68 69 68 68)
> #is: #Morph : #(83 83 90 82 83)
>
> The difference is still there, but obviously smaller.
>
> With CogVM (I couldn't force it to compile the method to machine code):
> #isMorph : #(101 101 103 103 103)
> #is: #Morph : #(103 102 103 103 104)
>
> No real difference.
>
> So code that uses #is* methods in tight loops may be slower with SqueakVM,
> but probably won't with CogVM. The change probably won't have measurable
> effect on other code.
>
>>
>>>
>>>> The only thing which still looks controversial is too simple default
>>>> implementation which answers false.
>>>>
>>>> To my current opinion, Juan's variant is preferable. :) Yes. it should
>>>> answer false and don't contain any extra logic , like trying to follow
>>>> class hierarchy etc.
>>
>> My intention is to include the method copied directly from Cuis, which is:
>>
>> is: aSymbol
>>        "A means for cleanly replacing all isXXX like methods.
>>        Please use judiciously!
>>        Suggested by Igor Stasenko at
>>
>>  http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-June/136793.html"
>>
>>        ^false
>
> Okay.
>
>>
>>>> Because it serves to replace isXXXX pattern, and not adding something
>>>> new (i.e. more 'userful'). So, answering false for Object class fits
>>>> well for this purpose.
>>>>
>>>> And of course solution to that problem is simple:
>>>> - avoid writing code in style, which require isXXX tests and then
>>>> branching. Nicely written code should use message dispatch instead.
>>>> Too bad, we are not living in perfect world :)
>>>
>>> Is it better to flood superclasses with no-op extension methods?
>>>
>>
>> Absolutely no. But the proposal is from June 2009 and was supported
>> by Andreas, whose judgement I trust a lot. This is the first time in
>> over 10 years of squeaking that I have ever suggested adding a method
>> to Object, so it's really not too much of a flood. And I promise
>> never to do it again ;-)
>
> The flooding is unrelated to #is:. It would be the side effect of Igor's
> suggestion: "- avoid writing code in style, which require isXXX tests and
> then branching.".
> Let's see the above example: SmalltalkImage >> #cleanUpUndoCommands. It
> sends #isMorph to all objects and then does something if the result is true.
> How could it be modified to satisfy Igor's suggestion?
> Implement Object >> #cleanUpUndoCommands which does nothing (this is the
> bloat) and implement Morph >> #cleanUpUndoCommands which does the real work.
> Then send this method from SmalltalkImage's method to all objects. No
> branching on the result of a #is* method, but an extra method for Object.
> Why is this worse than using #isMorph? Because this method is hardly useful
> from any other code, but #isMorph is.
>

Since this method is hardly useful from any other code but morphic,
then what it does in SmalltalkImage?
It should belong to UI universe.. and UI uninverse should know how to
tell all morphs to do that cleanup.. and then you don't need anything
related to it in Object protocol.
It makes no sense asking every object in system in a way like that.

So, all you need is to think a bit more broadly in a sense, how to
improve system and remove crappy patterns from use,
but not blindly replace one pattern by another , which replacing one
flood with another.


>
> Levente
>
>>
>> Dave
>>
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Levente Uzonyi-2
On Fri, 11 Feb 2011, Igor Stasenko wrote:

> Since this method is hardly useful from any other code but morphic,
> then what it does in SmalltalkImage?

That's a good question, but unrelated to this thread.

> It should belong to UI universe.. and UI uninverse should know how to
> tell all morphs to do that cleanup.. and then you don't need anything
> related to it in Object protocol.
> It makes no sense asking every object in system in a way like that.

It's a lot faster asking all objects, than asking only the Morphs.

>
> So, all you need is to think a bit more broadly in a sense, how to
> improve system and remove crappy patterns from use,
> but not blindly replace one pattern by another , which replacing one
> flood with another.

If you can show a pattern for this which has comparable performance with
the current implementation, then I'm all ears.


Levente

>
>
>>
>> Levente
>>
>>>
>>> Dave
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Igor Stasenko
On 11 February 2011 15:57, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>
>> Since this method is hardly useful from any other code but morphic,
>> then what it does in SmalltalkImage?
>
> That's a good question, but unrelated to this thread.
>
>> It should belong to UI universe.. and UI uninverse should know how to
>> tell all morphs to do that cleanup.. and then you don't need anything
>> related to it in Object protocol.
>> It makes no sense asking every object in system in a way like that.
>
> It's a lot faster asking all objects, than asking only the Morphs.
>

Morphs are just a subset of all objects.. So, please tell me how
sending a message to all objects could be faster than sending message
to all morphs? :)

>>
>> So, all you need is to think a bit more broadly in a sense, how to
>> improve system and remove crappy patterns from use,
>> but not blindly replace one pattern by another , which replacing one
>> flood with another.
>
> If you can show a pattern for this which has comparable performance with the
> current implementation, then I'm all ears.
>

Since when performance became the only criteria for reasoning about
implementation quality?

>
> Levente
>
>>
>>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Levente Uzonyi-2
On Fri, 11 Feb 2011, Igor Stasenko wrote:

> On 11 February 2011 15:57, Levente Uzonyi <[hidden email]> wrote:
>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>
>>> Since this method is hardly useful from any other code but morphic,
>>> then what it does in SmalltalkImage?
>>
>> That's a good question, but unrelated to this thread.
>>
>>> It should belong to UI universe.. and UI uninverse should know how to
>>> tell all morphs to do that cleanup.. and then you don't need anything
>>> related to it in Object protocol.
>>> It makes no sense asking every object in system in a way like that.
>>
>> It's a lot faster asking all objects, than asking only the Morphs.
>>
>
> Morphs are just a subset of all objects.. So, please tell me how
> sending a message to all objects could be faster than sending message
> to all morphs? :)

I guess you didn't think about the problem. How do you select all morphs?

>
>>>
>>> So, all you need is to think a bit more broadly in a sense, how to
>>> improve system and remove crappy patterns from use,
>>> but not blindly replace one pattern by another , which replacing one
>>> flood with another.
>>
>> If you can show a pattern for this which has comparable performance with the
>> current implementation, then I'm all ears.
>>
>
> Since when performance became the only criteria for reasoning about
> implementation quality?

Who said it's the only criteria (besides you)?
Btw, the previous implementation of this method was slow. It annoyed me so
much that I changed it to the current implememtation which uses
allObjectsDo: and is 22x faster for a Trunk image.


Levente

>
>>
>> Levente
>>
>>>
>>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Igor Stasenko
On 11 February 2011 17:02, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>
>> On 11 February 2011 15:57, Levente Uzonyi <[hidden email]> wrote:
>>>
>>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>>
>>>> Since this method is hardly useful from any other code but morphic,
>>>> then what it does in SmalltalkImage?
>>>
>>> That's a good question, but unrelated to this thread.
>>>
>>>> It should belong to UI universe.. and UI uninverse should know how to
>>>> tell all morphs to do that cleanup.. and then you don't need anything
>>>> related to it in Object protocol.
>>>> It makes no sense asking every object in system in a way like that.
>>>
>>> It's a lot faster asking all objects, than asking only the Morphs.
>>>
>>
>> Morphs are just a subset of all objects.. So, please tell me how
>> sending a message to all objects could be faster than sending message
>> to all morphs? :)
>
> I guess you didn't think about the problem. How do you select all morphs?
>
you can do something like:
  World blahblah...
no?
I am sure, if you look deeply there is a way to iterate over all submorphs tree.

And don't say that it will be slower than iterating over all objects
in object memory.

But even if you do, then why not iterating over morphs , so you don't
have to use #isMorph

Morph allSubInstancesDo: ...

>>
>>>>
>>>> So, all you need is to think a bit more broadly in a sense, how to
>>>> improve system and remove crappy patterns from use,
>>>> but not blindly replace one pattern by another , which replacing one
>>>> flood with another.
>>>
>>> If you can show a pattern for this which has comparable performance with
>>> the
>>> current implementation, then I'm all ears.
>>>
>>
>> Since when performance became the only criteria for reasoning about
>> implementation quality?
>
> Who said it's the only criteria (besides you)?
> Btw, the previous implementation of this method was slow. It annoyed me so
> much that I changed it to the current implememtation which uses
> allObjectsDo: and is 22x faster for a Trunk image.
>

Why then to not change the implementation?
Why you fighting with imlementation being slow, without getting
interested why it implemented in such manner,
which is the main reason why its so slow.

Did you asked yourself, why cleaning up the undo commands in morphs is
responsibility of SmalltalkImage class ??
Why it is not responsibility of morphic world/project.

So, yeah.. keep fighting with consequences instead of dealing with cause.

>
> Levente



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Ricardo Moran

On Fri, Feb 11, 2011 at 3:29 PM, Igor Stasenko <[hidden email]> wrote:>
(snip)
you can do something like:
 World blahblah...
no?
I am sure, if you look deeply there is a way to iterate over all submorphs tree.
 
I think you mean

World>>#allMorphsDo:

and in my experience it is *much* faster than iterating over all objects.

Cheers
Richo
 

And don't say that it will be slower than iterating over all objects
in object memory.

But even if you do, then why not iterating over morphs , so you don't
have to use #isMorph

Morph allSubInstancesDo: ...

>>
>>>>
>>>> So, all you need is to think a bit more broadly in a sense, how to
>>>> improve system and remove crappy patterns from use,
>>>> but not blindly replace one pattern by another , which replacing one
>>>> flood with another.
>>>
>>> If you can show a pattern for this which has comparable performance with
>>> the
>>> current implementation, then I'm all ears.
>>>
>>
>> Since when performance became the only criteria for reasoning about
>> implementation quality?
>
> Who said it's the only criteria (besides you)?
> Btw, the previous implementation of this method was slow. It annoyed me so
> much that I changed it to the current implememtation which uses
> allObjectsDo: and is 22x faster for a Trunk image.
>

Why then to not change the implementation?
Why you fighting with imlementation being slow, without getting
interested why it implemented in such manner,
which is the main reason why its so slow.

Did you asked yourself, why cleaning up the undo commands in morphs is
responsibility of SmalltalkImage class ??
Why it is not responsibility of morphic world/project.

So, yeah.. keep fighting with consequences instead of dealing with cause.

>
> Levente



--
Best regards,
Igor Stasenko AKA sig.




Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Igor Stasenko
On 11 February 2011 20:23, Ricardo Moran <[hidden email]> wrote:

>
> On Fri, Feb 11, 2011 at 3:29 PM, Igor Stasenko <[hidden email]> wrote:>
> (snip)
>>
>> you can do something like:
>>  World blahblah...
>> no?
>> I am sure, if you look deeply there is a way to iterate over all submorphs
>> tree.
>
>
> I think you mean
> World>>#allMorphsDo:
> and in my experience it is *much* faster than iterating over all objects.

sure it is faster, and besides you don't have to test for #isMorph
when iterating using it :)

There is a lot of benefits of writing good OO code and separating
domains and operations applicable to
(sub)domains like clean undo history etc ..

So yeah.. #is: is slower... so lets keep using #allObjectsDo: +
isMorph, because its faster. :)


> Cheers
> Richo
>


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Colin Putney-3
In reply to this post by Igor Stasenko
On Thu, Feb 10, 2011 at 5:41 PM, Igor Stasenko <[hidden email]> wrote:

> Just yesterday i had  discussion about this with people in the lab. I
> can't say that i heard something new regarding this,
> and not saying that i'd like to resurrect the discussion.
> So, in short: there was no objection concerning getting rid of isXXX
> in favor of using #is: method.
> The only thing which still looks controversial is too simple default
> implementation which answers false.

No so. I think #is: is a terrible idea, and I object to it on those
grounds. I only object to the default implementation because it's the
thin edge of the wedge which invites people to use an anti-pattern.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Stéphane Rollandin
>  I think #is: is a terrible idea

A possible solution is to name it #isA: and limit its semantics to
inheritance testing only. We discussed this at length one year ago in
that thread:

http://forum.world.st/Object-gt-gt-is-was-Re-PackageDependencyTest-td1578541.html
(and following pages)



The reason I thought (and still think) Object>>#is: is a bad design for
protocol implementation can be summarized by the following citations of
mine (see the thread for more context):

----

all #is:-type of attributes have to be centralized in
one place, the #is: method.

a Morph that isMorph, isBeautiful and isWhatMyUncleLikes has to provide
the three answers to very different questions in the same place. Now if
another package needs to know if a Morph isMyCupOfTea, it must override
aMorph>>#is:

so #is: can not actually safely belong to a single package. while
#isWhatMyUncleLikes will only be in my package MyUncle, except if
someone else has the same kind of weird ideas about protocol names.

plus, looking for the senders of #isBeautiful immediately gives me all
classes responding to the protocol. with the #is: idea, all protocols
are mangled in one: you have to look at all #is: implementations, in all
objects (!) to see where you protocol went.

----

#is: becomes an attractor, a fixed point for all protocols, dispatched
on all classes and having to support all packages. it's another form of
the God class: it's the God method for protocols. this is not OOP as I
understand (and practice) it.

----



I was answered by proponents of Object>>#is: that my points were moot
because extension methods were evil and I was doing monkey patching. So
in the end we talked about what is good practice in that matter, and
disagreed :)



Stef

Reply | Threaded
Open this post in threaded view
|

Iterating over all Morphs (was: Re: [squeak-dev] Object>>is:)

Levente Uzonyi-2
In reply to this post by Igor Stasenko
On Fri, 11 Feb 2011, Igor Stasenko wrote:

> On 11 February 2011 17:02, Levente Uzonyi <[hidden email]> wrote:
>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>
>>> On 11 February 2011 15:57, Levente Uzonyi <[hidden email]> wrote:
>>>>
>>>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>>>
>>>>> Since this method is hardly useful from any other code but morphic,
>>>>> then what it does in SmalltalkImage?
>>>>
>>>> That's a good question, but unrelated to this thread.
>>>>
>>>>> It should belong to UI universe.. and UI uninverse should know how to
>>>>> tell all morphs to do that cleanup.. and then you don't need anything
>>>>> related to it in Object protocol.
>>>>> It makes no sense asking every object in system in a way like that.
>>>>
>>>> It's a lot faster asking all objects, than asking only the Morphs.
>>>>
>>>
>>> Morphs are just a subset of all objects.. So, please tell me how
>>> sending a message to all objects could be faster than sending message
>>> to all morphs? :)
>>
>> I guess you didn't think about the problem. How do you select all morphs?
>>
> you can do something like:
>  World blahblah...
> no?
> I am sure, if you look deeply there is a way to iterate over all submorphs tree.

You can, but that doesn't find all the Morphs:

c1 := c2 := 0.
World allMorphsDo: [ :x | c1 := c1 + 1 ].
Morph allSubInstancesDo: [ :each | c2 := c2 + 1 ].
{ c1. c2 }. #(1054 3600).

>
> And don't say that it will be slower than iterating over all objects
> in object memory.

No, it's faster, but it doesn't find all Morphs.

>
> But even if you do, then why not iterating over morphs , so you don't
> have to use #isMorph
>
> Morph allSubInstancesDo: ...

The slow implementation which I replaced with #allObjectsDo: did the same
as Morph allSubInstancesDo: [ ... ].

>
>>>
>>>>>
>>>>> So, all you need is to think a bit more broadly in a sense, how to
>>>>> improve system and remove crappy patterns from use,
>>>>> but not blindly replace one pattern by another , which replacing one
>>>>> flood with another.
>>>>
>>>> If you can show a pattern for this which has comparable performance with
>>>> the
>>>> current implementation, then I'm all ears.
>>>>
>>>
>>> Since when performance became the only criteria for reasoning about
>>> implementation quality?
>>
>> Who said it's the only criteria (besides you)?
>> Btw, the previous implementation of this method was slow. It annoyed me so
>> much that I changed it to the current implememtation which uses
>> allObjectsDo: and is 22x faster for a Trunk image.
>>
>
> Why then to not change the implementation?

I changed the implementation. :)

> Why you fighting with imlementation being slow, without getting
> interested why it implemented in such manner,
> which is the main reason why its so slow.

It's not slow anymore, and I still doubt you could make it faster without
changing the VM or registering all morphs to some collection. But I'm
still all ears to a better implementation.

>
> Did you asked yourself, why cleaning up the undo commands in morphs is
> responsibility of SmalltalkImage class ??

As I wrote before, this is an important question, but irrelevant in
this thread.

> Why it is not responsibility of morphic world/project.

Because they don't contain all morphs?


Levente

>
> So, yeah.. keep fighting with consequences instead of dealing with cause.
>
>>
>> Levente
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Levente Uzonyi-2
In reply to this post by Igor Stasenko
On Fri, 11 Feb 2011, Igor Stasenko wrote:

> On 11 February 2011 20:23, Ricardo Moran <[hidden email]> wrote:
>>
>> On Fri, Feb 11, 2011 at 3:29 PM, Igor Stasenko <[hidden email]> wrote:>
>> (snip)
>>>
>>> you can do something like:
>>>  World blahblah...
>>> no?
>>> I am sure, if you look deeply there is a way to iterate over all submorphs
>>> tree.
>>
>>
>> I think you mean
>> World>>#allMorphsDo:
>> and in my experience it is *much* faster than iterating over all objects.
>
> sure it is faster, and besides you don't have to test for #isMorph
> when iterating using it :)
>
> There is a lot of benefits of writing good OO code and separating
> domains and operations applicable to
> (sub)domains like clean undo history etc ..
>
> So yeah.. #is: is slower... so lets keep using #allObjectsDo: +
> isMorph, because its faster. :)
You're trying to twist my words, but to make it clear, I never said that.
Read my previous mail why your idea doesn't work.


Levente

>
>
>> Cheers
>> Richo
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Object>>is:

Levente Uzonyi-2
In reply to this post by Stéphane Rollandin
On Fri, 11 Feb 2011, Stéphane Rollandin wrote:

>>  I think #is: is a terrible idea
>
> A possible solution is to name it #isA: and limit its semantics to
> inheritance testing only. We discussed this at length one year ago in that
> thread:

If you would only use it for inheritance testing, then why bother with it
at all? #isKindOf: is already in the image and does exactly that.

In general #is: works as long as you don't have to add a protocol to a
class that already implements #is:.


Levente

>
> http://forum.world.st/Object-gt-gt-is-was-Re-PackageDependencyTest-td1578541.html
> (and following pages)
>
>
>
> The reason I thought (and still think) Object>>#is: is a bad design for
> protocol implementation can be summarized by the following citations of mine
> (see the thread for more context):
>
> ----
>
> all #is:-type of attributes have to be centralized in
> one place, the #is: method.
>
> a Morph that isMorph, isBeautiful and isWhatMyUncleLikes has to provide
> the three answers to very different questions in the same place. Now if
> another package needs to know if a Morph isMyCupOfTea, it must override
> aMorph>>#is:
>
> so #is: can not actually safely belong to a single package. while
> #isWhatMyUncleLikes will only be in my package MyUncle, except if
> someone else has the same kind of weird ideas about protocol names.
>
> plus, looking for the senders of #isBeautiful immediately gives me all
> classes responding to the protocol. with the #is: idea, all protocols
> are mangled in one: you have to look at all #is: implementations, in all
> objects (!) to see where you protocol went.
>
> ----
>
> #is: becomes an attractor, a fixed point for all protocols, dispatched
> on all classes and having to support all packages. it's another form of
> the God class: it's the God method for protocols. this is not OOP as I
> understand (and practice) it.
>
> ----
>
>
>
> I was answered by proponents of Object>>#is: that my points were moot because
> extension methods were evil and I was doing monkey patching. So in the end we
> talked about what is good practice in that matter, and disagreed :)
>
>
>
> Stef
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Iterating over all Morphs (was: Re: [squeak-dev] Object>>is:)

Igor Stasenko
In reply to this post by Levente Uzonyi-2
On 11 February 2011 23:01, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>
>> On 11 February 2011 17:02, Levente Uzonyi <[hidden email]> wrote:
>>>
>>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>>
>>>> On 11 February 2011 15:57, Levente Uzonyi <[hidden email]> wrote:
>>>>>
>>>>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>>>>
>>>>>> Since this method is hardly useful from any other code but morphic,
>>>>>> then what it does in SmalltalkImage?
>>>>>
>>>>> That's a good question, but unrelated to this thread.
>>>>>
>>>>>> It should belong to UI universe.. and UI uninverse should know how to
>>>>>> tell all morphs to do that cleanup.. and then you don't need anything
>>>>>> related to it in Object protocol.
>>>>>> It makes no sense asking every object in system in a way like that.
>>>>>
>>>>> It's a lot faster asking all objects, than asking only the Morphs.
>>>>>
>>>>
>>>> Morphs are just a subset of all objects.. So, please tell me how
>>>> sending a message to all objects could be faster than sending message
>>>> to all morphs? :)
>>>
>>> I guess you didn't think about the problem. How do you select all morphs?
>>>
>> you can do something like:
>>  World blahblah...
>> no?
>> I am sure, if you look deeply there is a way to iterate over all submorphs
>> tree.
>
> You can, but that doesn't find all the Morphs:
>
> c1 := c2 := 0.
> World allMorphsDo: [ :x | c1 := c1 + 1 ].
> Morph allSubInstancesDo: [ :each | c2 := c2 + 1 ].
> { c1. c2 }. #(1054 3600).

Same mistake again.
Fix the error that some morphs are not visible through world (probably
due to belonging to other PasteUpMorph instance).
So you still don't have to use VM heap walk to iterate over them.
Moreover, i pretty sure that you can skip those morphs, which are not
taking part in UI interaction (what undo history could have a morph,
which
never seen its way to world?).

>
>>
>> And don't say that it will be slower than iterating over all objects
>> in object memory.
>
> No, it's faster, but it doesn't find all Morphs.
>
>>
>> But even if you do, then why not iterating over morphs , so you don't
>> have to use #isMorph
>>
>> Morph allSubInstancesDo: ...
>
> The slow implementation which I replaced with #allObjectsDo: did the same as
> Morph allSubInstancesDo: [ ... ].
>
>>
>>>>
>>>>>>
>>>>>> So, all you need is to think a bit more broadly in a sense, how to
>>>>>> improve system and remove crappy patterns from use,
>>>>>> but not blindly replace one pattern by another , which replacing one
>>>>>> flood with another.
>>>>>
>>>>> If you can show a pattern for this which has comparable performance
>>>>> with
>>>>> the
>>>>> current implementation, then I'm all ears.
>>>>>
>>>>
>>>> Since when performance became the only criteria for reasoning about
>>>> implementation quality?
>>>
>>> Who said it's the only criteria (besides you)?
>>> Btw, the previous implementation of this method was slow. It annoyed me
>>> so
>>> much that I changed it to the current implememtation which uses
>>> allObjectsDo: and is 22x faster for a Trunk image.
>>>
>>
>> Why then to not change the implementation?
>
> I changed the implementation. :)
>
>> Why you fighting with imlementation being slow, without getting
>> interested why it implemented in such manner,
>> which is the main reason why its so slow.
>
> It's not slow anymore, and I still doubt you could make it faster without
> changing the VM or registering all morphs to some collection. But I'm still
> all ears to a better implementation.
>
>>
>> Did you asked yourself, why cleaning up the undo commands in morphs is
>> responsibility of SmalltalkImage class ??
>
> As I wrote before, this is an important question, but irrelevant in this
> thread.
>
>> Why it is not responsibility of morphic world/project.
>
> Because they don't contain all morphs?
>

And you don't need all morphs.

>
> Levente
>


--
Best regards,
Igor Stasenko AKA sig.

12