This is the Help System failure...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
cbc
Reply | Threaded
Open this post in threaded view
|

This is the Help System failure...

cbc
HelpBrowserTest>>testOpen

the selected item (Welcome) has the red cross in it, and 2 debug windows on UndefinedObject>>findBinaryIndex:ifNone: show up.

And as for the lockup?  As long as you don't click on the red X box, you are ok. Once you click on it, Squeak lockup, time to go to the process list and kill it (window close doesn't work).

Thanks,
cbc


Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Karl Ramberg
The recent change to Text>>setString: aString setRunsChecking: aRunArray cause this

Best,
Karl



On Sat, Jul 14, 2018 at 6:26 AM Chris Cunningham <[hidden email]> wrote:
HelpBrowserTest>>testOpen

the selected item (Welcome) has the red cross in it, and 2 debug windows on UndefinedObject>>findBinaryIndex:ifNone: show up.

And as for the lockup?  As long as you don't click on the red X box, you are ok. Once you click on it, Squeak lockup, time to go to the process list and kill it (window close doesn't work).

Thanks,
cbc



cbc
Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

cbc
Yes, verified.  If this method is reverted, the tests run.

On Sat, Jul 14, 2018 at 7:43 AM, karl ramberg <[hidden email]> wrote:
The recent change to Text>>setString: aString setRunsChecking: aRunArray cause this

Best,
Karl



On Sat, Jul 14, 2018 at 6:26 AM Chris Cunningham <[hidden email]> wrote:
HelpBrowserTest>>testOpen

the selected item (Welcome) has the red cross in it, and 2 debug windows on UndefinedObject>>findBinaryIndex:ifNone: show up.

And as for the lockup?  As long as you don't click on the red X box, you are ok. Once you click on it, Squeak lockup, time to go to the process list and kill it (window close doesn't work).

Thanks,
cbc







Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

K K Subbu
In reply to this post by cbc
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



helpbrowser-crash.png (96K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

David T. Lewis
In reply to this post by Karl Ramberg
Oops, that's not a good thing, I'll revert it for now.

Thanks

On Sat, Jul 14, 2018 at 04:43:52PM +0200, karl ramberg wrote:

> The recent change to Text>>setString: aString setRunsChecking: aRunArray
> cause this
>
> Best,
> Karl
>
>
>
> On Sat, Jul 14, 2018 at 6:26 AM Chris Cunningham <[hidden email]>
> wrote:
>
> > HelpBrowserTest>>testOpen
> >
> > the selected item (Welcome) has the red cross in it, and 2 debug windows
> > on UndefinedObject>>findBinaryIndex:ifNone: show up.
> >
> > And as for the lockup?  As long as you don't click on the red X box, you
> > are ok. Once you click on it, Squeak lockup, time to go to the process list
> > and kill it (window close doesn't work).
> >
> > Thanks,
> > cbc
> >
> >

>


Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

David T. Lewis
In reply to this post by K K Subbu
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


>


Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

K K Subbu
David,

I feel very silly to have let a typo slip through. Late night hacking
and all that :-(. I should have reviewed my change thoroughly before
saving it to inbox. Apologies to all who were affected.

Chris/Karl, could you please verify if the changeset I posted today to
inbox solves your problem? Only a single method is changed. Thanks.

Regards .. Subbu

On Saturday 14 July 2018 10:47 PM, David T. Lewis 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
>
>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Chris Muller-3
In reply to this post by David T. Lewis
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.

On Sat, Jul 14, 2018 at 12:17 PM, David T. Lewis <[hidden email]> 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
>
>
>>
>
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

cbc
In reply to this post by K K Subbu

On Sat, Jul 14, 2018 at 10:53 AM, K K Subbu <[hidden email]> wrote:
David,

I feel very silly to have let a typo slip through. Late night hacking and all that :-(. I should have reviewed my change thoroughly before saving it to inbox. Apologies to all who were affected.

Chris/Karl, could you please verify if the changeset I posted today to inbox solves your problem? Only a single method is changed. Thanks.

With this change, the tests run successfully.
Thank you,
cbc
 
Regards .. Subbu


Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Levente Uzonyi
In reply to this post by David T. Lewis
On Sat, 14 Jul 2018, David T. Lewis 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).

Indeed, the package now has two head versions in the Trunk. The best
would have been to simply commit a new version of the package.

Levente

>
> 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
>
>
>>

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Levente Uzonyi
In reply to this post by Chris Muller-3
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 <[hidden email]> 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
>>
>>
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Chris Muller-4
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 <[hidden email]> 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 <[hidden email]> 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
> >>
> >>
> >>>
> >>
> >>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

cbc
So, Levente/Chris/David,

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.


On Sat, Jul 14, 2018 at 1:25 PM, Chris Muller <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>
> >>
> >>>
> >>
> >>




Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Levente Uzonyi
On Sat, 14 Jul 2018, Chris Cunningham wrote:

> So, Levente/Chris/David,
> 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.

Neither. The proper solution is to create a new version which merges the
two branches. If the fix is in kks.803, then xxx.804 will contain the fix
and have both kks.803 and kks.801 as ancestors.

Levente

>
>
> On Sat, Jul 14, 2018 at 1:25 PM, Chris Muller <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>       > >>
>       > >>
>       > >>>
>       > >>
>       > >>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Levente Uzonyi
In reply to this post by Chris Muller-4
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.

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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>>>
>>>>>
>>>>
>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Chris Muller-3
In reply to this post by Levente Uzonyi
>> So, Levente/Chris/David,
>> 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.
>
> Neither. The proper solution is to create a new version which merges the two
> branches. If the fix is in kks.803, then xxx.804 will contain the fix and
> have both kks.803 and kks.801 as ancestors.

Wow.

> It is well known that the MC model was not designed for projects of this size.

Right.

> But it would save almost nothing if that version were removed form the ancestry.

Your suggestion above puts "almost nothing" at up to no less than
three new versions in the ancestry for a one method fix.  It is not
just about disk space, or memory space, or exacerbating our unscalable
dimensions, but clutter, too.  Those are my rationale's for deleting.
I didn't catch any solid rationale for the idea of littering the
ancestry when we have the opportunity not to.

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Levente Uzonyi
On Sat, 14 Jul 2018, Chris Muller wrote:

>>> So, Levente/Chris/David,
>>> 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.
>>
>> Neither. The proper solution is to create a new version which merges the two
>> branches. If the fix is in kks.803, then xxx.804 will contain the fix and
>> have both kks.803 and kks.801 as ancestors.
>
> Wow.
>
>> It is well known that the MC model was not designed for projects of this size.
>
> Right.
>
>> But it would save almost nothing if that version were removed form the ancestry.
>
> Your suggestion above puts "almost nothing" at up to no less than
> three new versions in the ancestry for a one method fix.  It is not
> just about disk space, or memory space, or exacerbating our unscalable
> dimensions, but clutter, too.  Those are my rationale's for deleting.
> I didn't catch any solid rationale for the idea of littering the
> ancestry when we have the opportunity not to.

So, you would rather break the images of everyone who had updated before
the suggested removal of the verions?

Levente

>
> - Chris

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Chris Muller-4
> So, you would rather break the images of everyone who had updated before
> the suggested removal of the verions?

It doesn't break anything.  The original commit is what broke the
images of the very few who updated, and only for a very short period
of time, because Dave got it removed quickly.  So, what would be nice
now would be for it not to incur a permanent cost on top of that, for
every image for everyone, forever.  I know three more versions seems
like not much, but they add up.

 - Chris

> 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.

> >>> So, Levente/Chris/David,
> >>> 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.
> >>
> >> Neither. The proper solution is to create a new version which merges the two
> >> branches. If the fix is in kks.803, then xxx.804 will contain the fix and
> >> have both kks.803 and kks.801 as ancestors.
> >
> > Wow.
> >
> >> It is well known that the MC model was not designed for projects of this size.
> >
> > Right.
> >
> >> But it would save almost nothing if that version were removed form the ancestry.
> >
> > Your suggestion above puts "almost nothing" at up to no less than
> > three new versions in the ancestry for a one method fix.  It is not
> > just about disk space, or memory space, or exacerbating our unscalable
> > dimensions, but clutter, too.  Those are my rationale's for deleting.
> > I didn't catch any solid rationale for the idea of littering the
> > ancestry when we have the opportunity not to.
>
> So, you would rather break the images of everyone who had updated before
> the suggested removal of the verions?
>
> Levente
>
> >
> > - Chris

Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Tobias Pape
In reply to this post by Levente Uzonyi

> On 14.07.2018, at 23:49, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>
>>>>>
>>>>>>
>>>>>
>>>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: This is the Help System failure...

Hannes Hirzel
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 <[hidden email]> wrote:

>
>> On 14.07.2018, at 23:49, Levente Uzonyi <[hidden email]> 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 <[hidden email]>
>>> 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 <[hidden email]>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>
>
>
>

12