[Cuis-dev] [Ann] Serialization of BlockClosures

[Juan Vuletich]

With the recent changes Color was lacking #= and #hash, so all 
comparisons answered false. I guess that was the slowdown. Downside of 
using a very fast machine: I haven't noticed it immediately.

Hopefully the code I just pushed fixes this. Please pull, update & retry.

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich


On 10/2/2019 8:46 PM, Phil B wrote:
> Hmm... things are *much* more sluggish in 3899 on my system.  When I 
> open up a vanilla 3866 image ProcessBrowser shows the Morphic process 
> idling ~5-10% but with 3899 Morphic is at 35-40%. (if it turns out 
> that this is due purely due to Color no longer being a collection 
> subclass then we have our answer why it was one but I find the delta 
> too large to believe that's the issue at first glance)
>
> On Wed, Oct 2, 2019 at 11:15 AM Juan Vuletich <juan at jvuletich.org 
> <mailto:juan at jvuletich.org>> wrote:
>
>     Hi Folks,
>
>     (below)
>
>     On 10/1/2019 1:25 AM, Phil B wrote:
>>     Juan,
>>
>>     On Mon, Sep 30, 2019 at 11:43 PM Juan Vuletich via Cuis-dev
>>     <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>>
>>         Hi Nicolas,
>>
>>         On 9/30/2019 8:36 PM, Nicolas Cellier via Cuis-dev wrote:
>>>         Hi Juan,
>>>         Something strikes me.
>>>         Isn't this example a pathological case of inheritance? Is
>>>         Color really kind of Collection? Wouldn't any object
>>>         potentially be a collection of its instances variables in
>>>         this case?
>>
>>
>>     Well that kind of gets to a core issue (in an abstract way... I
>>     know, your favorite ;-) in that there is nothing inherent about
>>     being a Color that one should reasonably expect it to behave as a
>>     collection.  Sending #collect: etc. on a Color from an outside
>>     object doesn't actually make a lot of sense other than to abuse a
>>     leaked implementation detail (i.e. that it's actually implemented
>>     as a collection.)
>>
>>
>>         It can be considered a space optimization. Just like Squeak's
>>         encoding of RGB in a SmallInteger. Other examples in Cuis
>>         packages include Float32Matrix3x3, Float32Vector3,
>>         Float64Matrix?x?, Float64Quaternion, Float64Vector?,
>>         GPSPosition, All these could use ivars, but dont, and inherit
>>         from FloatArray or Float64Array.
>>
>>
>>     There are FFI reasons as well. (but that's an implementation detail)
>>
>>         This makes sense especially on 64 bit images for objects
>>         whose parts can be 32bit or shorter immediates, and if we
>>         build many instances. In this cases, I think the space saving
>>         overwheights the inconvenience of not having real ivars.
>>
>>
>>     One could argue (and I am) that whether it was implemented it
>>     that way for space savings or other reasons that we shouldn't
>>     depend on it being a collection because you could just as easily
>>     re-implement it as a direct subclass of Object and it would still
>>     make sense.  The fact that it is currently a collection seems
>>     irrelevant to being a Color.  The fact that it would no longer
>>     responded to #collect: and friends wouldn't make it any less a
>>     Color... so why encourage/support using these (essentially)
>>     leaked methods externally?
>>
>>         -- 
>>         Juan Vuletich
>>         www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>>         https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>         https://github.com/jvuletich
>>         https://www.linkedin.com/in/juan-vuletich-75611b3
>>         @JuanVuletich
>>
>>
>>     Thanks,
>>     Phil
>
>     You are both right. Thanks for raising this issue.
>
>     I just pushed to GitHub a new Float32SlotsObject, and made Color
>     subclass of it. Color is no longer a Collection, and I hope I
>     didn't break too many things... Please take a look, and report any
>     problems.
>
>     Cheers,
>
>     -- 
>     Juan Vuletich
>     www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     https://github.com/jvuletich
>     https://www.linkedin.com/in/juan-vuletich-75611b3
>     @JuanVuletich
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191002/b4bfb957/attachment.htm>