Ok, thanks for the feedback.  I'll merge eagerly again.

On Mon, Jan 10, 2011 at 4:58 AM, Levente Uzonyi <leves at elte.hu> wrote:
> On Sun, 9 Jan 2011, Chris Muller wrote:
>
>> Thanks Levente.  However, since the trunk update merges everything
>> into our images anyway, it didn't seem necessary to be as eager about
>> merging as I used to be, especially when they are small, distant
>> changes.
>
> IMHO every package in the Trunk should always have one head version. Why?
> - it's error prone if it's not. I had to merge System-dtl.408 manually
> yesterday because the update process didn't do it for me. So my fully
> updated image didn't have that, but it had System-bp.408.
> - non-core developers may be confused by this and not contribute, or start
> merging in the Inbox which should never happen IMHO. Merging should be done
> by the integrator and in the Trunk only. If someone merges in the Inbox,
> then the integration will be much harder.
>
>>
>> I'd had a copyright notice change in System for 2011 year change and
>> thought I'd wait a bit to see if anything else comes in.
>>
>> I like to be lazy like this in particular with the Morphic package
>> because it's so large (and MC so inefficient in storing whole copies
>> of packages even when only one line changes..).
>
> While the Morphic package is large, the updates people download are usually
> just diffs (mcd) which are small.
>
>
> Levente
>
>>
>> - Chris
>>
>>
>> On Sun, Jan 9, 2011 at 12:18 PM, Levente Uzonyi <leves at elte.hu> wrote:
>>>
>>> On Sun, 9 Jan 2011, Frank Shearar wrote:
>>>
>>>> On 2011/01/09 16:21, Levente Uzonyi wrote:
>>>>>
>>>>> On Sun, 9 Jan 2011, Frank Shearar wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I ran into a pair of bugs by accident
>>>>>> (http://bugs.squeak.org/view.php?id=7595 and
>>>>>> http://bugs.squeak.org/view.php?id=7596) that are caused by the same
>>>>>> problem.
>>>>>>
>>>>>> If you have a MessageNames that shows Undeclared, and you select
>>>>>> Undeclared, you get a pair of walkbacks because code that expects a
>>>>>> class actually gets a Dictionary. The problem stems from Smalltalk
>>>>>> classNamed: #Undeclared returning something that's not actually a
>>>>>> class. (I suspect this kind of bug will manifest for other non-class
>>>>>> globals.)
>>>>>>
>>>>>> Now one workaround is possibly to turn code like this:
>>>>>>
>>>>>> selectedClassOrMetaClass
>>>>>> "Answer the currently selected class (or metaclass)."
>>>>>> messageListIndex > 0 ifTrue: [
>>>>>> ^ self setClassAndSelectorIn: [:c :s | ^c]].
>>>>>> (selectorListIndex isNil not and: [selectorListIndex > 0]) ifTrue:
>>>>>> [^Smalltalk classNamed: (self selectorList at: selectorListIndex)].
>>>>>> ^ nil.
>>>>>>
>>>>>> into something like this:
>>>>>>
>>>>>> selectedClassOrMetaClass
>>>>>> "Answer the currently selected class (or metaclass)."
>>>>>> messageListIndex > 0 ifTrue: [
>>>>>> ^ self setClassAndSelectorIn: [:c :s | ^c]].
>>>>>> (selectorListIndex isNil not and: [selectorListIndex > 0]) ifTrue:
>>>>>> [ | cls |
>>>>>> cls := Smalltalk classNamed: (self selectorList at:
>>>>>> selectorListIndex).
>>>>>> ^(cls isKindOf: Behavior) ifTrue: [cls]].
>>>>>> ^ nil.
>>>>>>
>>>>>> I dislike this. You'd have to check the result of #classNamed: for
>>>>>> being a class!
>>>>>>
>>>>>> I'd rather fix the underlying problem, and change
>>>>>> SystemDictionary>>classOrTraitNamed: so that the last clause said
>>>>>> something like
>>>>>>
>>>>>> baseClass := Smalltalk at: baseName asSymbol ifAbsent: [^ nil].
>>>>>> meta
>>>>>> ifTrue: [^ baseClass classSide]
>>>>>> ifFalse: [^ (baseClass isKindOf: Behavior) ifTrue: [baseClass]]
>>>>>>
>>>>>> That doesn't seem to smash up anything, but is the above _sane_?
>>>>>
>>>>> It's an old idea to ensure that #classNamed: returns a class (or maybe
>>>>> a
>>>>> trait), but I'm not sure it won't break anything.
>>>>> I think it would be better to write it like this:
>>>>>
>>>>> ^self at: baseName asSymbol ifPresent: [ :global |
>>>>> global isBehavior ifTrue: [
>>>>> meta
>>>>> ifFalse: [ global ]
>>>>> ifTrue: [ global classSide ] ] ]
>>>>
>>>> I'll prepare an MCZ with tests, in the meantime, and try bang on the
>>>> change.
>>>
>>> Thanks.
>>>
>>>>
>>>> It looks like System currently has two heads in trunk - System-bp.408
>>>> and
>>>> System-dtl.408. With a freshly updated trunk image, it thus looks like
>>>> there
>>>> are local changes to the image before I've done anything.
>>>
>>> Right, Chris forgot to merge the two versions when he pushed
>>> System-bp.408.
>>>
>>>
>>> Levente
>>>
>>>>
>>>> frank
>>>>
>>>>
>>>
>>>
>>
>>
>
>