This is the Help System failure...
Locked
12
12
 
|
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 |
Re: This is the Help System failure...
|
|
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:
|
|
|
Yes, verified. If this method is reverted, the tests run. On Sat, Jul 14, 2018 at 7:43 AM, karl ramberg <[hidden email]> wrote:
|
|
|
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)
Re: This is the Help System failure...
|
|
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 > > > > > |
Re: This is the Help System failure...
|
|
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 > |
|
|
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 > > >> > > |
Re: This is the Help System failure...
|
|
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 > > >> > > |
|
|
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, With this change, the tests run successfully. Thank you, cbc Regards .. Subbu |
Re: This is the Help System failure...
|
|
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 > > >> |
Re: This is the Help System failure...
|
|
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 >> >> >>> >> >> |
Re: This is the Help System failure...
|
|
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 > >> > >> > >>> > >> > >> |
|
|
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, |
Re: This is the Help System failure...
|
|
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 > > >> > > >> > > >>> > > >> > > >> > > > > |
Re: This is the Help System failure...
|
|
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 >>>> >>>> >>>>> >>>> >>>> > |
Re: This is the Help System failure...
|
|
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 |
Re: This is the Help System failure...
|
|
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 |
Re: This is the Help System failure...
|
|
> 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 |
Re: This is the Help System failure...
|
|
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 >>>>> >>>>> >>>>>> >>>>> >>>>> >> > |
Re: This is the Help System failure...
|
|
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 >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>> >> > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |