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_? frank |
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 ] ] ] Levente > > frank > > |
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. 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. frank |
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 > > |
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. 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..). - Chris On Sun, Jan 9, 2011 at 12:18 PM, Levente Uzonyi <[hidden email]> 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 >> >> > > |
On 1/9/11 9:20 PM, "Chris Muller" <[hidden email]> wrote: > 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..). Being ReleaseManager gives you a different view of how the system could be build. This could solved with a mixed scheme as SqueakLight. We could have old style updates in .cs form and with trunk procedure (Monticello) Or we could use DeltaStreams. Or we could use Monticello2. Edgar |
In reply to this post by Chris Muller-3
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 <[hidden email]> 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 >>> >>> >> >> > > |
On 10.01.2011, at 11:58, Levente Uzonyi 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 What he said. - Bert - |
In reply to this post by Levente Uzonyi-2
Ok, thanks for the feedback. I'll merge eagerly again.
On Mon, Jan 10, 2011 at 4:58 AM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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 >>>> >>>> >>> >>> >> >> > > |
Free forum by Nabble | Edit this page |