Hi Tim,

On Wed, Mar 14, 2018 at 9:41 PM, Tim Johnson <digit at sonic.net> 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 <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>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180315/4a50381c/attachment.html>