<div dir="ltr">So, Levente/Chris/David,<div><br><div>to fix this - do we delete the kks.801 from trunk, or alter kks.803 in the inbox (which seems to fix the issue) to have both dtl.802 (it's current parent) and kks.801 as both of its parents, which I believe would solve the 'multi head' issue.</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 14, 2018 at 1:25 PM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If it's the top version and just an "oops" commit that just occurred,<br>
then cementing over it instead of discarding it means it becomes<br>
another object in the object memory history of every future<br>
trunk-derived image, forever (based on MC's current design).  That's<br>
reason enough for me.<br>
<div class="HOEnZb"><div class="h5">On Sat, Jul 14, 2018 at 3:09 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>> wrote:<br>
><br>
> On Sat, 14 Jul 2018, Chris Muller wrote:<br>
><br>
> > Thanks for doing it that way, since it's only a temporary minor<br>
> > inconvenience for trunk developers to remove the unwanted ancestor<br>
> > (assuming they've already updated) vs. making a permanent record of an<br>
> > unintended commit.<br>
><br>
> Removing something from the Trunk should be the last resort. That would be<br>
> totally unnecessary in this case.<br>
><br>
> Levente<br>
><br>
> ><br>
> > On Sat, Jul 14, 2018 at 12:17 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> >> Hi Subbu,<br>
> >><br>
> >> I resaved Collections in trunk to bypass the 801 update for the time<br>
> >> being.<br>
> >><br>
> >> I'm not sure I should have done it that way, it may leave an unresolved<br>
> >> merge for people who were already up to date (sorry for that).<br>
> >><br>
> >> Dave<br>
> >><br>
> >> On Sat, Jul 14, 2018 at 10:32:25PM +0530, K K Subbu wrote:<br>
> >>> On Saturday 14 July 2018 09:56 AM, Chris Cunningham wrote:<br>
> >>> >HelpBrowserTest>>testOpen<br>
> >>> ><br>
> >>> >the selected item (Welcome) has the red cross in it, and 2 debug windows<br>
> >>> >on UndefinedObject>><wbr>findBinaryIndex:ifNone: show up.<br>
> >>><br>
> >>> I can confirm this error. When HelpBrowser starts displaying the<br>
> >>> contents of Welcome text, it triggers an out of bounds error while<br>
> >>> processing its text based on its runArray (see attached picture). This<br>
> >>> in turn triggers the above error.<br>
> >>><br>
> >>> Here are my steps:<br>
> >>> 1. Start Squeak without Collections-kks.801 mcz<br>
> >>> 2. Open Workspace, type "HelpBrowserText new open"<br>
> >>> 3. Help window opens with "Welcome" subtopic. Close this window<br>
> >>> 4. Now install Collections-kks.801 mcz<br>
> >>> 5. In Workspace, do "HelpBrowserTest new open"<br>
> >>><br>
> >>> This will open an out of bounds error first and then an UndefinedObject<br>
> >>> error on top.<br>
> >>><br>
> >>> Welcome text is only 2173 bytes long, but in basicScanByte....,<br>
> >>> startIndex:   2171<br>
> >>> stopIndex:    4302 (!)<br>
> >>><br>
> >>> In CompositionScanner>><wbr>composeFrom:...., runLength is being computed as<br>
> >>> 2188 (!) for a startIndex of 2115.<br>
> >>><br>
> >>> Chris/Karl, thanks for finding this testcase. This may help us track<br>
> >>> down a long pending bug in Squeak's handling of styled text.<br>
> >>><br>
> >>> Regards .. Subbu<br>
> >><br>
> >><br>
> >>><br>
> >><br>
> >><br>
<br>
</div></div></blockquote></div><br></div>