Method Finder and deprecated method(s)

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>
>>
>
>

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>
>>>>
>>>
>>>
>>
>
>

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:

[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