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