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 <lewis at mail.msen.com> 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 <eliot.miranda at gmail.com> 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 <digit at sonic.net> 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>
>>>> 
>>> 
>>> 
>> 
> 
>