Re: The Inbox: Tools-fbs.338.mcz

> A new version of Tools was added to project The Inbox:
> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>
> ==================== Summary ====================
>
> Name: Tools-fbs.338
> Author: fbs
> Time: 31 March 2011, 1:38:40.964 pm
> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
> Ancestors: Tools-fbs.337
>
> Re-add the instvar "growable", accidentally removed in 332 or 333.
>

> If I may be so bold, I'd love some review of this and its related packages:
>
> * Tools-fbs.338
> * ToolsTest-fbs.38
> * Morphic-fbs.526
> * Services-Base.47
> * System-fbs.427
>
> Word has it that Eliot promised to integrate RB into the base browser!
> Evidence!:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html

> On 2011/03/31 12:38, [hidden email] wrote:
>>
>> A new version of Tools was added to project The Inbox:
>> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Tools-fbs.338
>> Author: fbs
>> Time: 31 March 2011, 1:38:40.964 pm
>> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
>> Ancestors: Tools-fbs.337
>>
>> Re-add the instvar "growable", accidentally removed in 332 or 333.
>>
> If I may be so bold, I'd love some review of this and its related packages:
>
> * Tools-fbs.338
> * ToolsTest-fbs.38
> * Morphic-fbs.526
> * Services-Base.47
> * System-fbs.427
>
> Word has it that Eliot promised to integrate RB into the base browser!
> Evidence!:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html
>
> frank
>
>

> On Thu, Apr 7, 2011 at 1:09 PM, Frank Shearar
> <[hidden email]> wrote:
>
>> If I may be so bold, I'd love some review of this and its related packages:
>>
>> * Tools-fbs.338
>> * ToolsTest-fbs.38
>> * Morphic-fbs.526
>> * Services-Base.47
>> * System-fbs.427
>>
>> Word has it that Eliot promised to integrate RB into the base browser!
>> Evidence!:
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html
>
> Um, why not just use OmniBrowser? It already has refactoring support.
>
> Colin
>
>

> On 2011/03/31 12:38, [hidden email] wrote:
>>
>> A new version of Tools was added to project The Inbox:
>> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Tools-fbs.338
>> Author: fbs
>> Time: 31 March 2011, 1:38:40.964 pm
>> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
>> Ancestors: Tools-fbs.337
>>
>> Re-add the instvar "growable", accidentally removed in 332 or 333.
>>
> If I may be so bold, I'd love some review of this and its related packages:
>
> * Tools-fbs.338
> * ToolsTest-fbs.38
> * Morphic-fbs.526
> * Services-Base.47
> * System-fbs.427
>
> Word has it that Eliot promised to integrate RB into the base browser!
> Evidence!:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html
>
> frank
>
>

> I didn't reviewed (and I'm not a big fan of StringHolder hierarchy),
> but one good thing is that we can merge those 5 files without hanging
> an updated trunk image...
> So integration should be easy.
>
> Nicolas
>
> 2011/4/7 Frank Shearar <[hidden email]>:
>> On 2011/03/31 12:38, [hidden email] wrote:
>>>
>>> A new version of Tools was added to project The Inbox:
>>> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Tools-fbs.338
>>> Author: fbs
>>> Time: 31 March 2011, 1:38:40.964 pm
>>> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
>>> Ancestors: Tools-fbs.337
>>>
>>> Re-add the instvar "growable", accidentally removed in 332 or 333.
>>>
>> If I may be so bold, I'd love some review of this and its related packages:
>>
>> * Tools-fbs.338
>> * ToolsTest-fbs.38
>> * Morphic-fbs.526
>> * Services-Base.47
>> * System-fbs.427
>>
>> Word has it that Eliot promised to integrate RB into the base browser!
>> Evidence!:
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html
>>
>> frank
>>
>>
>

> Oh wait, I just didn't merge the right ones because those MC changes
> once again messed a cache or something, and my MC browser didn't show
> me the last updates...
> I will have to redo. Maybe tomorrow...
>
> Nicolas
>
> 2011/4/7 Nicolas Cellier <[hidden email]>:
>> I didn't reviewed (and I'm not a big fan of StringHolder hierarchy),
>> but one good thing is that we can merge those 5 files without hanging
>> an updated trunk image...
>> So integration should be easy.
>>
>> Nicolas
>>
>> 2011/4/7 Frank Shearar <[hidden email]>:
>>> On 2011/03/31 12:38, [hidden email] wrote:
>>>>
>>>> A new version of Tools was added to project The Inbox:
>>>> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Tools-fbs.338
>>>> Author: fbs
>>>> Time: 31 March 2011, 1:38:40.964 pm
>>>> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
>>>> Ancestors: Tools-fbs.337
>>>>
>>>> Re-add the instvar "growable", accidentally removed in 332 or 333.
>>>>
>>> If I may be so bold, I'd love some review of this and its related packages:
>>>
>>> * Tools-fbs.338
>>> * ToolsTest-fbs.38
>>> * Morphic-fbs.526
>>> * Services-Base.47
>>> * System-fbs.427
>>>
>>> Word has it that Eliot promised to integrate RB into the base browser!
>>> Evidence!:
>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html
>>>
>>> frank
>>>
>>>
>>
>

> On 2011/03/31 12:38, [hidden email] wrote:
>> A new version of Tools was added to project The Inbox:
>> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Tools-fbs.338
>> Author: fbs
>> Time: 31 March 2011, 1:38:40.964 pm
>> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
>> Ancestors: Tools-fbs.337
>>
>> Re-add the instvar "growable", accidentally removed in 332 or 333.
>>
> If I may be so bold, I'd love some review of this and its related packages:
>
> * Tools-fbs.338
> * ToolsTest-fbs.38
> * Morphic-fbs.526
> * Services-Base.47
> * System-fbs.427
>
> Word has it that Eliot promised to integrate RB into the base browser!
> Evidence!:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html

> On Thu, 7 Apr 2011, Frank Shearar wrote:
>
>> On 2011/03/31 12:38, [hidden email] wrote:
>>> A new version of Tools was added to project The Inbox:
>>> http://source.squeak.org/inbox/Tools-fbs.338.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Tools-fbs.338
>>> Author: fbs
>>> Time: 31 March 2011, 1:38:40.964 pm
>>> UUID: 373272eb-3606-7746-b992-2194e8ebc1f7
>>> Ancestors: Tools-fbs.337
>>>
>>> Re-add the instvar "growable", accidentally removed in 332 or 333.
>>>
>> If I may be so bold, I'd love some review of this and its related
>> packages:
>>
>> * Tools-fbs.338
>> * ToolsTest-fbs.38
>> * Morphic-fbs.526
>> * Services-Base.47
>> * System-fbs.427
>>
>> Word has it that Eliot promised to integrate RB into the base browser!
>> Evidence!:
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/153302.html
>>
>
> Great. I thought it's complete, but you didn't express it explicitly, so
> I wasn't sure. Do you know about dependencies that we should care about
> during integration?

> On Thu, Apr 7, 2011 at 4:27 PM, Levente Uzonyi <[hidden email]> wrote:
>> On Thu, 7 Apr 2011, Colin Putney wrote:
>
>> It has. But it's badly broken (e.g. buttons don't work). People who tried to
>> fix it have no access to the repository to push their fixes, so they posted
>> fixes to this mailing list...
>
> Ok, that's fixable. I've made it possible to anyone to commit to
> http://www.squeaksource.com/OmniBrowser. I'll treat that like an INBOX
> repository for OB. The trunk is still at http://source.wiresong.ca/ob/
> which isn't public writable (that proved problematic), but I'll be
> happy to give commit rights there to anyone who wants to contribute.

>
>> The Metacello configuration was also broken, I just fixed it.
>
> Great, thank you.
>
>> If we would like to keep OB alive, then we have to fix the bugs first, then
>> consider merging enhancements from Lukas' repository.
>
> Ok, sounds like a plan.
>
> I'll go through bugs.squeak.org and assess what's still relevant. If
> folks have issues that aren't recorded there, feel free to bring them
> up here, or enter them directly into Mantis.

> On Fri, 8 Apr 2011, Frank Shearar wrote:
>
>> When I load it into a virgin image I follow the order above. I
>> wouldn't stake my life on it being entirely 100% correct. There might
>> be some interaction between the Morphic and Tools packages, in
>> particular, because the Morphic version has changes to how Browsers open.
>>
>> I have, for instance, noticed that my image "goes away" sometimes when
>> I load Morphic. I can hit alt-. and abandon the process, and
>> everything Just Works.
>
> I finally set up my Trunk clone, where I could test the integration of
> your changes. I didn't face the problem you described, but I found
> another one. MessageSets (senders, implementors, etc) opened before the
> update will have their messageListIndex instance variable uninitialized.
> This means that #messageListIndex will return nil instead of an integer.
> So if I had some senders/implementors browsers open before the update, I
> get a debugger for each of them after it. Implementing #messageListIndex as
>
> ^messageListIndex ifNil: [ 0 ]
>
> solves this issue. The state of the browsers will not be preserved this
> way, but it's not worth writing complex migration code for this IMHO.

> On 4/11/11, Frank Shearar<[hidden email]>  wrote:
>> On 2011/04/11 01:46, Levente Uzonyi wrote:
>>> On Fri, 8 Apr 2011, Frank Shearar wrote:
>>>
>>>> When I load it into a virgin image I follow the order above. I
>>>> wouldn't stake my life on it being entirely 100% correct. There might
>>>> be some interaction between the Morphic and Tools packages, in
>>>> particular, because the Morphic version has changes to how Browsers open.
>>>>
>>>> I have, for instance, noticed that my image "goes away" sometimes when
>>>> I load Morphic. I can hit alt-. and abandon the process, and
>>>> everything Just Works.
>>>
>>> I finally set up my Trunk clone, where I could test the integration of
>>> your changes. I didn't face the problem you described, but I found
>>> another one. MessageSets (senders, implementors, etc) opened before the
>>> update will have their messageListIndex instance variable uninitialized.
>>> This means that #messageListIndex will return nil instead of an integer.
>>> So if I had some senders/implementors browsers open before the update, I
>>> get a debugger for each of them after it. Implementing #messageListIndex
>>> as
>>>
>>> ^messageListIndex ifNil: [ 0 ]
>>>
>>> solves this issue. The state of the browsers will not be preserved this
>>> way, but it's not worth writing complex migration code for this IMHO.
>>
>> Ah yes, because of instvar move: the new MessageSet instvar will be nil,
>> and nothing's yet set it to a valid value (i.e., an index).
>>
>> See version 339!
>>
>> frank
>>
>>
>
>
> What is the decision on this?
>
> And: Do we need to keep the old versions in the inbox?

> On 2011/04/15 18:21, Hannes Hirzel wrote:
>> On 4/11/11, Frank Shearar<[hidden email]>  wrote:
>>> On 2011/04/11 01:46, Levente Uzonyi wrote:
>>>> On Fri, 8 Apr 2011, Frank Shearar wrote:
>>>>
>>>>> When I load it into a virgin image I follow the order above. I
>>>>> wouldn't stake my life on it being entirely 100% correct. There might
>>>>> be some interaction between the Morphic and Tools packages, in
>>>>> particular, because the Morphic version has changes to how Browsers
>>>>> open.
>>>>>
>>>>> I have, for instance, noticed that my image "goes away" sometimes when
>>>>> I load Morphic. I can hit alt-. and abandon the process, and
>>>>> everything Just Works.
>>>>
>>>> I finally set up my Trunk clone, where I could test the integration of
>>>> your changes. I didn't face the problem you described, but I found
>>>> another one. MessageSets (senders, implementors, etc) opened before the
>>>> update will have their messageListIndex instance variable uninitialized.
>>>> This means that #messageListIndex will return nil instead of an integer.
>>>> So if I had some senders/implementors browsers open before the update, I
>>>> get a debugger for each of them after it. Implementing #messageListIndex
>>>> as
>>>>
>>>> ^messageListIndex ifNil: [ 0 ]
>>>>
>>>> solves this issue. The state of the browsers will not be preserved this
>>>> way, but it's not worth writing complex migration code for this IMHO.
>>>
>>> Ah yes, because of instvar move: the new MessageSet instvar will be nil,
>>> and nothing's yet set it to a valid value (i.e., an index).
>>>
>>> See version 339!
>>>
>>> frank
>>>
>>>
>>
>>
>> What is the decision on this?
>>
>> And: Do we need to keep the old versions in the inbox?
>
> Levente said that _all_ versions should be into Treated when everyone's
> happy, so that we have complete and entire Monticello histories.
>
> Of course, I can't comment on the decision :)
>
> frank
>
>

>
> --Hannes
>
> On 4/15/11, Frank Shearar<[hidden email]>  wrote:
>> On 2011/04/15 18:21, Hannes Hirzel wrote:
>>> On 4/11/11, Frank Shearar<[hidden email]>   wrote:
>>>> On 2011/04/11 01:46, Levente Uzonyi wrote:
>>>>> On Fri, 8 Apr 2011, Frank Shearar wrote:
>>>>>
>>>>>> When I load it into a virgin image I follow the order above. I
>>>>>> wouldn't stake my life on it being entirely 100% correct. There might
>>>>>> be some interaction between the Morphic and Tools packages, in
>>>>>> particular, because the Morphic version has changes to how Browsers
>>>>>> open.
>>>>>>
>>>>>> I have, for instance, noticed that my image "goes away" sometimes when
>>>>>> I load Morphic. I can hit alt-. and abandon the process, and
>>>>>> everything Just Works.
>>>>>
>>>>> I finally set up my Trunk clone, where I could test the integration of
>>>>> your changes. I didn't face the problem you described, but I found
>>>>> another one. MessageSets (senders, implementors, etc) opened before the
>>>>> update will have their messageListIndex instance variable uninitialized.
>>>>> This means that #messageListIndex will return nil instead of an integer.
>>>>> So if I had some senders/implementors browsers open before the update, I
>>>>> get a debugger for each of them after it. Implementing #messageListIndex
>>>>> as
>>>>>
>>>>> ^messageListIndex ifNil: [ 0 ]
>>>>>
>>>>> solves this issue. The state of the browsers will not be preserved this
>>>>> way, but it's not worth writing complex migration code for this IMHO.
>>>>
>>>> Ah yes, because of instvar move: the new MessageSet instvar will be nil,
>>>> and nothing's yet set it to a valid value (i.e., an index).
>>>>
>>>> See version 339!
>>>>
>>>> frank
>>>>
>>>>
>>>
>>>
>>> What is the decision on this?
>>>
>>> And: Do we need to keep the old versions in the inbox?
>>
>> Levente said that _all_ versions should be into Treated when everyone's
>> happy, so that we have complete and entire Monticello histories.
>>
>> Of course, I can't comment on the decision :)
>>
>> frank
>>
>>
>
>
>

> On 2011/04/15 18:21, Hannes Hirzel wrote:
>> On 4/11/11, Frank Shearar<[hidden email]>  wrote:
>>> On 2011/04/11 01:46, Levente Uzonyi wrote:
>>>> On Fri, 8 Apr 2011, Frank Shearar wrote:
>>>>
>>>>> When I load it into a virgin image I follow the order above. I
>>>>> wouldn't stake my life on it being entirely 100% correct. There might
>>>>> be some interaction between the Morphic and Tools packages, in
>>>>> particular, because the Morphic version has changes to how Browsers
>>>>> open.
>>>>>
>>>>> I have, for instance, noticed that my image "goes away" sometimes when
>>>>> I load Morphic. I can hit alt-. and abandon the process, and
>>>>> everything Just Works.
>>>>
>>>> I finally set up my Trunk clone, where I could test the integration of
>>>> your changes. I didn't face the problem you described, but I found
>>>> another one. MessageSets (senders, implementors, etc) opened before the
>>>> update will have their messageListIndex instance variable uninitialized.
>>>> This means that #messageListIndex will return nil instead of an integer.
>>>> So if I had some senders/implementors browsers open before the update, I
>>>> get a debugger for each of them after it. Implementing #messageListIndex
>>>> as
>>>>
>>>> ^messageListIndex ifNil: [ 0 ]
>>>>
>>>> solves this issue. The state of the browsers will not be preserved this
>>>> way, but it's not worth writing complex migration code for this IMHO.
>>>
>>> Ah yes, because of instvar move: the new MessageSet instvar will be nil,
>>> and nothing's yet set it to a valid value (i.e., an index).
>>>
>>> See version 339!
>>>
>>> frank
>>>
>>>
>>
>>
>> What is the decision on this?
>>
>> And: Do we need to keep the old versions in the inbox?
>
> Levente said that _all_ versions should be into Treated when everyone's
> happy, so that we have complete and entire Monticello histories.