The Inbox: EToys-hjh.333.mcz

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

The Inbox: EToys-hjh.333.mcz

commits-2
A new version of EToys was added to project The Inbox:
http://source.squeak.org/inbox/EToys-hjh.333.mcz

==================== Summary ====================

Name: EToys-hjh.333
Author: hjh
Time: 11 June 2018, 7:47:07.644259 am
UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
Ancestors: EToys-nice.332

Move methods
Morph rotationCenter and rotationCenter:
from 'Etoys-geometry' to 'geometry'

=============== Diff against EToys-nice.332 ===============

Item was removed:
- ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry') -----
- rotationCenter
- "Return the rotation center of the receiver. The rotation center defines the relative offset inside the receiver's bounds for locating the reference position."
- ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
- !

Item was removed:
- ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry') -----
- rotationCenter: aPointOrNil
- "Set the new rotation center of the receiver. The rotation center defines the relative offset inside the receiver's bounds for locating the reference position."
- aPointOrNil isNil
- ifTrue:[self removeProperty: #rotationCenter]
- ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
- !


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

Hannes Hirzel
The two methods


Morph rotationCenter and
Morph rotationCenter:

need to be moved from the  'Etoys-geometry' category to the
'geometry' category in order to avoid an immediate crash after
unloading Etoys.

See http://wiki.squeak.org/squeak/1156

I am not sure how this re-categorisation has to be done.

On Mon, 11 Jun 2018 05:47:31 0000, [hidden email]
<[hidden email]> wrote:

> A new version of EToys was added to project The Inbox:
> http://source.squeak.org/inbox/EToys-hjh.333.mcz
>
> ==================== Summary ====================
>
> Name: EToys-hjh.333
> Author: hjh
> Time: 11 June 2018, 7:47:07.644259 am
> UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
> Ancestors: EToys-nice.332
>
> Move methods
> Morph rotationCenter and rotationCenter:
> from 'Etoys-geometry' to 'geometry'
>
> =============== Diff against EToys-nice.332 ===============
>
> Item was removed:
> - ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry') -----
> - rotationCenter
> - "Return the rotation center of the receiver. The rotation center defines
> the relative offset inside the receiver's bounds for locating the reference
> position."
> - ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
> - !
>
> Item was removed:
> - ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry') -----
> - rotationCenter: aPointOrNil
> - "Set the new rotation center of the receiver. The rotation center defines
> the relative offset inside the receiver's bounds for locating the reference
> position."
> - aPointOrNil isNil
> - ifTrue:[self removeProperty: #rotationCenter]
> - ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
> - !
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

Hannes Hirzel
Package Morphic as the receiver of this change needs an update as well.

On 6/11/18, H. Hirzel <[hidden email]> wrote:

> The two methods
>
>
> Morph rotationCenter and
> Morph rotationCenter:
>
> need to be moved from the  'Etoys-geometry' category to the
> 'geometry' category in order to avoid an immediate crash after
> unloading Etoys.
>
> See http://wiki.squeak.org/squeak/1156
>
> I am not sure how this re-categorisation has to be done.
>
> On Mon, 11 Jun 2018 05:47:31 0000, [hidden email]
> <[hidden email]> wrote:
>> A new version of EToys was added to project The Inbox:
>> http://source.squeak.org/inbox/EToys-hjh.333.mcz
>>
>> ==================== Summary ====================
>>
>> Name: EToys-hjh.333
>> Author: hjh
>> Time: 11 June 2018, 7:47:07.644259 am
>> UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
>> Ancestors: EToys-nice.332
>>
>> Move methods
>> Morph rotationCenter and rotationCenter:
>> from 'Etoys-geometry' to 'geometry'
>>
>> =============== Diff against EToys-nice.332 ===============
>>
>> Item was removed:
>> - ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry')
>> -----
>> - rotationCenter
>> - "Return the rotation center of the receiver. The rotation center
>> defines
>> the relative offset inside the receiver's bounds for locating the
>> reference
>> position."
>> - ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
>> - !
>>
>> Item was removed:
>> - ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry')
>> -----
>> - rotationCenter: aPointOrNil
>> - "Set the new rotation center of the receiver. The rotation center
>> defines
>> the relative offset inside the receiver's bounds for locating the
>> reference
>> position."
>> - aPointOrNil isNil
>> - ifTrue:[self removeProperty: #rotationCenter]
>> - ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
>> - !
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

Edgar J. De Cleene-3
In reply to this post by Hannes Hirzel
More methods needs move outside Etoys for proper working.
I redo and check unload works well , but we agreed is not a priority for
5.2.

And the question is

We should have 5.3, etc and made planned short steps ?


On 11/06/2018, 02:52, "H. Hirzel" <[hidden email]> wrote:

> The two methods


Morph rotationCenter and
Morph rotationCenter:

need to be
> moved from the  'Etoys-geometry' category to the
'geometry' category in order
> to avoid an immediate crash after
unloading Etoys.

See
> http://wiki.squeak.org/squeak/1156

I am not sure how this re-categorisation
> has to be done.



Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

David T. Lewis
In reply to this post by Hannes Hirzel
These two methods are sent by CircleMorph>>extent: in package Morphic-Basic,
so moving them from Etoys to Morphic seems the the right thing to do. Does
anyone disagree?

Note that #center and #rotationCenter are not the same for a CircleMorph,
and we have other implementers of #rotationCenter: in Morphic already.

Dave


On Mon, Jun 11, 2018 at 07:54:32AM +0200, H. Hirzel wrote:

> Package Morphic as the receiver of this change needs an update as well.
>
> On 6/11/18, H. Hirzel <[hidden email]> wrote:
> > The two methods
> >
> >
> > Morph rotationCenter and
> > Morph rotationCenter:
> >
> > need to be moved from the  'Etoys-geometry' category to the
> > 'geometry' category in order to avoid an immediate crash after
> > unloading Etoys.
> >
> > See http://wiki.squeak.org/squeak/1156
> >
> > I am not sure how this re-categorisation has to be done.
> >
> > On Mon, 11 Jun 2018 05:47:31 0000, [hidden email]
> > <[hidden email]> wrote:
> >> A new version of EToys was added to project The Inbox:
> >> http://source.squeak.org/inbox/EToys-hjh.333.mcz
> >>
> >> ==================== Summary ====================
> >>
> >> Name: EToys-hjh.333
> >> Author: hjh
> >> Time: 11 June 2018, 7:47:07.644259 am
> >> UUID: 1872ec0f-374c-4d8a-a701-f118fb19ae40
> >> Ancestors: EToys-nice.332
> >>
> >> Move methods
> >> Morph rotationCenter and rotationCenter:
> >> from 'Etoys-geometry' to 'geometry'
> >>
> >> =============== Diff against EToys-nice.332 ===============
> >>
> >> Item was removed:
> >> - ----- Method: Morph>>rotationCenter (in category '*Etoys-geometry')
> >> -----
> >> - rotationCenter
> >> - "Return the rotation center of the receiver. The rotation center
> >> defines
> >> the relative offset inside the receiver's bounds for locating the
> >> reference
> >> position."
> >> - ^self valueOfProperty: #rotationCenter ifAbsent:[0.5@0.5]
> >> - !
> >>
> >> Item was removed:
> >> - ----- Method: Morph>>rotationCenter: (in category '*Etoys-geometry')
> >> -----
> >> - rotationCenter: aPointOrNil
> >> - "Set the new rotation center of the receiver. The rotation center
> >> defines
> >> the relative offset inside the receiver's bounds for locating the
> >> reference
> >> position."
> >> - aPointOrNil isNil
> >> - ifTrue:[self removeProperty: #rotationCenter]
> >> - ifFalse:[self setProperty: #rotationCenter toValue: aPointOrNil]
> >> - !
> >>
> >>
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

K K Subbu
On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
> These two methods are sent by CircleMorph>>extent: in package Morphic-Basic,
> so moving them from Etoys to Morphic seems the the right thing to do. Does
> anyone disagree?

rotationCenter is an optional not an intrinsic geometric property like
bounds, extent etc. So should it be moved into the category "rotate
scale and flex"?

rotationCenter also works with other properties like forwardDirection
etc. They should also be considered for merging into Morphic. In fact,
all the methods in Etoys-geometry could be moved to Morph as they don't
use anything specific to Etoys (player).

Regards .. Subbu

cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

cbc

On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> wrote:
On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
These two methods are sent by CircleMorph>>extent: in package Morphic-Basic,
so moving them from Etoys to Morphic seems the the right thing to do. Does
anyone disagree?

rotationCenter is an optional not an intrinsic geometric property like bounds, extent etc. So should it be moved into the category "rotate scale and flex"?

rotationCenter also works with other properties like forwardDirection etc. They should also be considered for merging into Morphic. In fact, all the methods in Etoys-geometry could be moved to Morph as they don't use anything specific to Etoys (player).

Regards .. Subbu

Looking at the definitions in the image, there are 4 definitions of these methods.  The 3 definitions NOT in Etoys are in the method category 'geometry etoy'.  So I'd suggest putting them there to at least have all of them in the same place.

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

Hannes Hirzel
So the proposal is to

a) to move all from category '*Etoys-geometry* to category *geometry
eToy* and then the two methods

rotationCenter and rotationCenter:

to category 'rotate scale and flex'

-- HJH


On 6/11/18, Chris Cunningham <[hidden email]> wrote:

> On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> wrote:
>
>> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
>>
>>> These two methods are sent by CircleMorph>>extent: in package
>>> Morphic-Basic,
>>> so moving them from Etoys to Morphic seems the the right thing to do.
>>> Does
>>> anyone disagree?
>>>
>>
>> rotationCenter is an optional not an intrinsic geometric property like
>> bounds, extent etc. So should it be moved into the category "rotate scale
>> and flex"?
>>
>> rotationCenter also works with other properties like forwardDirection
>> etc.
>> They should also be considered for merging into Morphic. In fact, all the
>> methods in Etoys-geometry could be moved to Morph as they don't use
>> anything specific to Etoys (player).
>>
>> Regards .. Subbu
>>
>> Looking at the definitions in the image, there are 4 definitions of these
> methods.  The 3 definitions NOT in Etoys are in the method category
> 'geometry etoy'.  So I'd suggest putting them there to at least have all of
> them in the same place.
>
> -cbc
>



category_geometry_etoy_Screenshot_2018-06-11.png (301K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

Hannes Hirzel
(Morph methodsInCategory: '*Etoys-geometry')
    do: [:m | Morph organization classify: m under: 'geometry eToy'].

On 6/11/18, H. Hirzel <[hidden email]> wrote:

> So the proposal is to
>
> a) to move all from category '*Etoys-geometry* to category *geometry
> eToy* and then the two methods
>
> rotationCenter and rotationCenter:
>
> to category 'rotate scale and flex'
>
> -- HJH
>
>
> On 6/11/18, Chris Cunningham <[hidden email]> wrote:
>> On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> wrote:
>>
>>> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
>>>
>>>> These two methods are sent by CircleMorph>>extent: in package
>>>> Morphic-Basic,
>>>> so moving them from Etoys to Morphic seems the the right thing to do.
>>>> Does
>>>> anyone disagree?
>>>>
>>>
>>> rotationCenter is an optional not an intrinsic geometric property like
>>> bounds, extent etc. So should it be moved into the category "rotate
>>> scale
>>> and flex"?
>>>
>>> rotationCenter also works with other properties like forwardDirection
>>> etc.
>>> They should also be considered for merging into Morphic. In fact, all
>>> the
>>> methods in Etoys-geometry could be moved to Morph as they don't use
>>> anything specific to Etoys (player).
>>>
>>> Regards .. Subbu
>>>
>>> Looking at the definitions in the image, there are 4 definitions of
>>> these
>> methods.  The 3 definitions NOT in Etoys are in the method category
>> 'geometry etoy'.  So I'd suggest putting them there to at least have all
>> of
>> them in the same place.
>>
>> -cbc
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

David T. Lewis
In reply to this post by Hannes Hirzel
On Mon, Jun 11, 2018 at 11:29:49PM +0200, H. Hirzel wrote:

>
> On 6/11/18, Chris Cunningham <[hidden email]> wrote:
>
> > On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> wrote:
> >
> >> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
> >>
> >>> These two methods are sent by CircleMorph>>extent: in package Morphic-Basic,
> >>> so moving them from Etoys to Morphic seems the the right thing to do.
> >>> Does anyone disagree?
> >>
> >> rotationCenter is an optional not an intrinsic geometric property like
> >> bounds, extent etc. So should it be moved into the category "rotate scale
> >> and flex"?
> >>
> >> rotationCenter also works with other properties like forwardDirection etc.
> >> They should also be considered for merging into Morphic. In fact, all the
> >> methods in Etoys-geometry could be moved to Morph as they don't use
> >> anything specific to Etoys (player).
> >
> > Looking at the definitions in the image, there are 4 definitions of these
> > methods.  The 3 definitions NOT in Etoys are in the method category
> > 'geometry etoy'.  So I'd suggest putting them there to at least have all of
> > them in the same place.
>
> So the proposal is to
>
> a) to move all from category '*Etoys-geometry* to category *geometry
> eToy* and then the two methods
>
> rotationCenter and rotationCenter:
>
> to category 'rotate scale and flex'
>

I think that Chris Cunningham is supporting your original proposal to move
rotationCenter and rotationCenter: from '*Etoys-geometry' in package Etoys
to 'geometry eToy' in package Morphic.

This seems right because it is consistent with other implementers of
rotationCenter and rotationCenter: in Morphic.

Subbu offered some additional suggestions, but let's get your original
fix into trunk first :-)  

Dave


cbc
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

cbc


On Mon, Jun 11, 2018 at 8:37 PM, David T. Lewis <[hidden email]> wrote:
On Mon, Jun 11, 2018 at 11:29:49PM +0200, H. Hirzel wrote:
>
> On 6/11/18, Chris Cunningham <[hidden email]> wrote:
>
> > On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]> wrote:
> >
> >> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
> >>
> >>> These two methods are sent by CircleMorph>>extent: in package Morphic-Basic,
> >>> so moving them from Etoys to Morphic seems the the right thing to do.
> >>> Does anyone disagree?
> >>
> >> rotationCenter is an optional not an intrinsic geometric property like
> >> bounds, extent etc. So should it be moved into the category "rotate scale
> >> and flex"?
> >>
> >> rotationCenter also works with other properties like forwardDirection etc.
> >> They should also be considered for merging into Morphic. In fact, all the
> >> methods in Etoys-geometry could be moved to Morph as they don't use
> >> anything specific to Etoys (player).
> >
> > Looking at the definitions in the image, there are 4 definitions of these
> > methods.  The 3 definitions NOT in Etoys are in the method category
> > 'geometry etoy'.  So I'd suggest putting them there to at least have all of
> > them in the same place.
>
> So the proposal is to
>
> a) to move all from category '*Etoys-geometry* to category *geometry
> eToy* and then the two methods
>
> rotationCenter and rotationCenter:
>
> to category 'rotate scale and flex'
>

I think that Chris Cunningham is supporting your original proposal to move
rotationCenter and rotationCenter: from '*Etoys-geometry' in package Etoys
to 'geometry eToy' in package Morphic.

This seems right because it is consistent with other implementers of
rotationCenter and rotationCenter: in Morphic.

Subbu offered some additional suggestions, but let's get your original
fix into trunk first :-) 

Dave
Thanks Dave,
that is what I intended.

Looking at what was committed, I think we should now move the other methods of the same name on different objects/packages also into the more specific method categories as well.

This could be the tip of the iceberg in re-classifying methods - I'm not sure how far this wants to go before the release, but at least related same methods should be categorized so the next person to encounter them see them consistently placed.

If no one beats me to it, I'll do that in before the next day passes (especially since I seem to be more motivated by it at the moment).

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

David T. Lewis
On Tue, Jun 12, 2018 at 03:28:38PM -0700, Chris Cunningham wrote:

> On Mon, Jun 11, 2018 at 8:37 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Mon, Jun 11, 2018 at 11:29:49PM +0200, H. Hirzel wrote:
> > >
> > > On 6/11/18, Chris Cunningham <[hidden email]> wrote:
> > >
> > > > On Mon, Jun 11, 2018 at 9:27 AM, K K Subbu <[hidden email]>
> > wrote:
> > > >
> > > >> On Monday 11 June 2018 06:24 PM, David T. Lewis wrote:
> > > >>
> > > >>> These two methods are sent by CircleMorph>>extent: in package
> > Morphic-Basic,
> > > >>> so moving them from Etoys to Morphic seems the the right thing to do.
> > > >>> Does anyone disagree?
> > > >>
> > > >> rotationCenter is an optional not an intrinsic geometric property like
> > > >> bounds, extent etc. So should it be moved into the category "rotate
> > scale
> > > >> and flex"?
> > > >>
> > > >> rotationCenter also works with other properties like forwardDirection
> > etc.
> > > >> They should also be considered for merging into Morphic. In fact, all
> > the
> > > >> methods in Etoys-geometry could be moved to Morph as they don't use
> > > >> anything specific to Etoys (player).
> > > >
> > > > Looking at the definitions in the image, there are 4 definitions of
> > these
> > > > methods.  The 3 definitions NOT in Etoys are in the method category
> > > > 'geometry etoy'.  So I'd suggest putting them there to at least have
> > all of
> > > > them in the same place.
> > >
> > > So the proposal is to
> > >
> > > a) to move all from category '*Etoys-geometry* to category *geometry
> > > eToy* and then the two methods
> > >
> > > rotationCenter and rotationCenter:
> > >
> > > to category 'rotate scale and flex'
> > >
> >
> > I think that Chris Cunningham is supporting your original proposal to move
> > rotationCenter and rotationCenter: from '*Etoys-geometry' in package Etoys
> > to 'geometry eToy' in package Morphic.
> >
> > This seems right because it is consistent with other implementers of
> > rotationCenter and rotationCenter: in Morphic.
> >
> > Subbu offered some additional suggestions, but let's get your original
> > fix into trunk first :-)
> >
> > Dave
> >
> Thanks Dave,
> that is what I intended.
>
> Looking at what was committed, I think we should now move the other methods
> of the same name on different objects/packages also into the more specific
> method categories as well.
>
> This could be the tip of the iceberg in re-classifying methods - I'm not
> sure how far this wants to go before the release, but at least related same
> methods should be categorized so the next person to encounter them see them
> consistently placed.
>
> If no one beats me to it, I'll do that in before the next day passes
> (especially since I seem to be more motivated by it at the moment).
>
> -cbc

Thanks Chris,

That sounds like a good idea, and it is all very low risk with respect
to the upcoming 5.2 release, so I see no reason that you should not go
ahead and re-classify where appropriate.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: EToys-hjh.333.mcz

Edgar J. De Cleene-3
I agree with this.
Here attach more methods should be moved out of Etoys for proper unload.
With this Etoys could be unload and 5.2 is usable, but can't load .pr as
still need more polish.
Is a step...

Again,

We do not must have Etoys unloadable now.
Time to freeze 5.2 and start to think 5.3 ?





On 12/06/2018, 19:36, "David T. Lewis" <[hidden email]> wrote:

> That sounds like a good idea, and it is all very low risk with respect
to the
> upcoming 5.2 release, so I see no reason that you should not go
ahead and
> re-classify where appropriate.

Dave




Morph-compatibility.st (2K) Download Attachment
ProjectLoading class-compatibility.1.st (15K) Download Attachment