[squeak-dev] Smalltalk global instances

Levente Uzonyi leves at elte.hu
Mon Jan 10 10:58:50 UTC 2011


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



More information about the Squeak-dev mailing list