[squeak-dev] This is the Help System failure...

H. Hirzel hannes.hirzel at gmail.com
Mon Jul 16 05:43:09 UTC 2018


Hello

I did not follow this thread in detail.

I updated an image two times and got


========== Collections-dtl.802 ==========

Bypass Collections.kks.801.mcz for now because it leads to a problem
opening the help browser.

==========  Update completed:  18145 -> 18146 ==========


The HelpBrowser error was still there.

Karl Ramberg pointed out (2nd post) that


      The recent change to Text>>setString: aString setRunsChecking:
aRunArray caused it.

So I reverted that method and the HelpBrowser works again.

The method is now again the version ar 4/9/2010

Seems to be the way to fix it.

Regards
Hannes






On 7/15/18, Tobias Pape <Das.Linux at gmx.de> wrote:
>
>> On 14.07.2018, at 23:49, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>>
>> It is well known that the MC model was not designed for projects of this
>> size. But it would save almost nothing if that version were removed form
>> the ancestry.
>>
>
> I agree with that fullheartedly.
> best 	
> -t
>
>> Levente
>>
>> On Sat, 14 Jul 2018, Chris Muller wrote:
>>
>>> If it's the top version and just an "oops" commit that just occurred,
>>> then cementing over it instead of discarding it means it becomes
>>> another object in the object memory history of every future
>>> trunk-derived image, forever (based on MC's current design).  That's
>>> reason enough for me.
>>> On Sat, Jul 14, 2018 at 3:09 PM Levente Uzonyi <leves at caesar.elte.hu>
>>> wrote:
>>>>
>>>> On Sat, 14 Jul 2018, Chris Muller wrote:
>>>>
>>>>> Thanks for doing it that way, since it's only a temporary minor
>>>>> inconvenience for trunk developers to remove the unwanted ancestor
>>>>> (assuming they've already updated) vs. making a permanent record of an
>>>>> unintended commit.
>>>>
>>>> Removing something from the Trunk should be the last resort. That would
>>>> be
>>>> totally unnecessary in this case.
>>>>
>>>> Levente
>>>>
>>>>>
>>>>> On Sat, Jul 14, 2018 at 12:17 PM, David T. Lewis <lewis at mail.msen.com>
>>>>> wrote:
>>>>>> Hi Subbu,
>>>>>>
>>>>>> I resaved Collections in trunk to bypass the 801 update for the time
>>>>>> being.
>>>>>>
>>>>>> I'm not sure I should have done it that way, it may leave an
>>>>>> unresolved
>>>>>> merge for people who were already up to date (sorry for that).
>>>>>>
>>>>>> Dave
>>>>>>
>>>>>> On Sat, Jul 14, 2018 at 10:32:25PM +0530, K K Subbu wrote:
>>>>>>> On Saturday 14 July 2018 09:56 AM, Chris Cunningham wrote:
>>>>>>>> HelpBrowserTest>>testOpen
>>>>>>>>
>>>>>>>> the selected item (Welcome) has the red cross in it, and 2 debug
>>>>>>>> windows
>>>>>>>> on UndefinedObject>>findBinaryIndex:ifNone: show up.
>>>>>>>
>>>>>>> I can confirm this error. When HelpBrowser starts displaying the
>>>>>>> contents of Welcome text, it triggers an out of bounds error while
>>>>>>> processing its text based on its runArray (see attached picture).
>>>>>>> This
>>>>>>> in turn triggers the above error.
>>>>>>>
>>>>>>> Here are my steps:
>>>>>>> 1. Start Squeak without Collections-kks.801 mcz
>>>>>>> 2. Open Workspace, type "HelpBrowserText new open"
>>>>>>> 3. Help window opens with "Welcome" subtopic. Close this window
>>>>>>> 4. Now install Collections-kks.801 mcz
>>>>>>> 5. In Workspace, do "HelpBrowserTest new open"
>>>>>>>
>>>>>>> This will open an out of bounds error first and then an
>>>>>>> UndefinedObject
>>>>>>> error on top.
>>>>>>>
>>>>>>> Welcome text is only 2173 bytes long, but in basicScanByte....,
>>>>>>> startIndex:   2171
>>>>>>> stopIndex:    4302 (!)
>>>>>>>
>>>>>>> In CompositionScanner>>composeFrom:...., runLength is being computed
>>>>>>> as
>>>>>>> 2188 (!) for a startIndex of 2115.
>>>>>>>
>>>>>>> Chris/Karl, thanks for finding this testcase. This may help us track
>>>>>>> down a long pending bug in Squeak's handling of styled text.
>>>>>>>
>>>>>>> Regards .. Subbu
>>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>
>
>
>


More information about the Squeak-dev mailing list