Method Finder and deprecated method(s)

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

Method Finder and deprecated method(s)

Tim Johnson-2
Hi all,

I seem to have stumbled into a few issues, and am taking the bold step
of including them all in a single email.  My apologies.  Tested/explored
in 6.0a-#17799.

Issues:

[1] The deprecation of SequenceableCollection>>#upTo:

[2] Removing deprecated #defaultBackgroundColor from MethodFinder

[3] MethodFinder class variable Dangerous and
MethodFinder>>#organizationFiltered:

So:

[1]

The deprecation of SequenceableCollection>>#upTo: means Method Finder
(a.k.a. Selector Browser) now pops up two modal dialogs if one enters
something like:

'deprecated '. 'method'. 'deprecated method'

...into its code entry pane and hits 'save'.

This appears to be due to the inclusion of #upTo: in
MethodFinder>>#initialize2 as a method which would be sent to a
PositionableStream... which seems reasonable.

According to ReadStream>>#readStream, a ReadStream is intended to be
polymorphic with SequencableCollection.  So, then, if #upTo: is an
intrinsic method of a Stream, does this mean it must be retained in
SequencableCollection? E.g. should it become undeprecated?

Though never until now have I thought about what it would take to use
Method Finder on a stream!  So I tried something similar to (but not
exactly) the following in a Workspace:

MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }  
"changed to protect the innocent user who put array braces in the wrong
place on his first attempt"

[2]

...and /another/ deprecation warning popped up:

"Object>>#defaultBackgroundColor has been deprecated. Implement
#uniformWindowColor and #customWindowColor in your model."

...#defaultBackgroundColor appears in method source 23 times, so there
are probably still a number of places where this deprecated method needs
to be engineered around :)   However, the place where it's probably
causing trouble in this case is in MethodFinder>>#initialize.  Attached
is a change set to remove it from that method.

[3]

However, there is another problem with MethodFinder>>#initialize and
#initialize2.  They both include comments at their respective ends which
call MethodFinder>>#organizationFiltered:, but that method fails due to
the class variable Dangerous being uninitialized.  The method which
initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.
  If I add "self noteDangerous" to one of the #initialize methods (I
added it to #initialize3 to test), this makes #organizationFiltered:
work again (after initializing MethodFinder).  Note that Dangerous is
not mentioned in the MethodFinder class comment, but other class
variables are.  I didn't do any research for how Dangerous is intended
to be useful.

Thanks for reading.

Best,
Tim


MethodFinder-Deprecated.cs (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Eliot Miranda-2
Hi Tim,


    it's great you're taking a look at MethodFinder.  Thanks! No one has responded but I expect that's because we're all busy.  You might make it easier for people to review and accept your work if you commit the changes packages to inbox instead of mailing a change set.  If that works for you go ahead, make sure the commit comment is helpful, and then report to the mailing list.

_,,,^..^,,,_ (phone)

> On Mar 11, 2018, at 11:23 AM, Tim Johnson <[hidden email]> wrote:
>
> Hi all,
>
> I seem to have stumbled into a few issues, and am taking the bold step of including them all in a single email.  My apologies.  Tested/explored in 6.0a-#17799.
>
> Issues:
>
> [1] The deprecation of SequenceableCollection>>#upTo:
>
> [2] Removing deprecated #defaultBackgroundColor from MethodFinder
>
> [3] MethodFinder class variable Dangerous and MethodFinder>>#organizationFiltered:
>
> So:
>
> [1]
>
> The deprecation of SequenceableCollection>>#upTo: means Method Finder (a.k.a. Selector Browser) now pops up two modal dialogs if one enters something like:
>
> 'deprecated '. 'method'. 'deprecated method'
>
> ...into its code entry pane and hits 'save'.
>
> This appears to be due to the inclusion of #upTo: in MethodFinder>>#initialize2 as a method which would be sent to a PositionableStream... which seems reasonable.
>
> According to ReadStream>>#readStream, a ReadStream is intended to be polymorphic with SequencableCollection.  So, then, if #upTo: is an intrinsic method of a Stream, does this mean it must be retained in SequencableCollection? E.g. should it become undeprecated?
>
> Though never until now have I thought about what it would take to use Method Finder on a stream!  So I tried something similar to (but not exactly) the following in a Workspace:
>
> MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }  "changed to protect the innocent user who put array braces in the wrong place on his first attempt"
>
> [2]
>
> ...and /another/ deprecation warning popped up:
>
> "Object>>#defaultBackgroundColor has been deprecated. Implement #uniformWindowColor and #customWindowColor in your model."
>
> ...#defaultBackgroundColor appears in method source 23 times, so there are probably still a number of places where this deprecated method needs to be engineered around :)   However, the place where it's probably causing trouble in this case is in MethodFinder>>#initialize.  Attached is a change set to remove it from that method.
>
> [3]
>
> However, there is another problem with MethodFinder>>#initialize and #initialize2.  They both include comments at their respective ends which call MethodFinder>>#organizationFiltered:, but that method fails due to the class variable Dangerous being uninitialized.  The method which initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.  If I add "self noteDangerous" to one of the #initialize methods (I added it to #initialize3 to test), this makes #organizationFiltered: work again (after initializing MethodFinder).  Note that Dangerous is not mentioned in the MethodFinder class comment, but other class variables are.  I didn't do any research for how Dangerous is intended to be useful.
>
> Thanks for reading.
>
> Best,
> Tim
> <MethodFinder-Deprecated.cs>
>

Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Hannes Hirzel
Is is about using the 'Inbox' (for non core developers)
http://wiki.squeak.org/squeak/6545

On 3/13/18, Eliot Miranda <[hidden email]> wrote:

> Hi Tim,
>
>
>     it's great you're taking a look at MethodFinder.  Thanks! No one has
> responded but I expect that's because we're all busy.  You might make it
> easier for people to review and accept your work if you commit the changes
> packages to inbox instead of mailing a change set.  If that works for you go
> ahead, make sure the commit comment is helpful, and then report to the
> mailing list.
>
> _,,,^..^,,,_ (phone)
>
>> On Mar 11, 2018, at 11:23 AM, Tim Johnson <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I seem to have stumbled into a few issues, and am taking the bold step of
>> including them all in a single email.  My apologies.  Tested/explored in
>> 6.0a-#17799.
>>
>> Issues:
>>
>> [1] The deprecation of SequenceableCollection>>#upTo:
>>
>> [2] Removing deprecated #defaultBackgroundColor from MethodFinder
>>
>> [3] MethodFinder class variable Dangerous and
>> MethodFinder>>#organizationFiltered:
>>
>> So:
>>
>> [1]
>>
>> The deprecation of SequenceableCollection>>#upTo: means Method Finder
>> (a.k.a. Selector Browser) now pops up two modal dialogs if one enters
>> something like:
>>
>> 'deprecated '. 'method'. 'deprecated method'
>>
>> ...into its code entry pane and hits 'save'.
>>
>> This appears to be due to the inclusion of #upTo: in
>> MethodFinder>>#initialize2 as a method which would be sent to a
>> PositionableStream... which seems reasonable.
>>
>> According to ReadStream>>#readStream, a ReadStream is intended to be
>> polymorphic with SequencableCollection.  So, then, if #upTo: is an
>> intrinsic method of a Stream, does this mean it must be retained in
>> SequencableCollection? E.g. should it become undeprecated?
>>
>> Though never until now have I thought about what it would take to use
>> Method Finder on a stream!  So I tried something similar to (but not
>> exactly) the following in a Workspace:
>>
>> MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }
>> "changed to protect the innocent user who put array braces in the wrong
>> place on his first attempt"
>>
>> [2]
>>
>> ...and /another/ deprecation warning popped up:
>>
>> "Object>>#defaultBackgroundColor has been deprecated. Implement
>> #uniformWindowColor and #customWindowColor in your model."
>>
>> ...#defaultBackgroundColor appears in method source 23 times, so there are
>> probably still a number of places where this deprecated method needs to be
>> engineered around :)   However, the place where it's probably causing
>> trouble in this case is in MethodFinder>>#initialize.  Attached is a
>> change set to remove it from that method.
>>
>> [3]
>>
>> However, there is another problem with MethodFinder>>#initialize and
>> #initialize2.  They both include comments at their respective ends which
>> call MethodFinder>>#organizationFiltered:, but that method fails due to
>> the class variable Dangerous being uninitialized.  The method which
>> initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.
>> If I add "self noteDangerous" to one of the #initialize methods (I added
>> it to #initialize3 to test), this makes #organizationFiltered: work again
>> (after initializing MethodFinder).  Note that Dangerous is not mentioned
>> in the MethodFinder class comment, but other class variables are.  I
>> didn't do any research for how Dangerous is intended to be useful.
>>
>> Thanks for reading.
>>
>> Best,
>> Tim
>> <MethodFinder-Deprecated.cs>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

David T. Lewis
Tim,

I'll second what Eliot said - If you do have the time to try committing
your changes to the inbox, that will be very much appreciated. This makes
it easier to review and move the changes directly to trunk, and it also
makes sure your ideas do not get lost if people are too busy to look at
the changes right now (which probably is the case at the moment).

The link that Hannes provided below (http://wiki.squeak.org/squeak/6545)
should be helpful. It is sometimes a bit of a pain trying this out for the
first time, but please do give it a try and ask questions if things do not
work as expected.

Thanks,
Dave


On Tue, Mar 13, 2018 at 09:57:40PM +0100, H. Hirzel wrote:

> Is is about using the 'Inbox' (for non core developers)
> http://wiki.squeak.org/squeak/6545
>
> On 3/13/18, Eliot Miranda <[hidden email]> wrote:
> > Hi Tim,
> >
> >
> >     it's great you're taking a look at MethodFinder.  Thanks! No one has
> > responded but I expect that's because we're all busy.  You might make it
> > easier for people to review and accept your work if you commit the changes
> > packages to inbox instead of mailing a change set.  If that works for you go
> > ahead, make sure the commit comment is helpful, and then report to the
> > mailing list.
> >
> > _,,,^..^,,,_ (phone)
> >
> >> On Mar 11, 2018, at 11:23 AM, Tim Johnson <[hidden email]> wrote:
> >>
> >> Hi all,
> >>
> >> I seem to have stumbled into a few issues, and am taking the bold step of
> >> including them all in a single email.  My apologies.  Tested/explored in
> >> 6.0a-#17799.
> >>
> >> Issues:
> >>
> >> [1] The deprecation of SequenceableCollection>>#upTo:
> >>
> >> [2] Removing deprecated #defaultBackgroundColor from MethodFinder
> >>
> >> [3] MethodFinder class variable Dangerous and
> >> MethodFinder>>#organizationFiltered:
> >>
> >> So:
> >>
> >> [1]
> >>
> >> The deprecation of SequenceableCollection>>#upTo: means Method Finder
> >> (a.k.a. Selector Browser) now pops up two modal dialogs if one enters
> >> something like:
> >>
> >> 'deprecated '. 'method'. 'deprecated method'
> >>
> >> ...into its code entry pane and hits 'save'.
> >>
> >> This appears to be due to the inclusion of #upTo: in
> >> MethodFinder>>#initialize2 as a method which would be sent to a
> >> PositionableStream... which seems reasonable.
> >>
> >> According to ReadStream>>#readStream, a ReadStream is intended to be
> >> polymorphic with SequencableCollection.  So, then, if #upTo: is an
> >> intrinsic method of a Stream, does this mean it must be retained in
> >> SequencableCollection? E.g. should it become undeprecated?
> >>
> >> Though never until now have I thought about what it would take to use
> >> Method Finder on a stream!  So I tried something similar to (but not
> >> exactly) the following in a Workspace:
> >>
> >> MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }
> >> "changed to protect the innocent user who put array braces in the wrong
> >> place on his first attempt"
> >>
> >> [2]
> >>
> >> ...and /another/ deprecation warning popped up:
> >>
> >> "Object>>#defaultBackgroundColor has been deprecated. Implement
> >> #uniformWindowColor and #customWindowColor in your model."
> >>
> >> ...#defaultBackgroundColor appears in method source 23 times, so there are
> >> probably still a number of places where this deprecated method needs to be
> >> engineered around :)   However, the place where it's probably causing
> >> trouble in this case is in MethodFinder>>#initialize.  Attached is a
> >> change set to remove it from that method.
> >>
> >> [3]
> >>
> >> However, there is another problem with MethodFinder>>#initialize and
> >> #initialize2.  They both include comments at their respective ends which
> >> call MethodFinder>>#organizationFiltered:, but that method fails due to
> >> the class variable Dangerous being uninitialized.  The method which
> >> initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.
> >> If I add "self noteDangerous" to one of the #initialize methods (I added
> >> it to #initialize3 to test), this makes #organizationFiltered: work again
> >> (after initializing MethodFinder).  Note that Dangerous is not mentioned
> >> in the MethodFinder class comment, but other class variables are.  I
> >> didn't do any research for how Dangerous is intended to be useful.
> >>
> >> Thanks for reading.
> >>
> >> Best,
> >> Tim
> >> <MethodFinder-Deprecated.cs>
> >>
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Eliot Miranda-2
In reply to this post by Hannes Hirzel


On Tue, Mar 13, 2018 at 1:57 PM, H. Hirzel <[hidden email]> wrote:
Is is about using the 'Inbox' (for non core developers)
http://wiki.squeak.org/squeak/6545

and this is the kind of documentation that, IMO, would be much more useful if there was a like to it from www.squeak.org, for example a curated page of links to the development process.
 


On 3/13/18, Eliot Miranda <[hidden email]> wrote:
> Hi Tim,
>
>
>     it's great you're taking a look at MethodFinder.  Thanks! No one has
> responded but I expect that's because we're all busy.  You might make it
> easier for people to review and accept your work if you commit the changes
> packages to inbox instead of mailing a change set.  If that works for you go
> ahead, make sure the commit comment is helpful, and then report to the
> mailing list.
>
> _,,,^..^,,,_ (phone)
>
>> On Mar 11, 2018, at 11:23 AM, Tim Johnson <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I seem to have stumbled into a few issues, and am taking the bold step of
>> including them all in a single email.  My apologies.  Tested/explored in
>> 6.0a-#17799.
>>
>> Issues:
>>
>> [1] The deprecation of SequenceableCollection>>#upTo:
>>
>> [2] Removing deprecated #defaultBackgroundColor from MethodFinder
>>
>> [3] MethodFinder class variable Dangerous and
>> MethodFinder>>#organizationFiltered:
>>
>> So:
>>
>> [1]
>>
>> The deprecation of SequenceableCollection>>#upTo: means Method Finder
>> (a.k.a. Selector Browser) now pops up two modal dialogs if one enters
>> something like:
>>
>> 'deprecated '. 'method'. 'deprecated method'
>>
>> ...into its code entry pane and hits 'save'.
>>
>> This appears to be due to the inclusion of #upTo: in
>> MethodFinder>>#initialize2 as a method which would be sent to a
>> PositionableStream... which seems reasonable.
>>
>> According to ReadStream>>#readStream, a ReadStream is intended to be
>> polymorphic with SequencableCollection.  So, then, if #upTo: is an
>> intrinsic method of a Stream, does this mean it must be retained in
>> SequencableCollection? E.g. should it become undeprecated?
>>
>> Though never until now have I thought about what it would take to use
>> Method Finder on a stream!  So I tried something similar to (but not
>> exactly) the following in a Workspace:
>>
>> MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }
>> "changed to protect the innocent user who put array braces in the wrong
>> place on his first attempt"
>>
>> [2]
>>
>> ...and /another/ deprecation warning popped up:
>>
>> "Object>>#defaultBackgroundColor has been deprecated. Implement
>> #uniformWindowColor and #customWindowColor in your model."
>>
>> ...#defaultBackgroundColor appears in method source 23 times, so there are
>> probably still a number of places where this deprecated method needs to be
>> engineered around :)   However, the place where it's probably causing
>> trouble in this case is in MethodFinder>>#initialize.  Attached is a
>> change set to remove it from that method.
>>
>> [3]
>>
>> However, there is another problem with MethodFinder>>#initialize and
>> #initialize2.  They both include comments at their respective ends which
>> call MethodFinder>>#organizationFiltered:, but that method fails due to
>> the class variable Dangerous being uninitialized.  The method which
>> initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.
>> If I add "self noteDangerous" to one of the #initialize methods (I added
>> it to #initialize3 to test), this makes #organizationFiltered: work again
>> (after initializing MethodFinder).  Note that Dangerous is not mentioned
>> in the MethodFinder class comment, but other class variables are.  I
>> didn't do any research for how Dangerous is intended to be useful.
>>
>> Thanks for reading.
>>
>> Best,
>> Tim
>> <MethodFinder-Deprecated.cs>
>>
>
>




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Tim Johnson-2
In reply to this post by David T. Lewis
Hi David, Eliot, Hannes —

Thanks for your suggestions.

Tonight I tried contributing my Tools patches to the inbox repo — first from my working 6.0a image, and then from a 6.0a with all trunk updates.  From both images, it pulled the removal of Context>>inspectorClass into my changes.  Not sure why, though I know inspectorClass was something recently changed by others.


How I tried to address / work around this:

In my working trunk image, I tried reverting (IIRC) Context>>inspectorClass's removal using Monticello Browser.  This left me in a state where I received a DNU whenever I tried to diff, show changes, or save to the inbox repo.   Things got ugly.  I saved screenshots.


In the freshly updated trunk image, I didn’t fool around with reverting or diffing inside of Monticello Browser.  I just went straight to trying a ’save’ to the inbox repo.   This successfully created a commit (no DNU) but the commit again included the removal of Context>>inspectorClass.  

Inside that commit window, I chose ‘revert (x)’ on the ‘Context>>inspectorClass’ item.  I then ‘cancel'ed out of the commit, thus dismissing the window.  I then (again) hit ‘save’ to the inbox repo.  This time, the commit window appeared and Context>>inspectorClass was not in my changes (yay).  I’ve submitted this commit to Inbox.


So:

How can I avoid a situation like this in the future?

Perhaps I should have also tried/built all of this against a freshly updated 5.1 image, instead of trunk?

In any case, I don’t think Context>>inspectorClass’s removal is being pulled into my changes because of anything I did.  Maybe it is missing that special something.  Or maybe (probably) I am the one missing something.

Thanks again,
Tim


> On Mar 14, 2018, at 4:15 PM, David T. Lewis <[hidden email]> wrote:
>
> Tim,
>
> I'll second what Eliot said - If you do have the time to try committing
> your changes to the inbox, that will be very much appreciated. This makes
> it easier to review and move the changes directly to trunk, and it also
> makes sure your ideas do not get lost if people are too busy to look at
> the changes right now (which probably is the case at the moment).
>
> The link that Hannes provided below (http://wiki.squeak.org/squeak/6545)
> should be helpful. It is sometimes a bit of a pain trying this out for the
> first time, but please do give it a try and ask questions if things do not
> work as expected.
>
> Thanks,
> Dave
>
>
> On Tue, Mar 13, 2018 at 09:57:40PM +0100, H. Hirzel wrote:
>> Is is about using the 'Inbox' (for non core developers)
>> http://wiki.squeak.org/squeak/6545
>>
>> On 3/13/18, Eliot Miranda <[hidden email]> wrote:
>>> Hi Tim,
>>>
>>>
>>>    it's great you're taking a look at MethodFinder.  Thanks! No one has
>>> responded but I expect that's because we're all busy.  You might make it
>>> easier for people to review and accept your work if you commit the changes
>>> packages to inbox instead of mailing a change set.  If that works for you go
>>> ahead, make sure the commit comment is helpful, and then report to the
>>> mailing list.
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>>> On Mar 11, 2018, at 11:23 AM, Tim Johnson <[hidden email]> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I seem to have stumbled into a few issues, and am taking the bold step of
>>>> including them all in a single email.  My apologies.  Tested/explored in
>>>> 6.0a-#17799.
>>>>
>>>> Issues:
>>>>
>>>> [1] The deprecation of SequenceableCollection>>#upTo:
>>>>
>>>> [2] Removing deprecated #defaultBackgroundColor from MethodFinder
>>>>
>>>> [3] MethodFinder class variable Dangerous and
>>>> MethodFinder>>#organizationFiltered:
>>>>
>>>> So:
>>>>
>>>> [1]
>>>>
>>>> The deprecation of SequenceableCollection>>#upTo: means Method Finder
>>>> (a.k.a. Selector Browser) now pops up two modal dialogs if one enters
>>>> something like:
>>>>
>>>> 'deprecated '. 'method'. 'deprecated method'
>>>>
>>>> ...into its code entry pane and hits 'save'.
>>>>
>>>> This appears to be due to the inclusion of #upTo: in
>>>> MethodFinder>>#initialize2 as a method which would be sent to a
>>>> PositionableStream... which seems reasonable.
>>>>
>>>> According to ReadStream>>#readStream, a ReadStream is intended to be
>>>> polymorphic with SequencableCollection.  So, then, if #upTo: is an
>>>> intrinsic method of a Stream, does this mean it must be retained in
>>>> SequencableCollection? E.g. should it become undeprecated?
>>>>
>>>> Though never until now have I thought about what it would take to use
>>>> Method Finder on a stream!  So I tried something similar to (but not
>>>> exactly) the following in a Workspace:
>>>>
>>>> MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }
>>>> "changed to protect the innocent user who put array braces in the wrong
>>>> place on his first attempt"
>>>>
>>>> [2]
>>>>
>>>> ...and /another/ deprecation warning popped up:
>>>>
>>>> "Object>>#defaultBackgroundColor has been deprecated. Implement
>>>> #uniformWindowColor and #customWindowColor in your model."
>>>>
>>>> ...#defaultBackgroundColor appears in method source 23 times, so there are
>>>> probably still a number of places where this deprecated method needs to be
>>>> engineered around :)   However, the place where it's probably causing
>>>> trouble in this case is in MethodFinder>>#initialize.  Attached is a
>>>> change set to remove it from that method.
>>>>
>>>> [3]
>>>>
>>>> However, there is another problem with MethodFinder>>#initialize and
>>>> #initialize2.  They both include comments at their respective ends which
>>>> call MethodFinder>>#organizationFiltered:, but that method fails due to
>>>> the class variable Dangerous being uninitialized.  The method which
>>>> initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.
>>>> If I add "self noteDangerous" to one of the #initialize methods (I added
>>>> it to #initialize3 to test), this makes #organizationFiltered: work again
>>>> (after initializing MethodFinder).  Note that Dangerous is not mentioned
>>>> in the MethodFinder class comment, but other class variables are.  I
>>>> didn't do any research for how Dangerous is intended to be useful.
>>>>
>>>> Thanks for reading.
>>>>
>>>> Best,
>>>> Tim
>>>> <MethodFinder-Deprecated.cs>
>>>>
>>>
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Eliot Miranda-2
Hi Tim,

On Wed, Mar 14, 2018 at 9:41 PM, Tim Johnson <[hidden email]> wrote:
Hi David, Eliot, Hannes —

Thanks for your suggestions.

Tonight I tried contributing my Tools patches to the inbox repo — first from my working 6.0a image, and then from a 6.0a with all trunk updates.  From both images, it pulled the removal of Context>>inspectorClass into my changes.  Not sure why, though I know inspectorClass was something recently changed by others.


How I tried to address / work around this:

In my working trunk image, I tried reverting (IIRC) Context>>inspectorClass's removal using Monticello Browser.  This left me in a state where I received a DNU whenever I tried to diff, show changes, or save to the inbox repo.   Things got ugly.  I saved screenshots.


In the freshly updated trunk image, I didn’t fool around with reverting or diffing inside of Monticello Browser.  I just went straight to trying a ’save’ to the inbox repo.   This successfully created a commit (no DNU) but the commit again included the removal of Context>>inspectorClass.

Where does the removal come form?  As required, Context>>inspectorClass is in Tools.  How is it being removed?


Inside that commit window, I chose ‘revert (x)’ on the ‘Context>>inspectorClass’ item.  I then ‘cancel'ed out of the commit, thus dismissing the window.  I then (again) hit ‘save’ to the inbox repo.  This time, the commit window appeared and Context>>inspectorClass was not in my changes (yay).  I’ve submitted this commit to Inbox.


So:

How can I avoid a situation like this in the future?

Perhaps I should have also tried/built all of this against a freshly updated 5.1 image, instead of trunk?

In any case, I don’t think Context>>inspectorClass’s removal is being pulled into my changes because of anything I did.  Maybe it is missing that special something.  Or maybe (probably) I am the one missing something.

Thanks again,
Tim


> On Mar 14, 2018, at 4:15 PM, David T. Lewis <[hidden email]> wrote:
>
> Tim,
>
> I'll second what Eliot said - If you do have the time to try committing
> your changes to the inbox, that will be very much appreciated. This makes
> it easier to review and move the changes directly to trunk, and it also
> makes sure your ideas do not get lost if people are too busy to look at
> the changes right now (which probably is the case at the moment).
>
> The link that Hannes provided below (http://wiki.squeak.org/squeak/6545)
> should be helpful. It is sometimes a bit of a pain trying this out for the
> first time, but please do give it a try and ask questions if things do not
> work as expected.
>
> Thanks,
> Dave
>
>
> On Tue, Mar 13, 2018 at 09:57:40PM +0100, H. Hirzel wrote:
>> Is is about using the 'Inbox' (for non core developers)
>> http://wiki.squeak.org/squeak/6545
>>
>> On 3/13/18, Eliot Miranda <[hidden email]> wrote:
>>> Hi Tim,
>>>
>>>
>>>    it's great you're taking a look at MethodFinder.  Thanks! No one has
>>> responded but I expect that's because we're all busy.  You might make it
>>> easier for people to review and accept your work if you commit the changes
>>> packages to inbox instead of mailing a change set.  If that works for you go
>>> ahead, make sure the commit comment is helpful, and then report to the
>>> mailing list.
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>>> On Mar 11, 2018, at 11:23 AM, Tim Johnson <[hidden email]> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I seem to have stumbled into a few issues, and am taking the bold step of
>>>> including them all in a single email.  My apologies.  Tested/explored in
>>>> 6.0a-#17799.
>>>>
>>>> Issues:
>>>>
>>>> [1] The deprecation of SequenceableCollection>>#upTo:
>>>>
>>>> [2] Removing deprecated #defaultBackgroundColor from MethodFinder
>>>>
>>>> [3] MethodFinder class variable Dangerous and
>>>> MethodFinder>>#organizationFiltered:
>>>>
>>>> So:
>>>>
>>>> [1]
>>>>
>>>> The deprecation of SequenceableCollection>>#upTo: means Method Finder
>>>> (a.k.a. Selector Browser) now pops up two modal dialogs if one enters
>>>> something like:
>>>>
>>>> 'deprecated '. 'method'. 'deprecated method'
>>>>
>>>> ...into its code entry pane and hits 'save'.
>>>>
>>>> This appears to be due to the inclusion of #upTo: in
>>>> MethodFinder>>#initialize2 as a method which would be sent to a
>>>> PositionableStream... which seems reasonable.
>>>>
>>>> According to ReadStream>>#readStream, a ReadStream is intended to be
>>>> polymorphic with SequencableCollection.  So, then, if #upTo: is an
>>>> intrinsic method of a Stream, does this mean it must be retained in
>>>> SequencableCollection? E.g. should it become undeprecated?
>>>>
>>>> Though never until now have I thought about what it would take to use
>>>> Method Finder on a stream!  So I tried something similar to (but not
>>>> exactly) the following in a Workspace:
>>>>
>>>> MethodFinder methodFor: { { 'deprecated' readStream . $c }.  'depre' }
>>>> "changed to protect the innocent user who put array braces in the wrong
>>>> place on his first attempt"
>>>>
>>>> [2]
>>>>
>>>> ...and /another/ deprecation warning popped up:
>>>>
>>>> "Object>>#defaultBackgroundColor has been deprecated. Implement
>>>> #uniformWindowColor and #customWindowColor in your model."
>>>>
>>>> ...#defaultBackgroundColor appears in method source 23 times, so there are
>>>> probably still a number of places where this deprecated method needs to be
>>>> engineered around :)   However, the place where it's probably causing
>>>> trouble in this case is in MethodFinder>>#initialize.  Attached is a
>>>> change set to remove it from that method.
>>>>
>>>> [3]
>>>>
>>>> However, there is another problem with MethodFinder>>#initialize and
>>>> #initialize2.  They both include comments at their respective ends which
>>>> call MethodFinder>>#organizationFiltered:, but that method fails due to
>>>> the class variable Dangerous being uninitialized.  The method which
>>>> initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.
>>>> If I add "self noteDangerous" to one of the #initialize methods (I added
>>>> it to #initialize3 to test), this makes #organizationFiltered: work again
>>>> (after initializing MethodFinder).  Note that Dangerous is not mentioned
>>>> in the MethodFinder class comment, but other class variables are.  I
>>>> didn't do any research for how Dangerous is intended to be useful.
>>>>
>>>> Thanks for reading.
>>>>
>>>> Best,
>>>> Tim
>>>> <MethodFinder-Deprecated.cs>
>>>>
>>>
>>>
>>
>
>





--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

timrowledge
from a completely different tim ...

> On 15-03-2018, at 12:12 PM, Eliot Miranda <[hidden email]> wrote:
> Where does the removal come form?  As required, Context>>inspectorClass is in Tools.  How is it being removed?

I've noticed this for some time and simply thought it might something I'd screwed up locally. Since I didn't recognise it nor have time to track anything down I've simply used the 'ignore' in MC to not-save it in versions of Tools that I've committed whilst doing the file dialogue stuff etc.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His shared libraries aren't installed.



Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Tim Johnson-2
In reply to this post by Eliot Miranda-2
Hi Eliot,

On Mar 15, 2018, at 12:12 PM, Eliot Miranda <[hidden email]> wrote:

In my working trunk image, I tried reverting (IIRC) Context>>inspectorClass's removal using Monticello Browser.  This left me in a state where I received a DNU whenever I tried to diff, show changes, or save to the inbox repo.   Things got ugly.  I saved screenshots.


In the freshly updated trunk image, I didn’t fool around with reverting or diffing inside of Monticello Browser.  I just went straight to trying a ’save’ to the inbox repo.   This successfully created a commit (no DNU) but the commit again included the removal of Context>>inspectorClass.

Where does the removal come form?  As required, Context>>inspectorClass is in Tools.  How is it being removed?

The current 6.0a image as downloaded from Squeak.org (Squeak6.0alpha-17606-32bit.image [Dec 21, 2017]) contains this anomaly and updating doesn’t help.

I just manually performed a bunch of diffs on the Tools project in the MC repository browser (I imagine there is a better way to do this).

It looks like Tools-eem.750.mcz is the last to have MethodContext>>inspectorClass in its *Extensions -> *Tools->Inspector.  Tools-eem.751.mcz is the first to have Context>>inspectorClass there.

Commit comment for Tools-eem.751.mcz (30 March 2017):

"Commit the essential cange of reference from MethodContext to Context before commiting the Kernel that does away with MethodContext."

Does that help?  

I have some suspicion, from my less-knowledgable viewpoint, that since MethodContext>>inspectorClass is in an *Extension, some subsequent commit could have come through in a different project, hadn’t updated to Tools-eem.751.mcz, and was missing Context>>inspectorClass?  But what do I know...

Thanks,
Tim




Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

Eliot Miranda-2
Hi Tim,


On Mar 15, 2018, at 1:31 PM, Tim Johnson <[hidden email]> wrote:

Hi Eliot,

On Mar 15, 2018, at 12:12 PM, Eliot Miranda <[hidden email]> wrote:

In my working trunk image, I tried reverting (IIRC) Context>>inspectorClass's removal using Monticello Browser.  This left me in a state where I received a DNU whenever I tried to diff, show changes, or save to the inbox repo.   Things got ugly.  I saved screenshots.


In the freshly updated trunk image, I didn’t fool around with reverting or diffing inside of Monticello Browser.  I just went straight to trying a ’save’ to the inbox repo.   This successfully created a commit (no DNU) but the commit again included the removal of Context>>inspectorClass.

Where does the removal come form?  As required, Context>>inspectorClass is in Tools.  How is it being removed?

The current 6.0a image as downloaded from Squeak.org (Squeak6.0alpha-17606-32bit.image [Dec 21, 2017]) contains this anomaly and updating doesn’t help.

I just manually performed a bunch of diffs on the Tools project in the MC repository browser (I imagine there is a better way to do this).

It looks like Tools-eem.750.mcz is the last to have MethodContext>>inspectorClass in its *Extensions -> *Tools->Inspector.  Tools-eem.751.mcz is the first to have Context>>inspectorClass there.

Commit comment for Tools-eem.751.mcz (30 March 2017):

"Commit the essential cange of reference from MethodContext to Context before commiting the Kernel that does away with MethodContext."

Does that help?  

I have some suspicion, from my less-knowledgable viewpoint, that since MethodContext>>inspectorClass is in an *Extension, some subsequent commit could have come through in a different project, hadn’t updated to Tools-eem.751.mcz, and was missing Context>>inspectorClass?  But what do I know...

Well, the problem is not in trunk, and we're converging in the next release being 5.2.  So perhaps we should take down the 6.0a image that is causing problems and try again.  IIRC if I do ReleaseBuilder saveAsNewRelease then the resulting image is perfectly fine.



Thanks,
Tim





Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

David T. Lewis
In reply to this post by Tim Johnson-2
Hi Tim,

Whatever the issues you were having, your two inbox submissions were fine and
they matched the changes sets that you sent in your earlier email (I checked),
so all is well.

I moved your two inbox submissions to trunk.

Thanks!
Dave

On Thu, Mar 15, 2018 at 01:31:13PM -0700, Tim Johnson wrote:

> Hi Eliot,
>
> > On Mar 15, 2018, at 12:12 PM, Eliot Miranda <[hidden email]> wrote:
> >
> > In my working trunk image, I tried reverting (IIRC) Context>>inspectorClass's removal using Monticello Browser.  This left me in a state where I received a DNU whenever I tried to diff, show changes, or save to the inbox repo.   Things got ugly.  I saved screenshots.
> >
> >
> > In the freshly updated trunk image, I didn???t fool around with reverting or diffing inside of Monticello Browser.  I just went straight to trying a ???save??? to the inbox repo.   This successfully created a commit (no DNU) but the commit again included the removal of Context>>inspectorClass.
> >
> > Where does the removal come form?  As required, Context>>inspectorClass is in Tools.  How is it being removed?
>
> The current 6.0a image as downloaded from Squeak.org <http://squeak.org/> (Squeak6.0alpha-17606-32bit.image [Dec 21, 2017]) contains this anomaly and updating doesn???t help.
>
> I just manually performed a bunch of diffs on the Tools project in the MC repository browser (I imagine there is a better way to do this).
>
> It looks like Tools-eem.750.mcz is the last to have MethodContext>>inspectorClass in its *Extensions -> *Tools->Inspector.  Tools-eem.751.mcz is the first to have Context>>inspectorClass there.
>
> Commit comment for Tools-eem.751.mcz (30 March 2017):
>
> "Commit the essential cange of reference from MethodContext to Context before commiting the Kernel that does away with MethodContext."
>
> Does that help?  
>
> I have some suspicion, from my less-knowledgable viewpoint, that since MethodContext>>inspectorClass is in an *Extension, some subsequent commit could have come through in a different project, hadn???t updated to Tools-eem.751.mcz, and was missing Context>>inspectorClass?  But what do I know...
>
> Thanks,
> Tim
>
>

>


cbc
Reply | Threaded
Open this post in threaded view
|

Re: Method Finder and deprecated method(s)

cbc
In reply to this post by Tim Johnson-2


On Sun, Mar 11, 2018 at 11:23 AM, Tim Johnson <[hidden email]> wrote:
Hi all,

I seem to have stumbled into a few issues, and am taking the bold step of including them all in a single email.  My apologies.  Tested/explored in 6.0a-#17799.

Issues:

[1] The deprecation of SequenceableCollection>>#upTo:

[2] Removing deprecated #defaultBackgroundColor from MethodFinder

[3] MethodFinder class variable Dangerous and MethodFinder>>#organizationFiltered:

So:

<snip> 

[3]

However, there is another problem with MethodFinder>>#initialize and #initialize2.  They both include comments at their respective ends which call MethodFinder>>#organizationFiltered:, but that method fails due to the class variable Dangerous being uninitialized.  The method which initializes Dangerous, MethodFinder>>#noteDangerous, looks to be unsent.  If I add "self noteDangerous" to one of the #initialize methods (I added it to #initialize3 to test), this makes #organizationFiltered: work again (after initializing MethodFinder).  Note that Dangerous is not mentioned in the MethodFinder class comment, but other class variables are.  I didn't do any research for how Dangerous is intended to be useful.

Hi.

I don't think that #organizationFiltered: is a method to be sent to MethodFinder often.  It was probably used to initialize the arrays of methods to use - and the comments where it was called out look to be notes to a future instance of the individual that added the notes to come back in and add those methods.  Which probably didn't happen.

If you notice the comments for the class MethodFinder, it start off near the top saying: 
    "Done by brute force, trying every possible selector."
This means it tries to run each method against the first element of the candidate you pass into MethodFinder.  if there are bad side effects (such as #becomeForward:, say) then you really, REALLY don't want to run those methods against the first object - you could wind up destroying the image (or, worst case, destroying things on your system!)

Dangerous is to try and protect against those methods - calling out ones we really don't ever want to run.

On the other hand, if you are adventurous, then you can run the #organizationFiltered: method against a new class and pull in those methods to try.  This would then give you a string that you could paste into one of the #initialize methods (probably #initialize3) following the pattern of previous authors.  But, make sure to look over those methods and think about what would happen if passed to an object - such as a FileDirectory,and remove any additional ones that are dangerous.  And ideally add those dangerous ones to #noteDangerous.

As to where to put a call to  #noteDangerous, I'd strongly suggest adding it to #organizationFiltered:, right at the beginning.  It is the only method that uses it, and there isn't any other reason to build that array.
 
Thanks for reading.
Thanks for being interested - and pushing down this far.  I'd noticed the variable before, but hadn't drilled down enough to track down WHY it was nil.  I enjoyed the push. 

Best,
Tim



-cbc