StandardScriptingSystem cleanup raises an MNU

I'm seeing this during the ReleaseSqueakTrunk job:

ByteString(Object)>>doesNotUnderstand: #costume
[] in StandardScriptingSystem class>>removeUnreferencedPlayers
Array(SequenceableCollection)>>do:
StandardScriptingSystem class>>removeUnreferencedPlayers

StandardScriptingSystem class>>cleanUp:

But what's super entertaining about this is that the relevant method
looks like this (whitespace ruined thanks to Gmail):

removeUnreferencedPlayers
    "Remove existing but unreferenced player references"
    "StandardScriptingSystem removeUnreferencedPlayers"
    References keys do:
        [ : key | | ref |
        ref := References at: key.
        ((ref respondsTo: #costume) and: [ ref costume pasteUpMorph
isNil ]) ifTrue: [ References removeKey: key ] ]

So despite the #respondsTo: guard, a ByteString still gets into the
second block. Thoughts?

frank

On 09-02-2014, at 2:19 PM, Frank Shearar <[hidden email]> wrote:
> So despite the #respondsTo: guard, a ByteString still gets into the
> second block. Thoughts?

Well you *are* testing ‘ref’ rather than ‘key’.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: TOAC: Turn Off Air Conditioner

On 9 February 2014 22:22, tim Rowledge <[hidden email]> wrote:
>
> On 09-02-2014, at 2:19 PM, Frank Shearar <[hidden email]> wrote:
>> So despite the #respondsTo: guard, a ByteString still gets into the
>> second block. Thoughts?
>
> Well you *are* testing ‘ref’ rather than ‘key’.

Eh? It's "ref respondsTo: #costume" and then "ref costume".

frank

> tim

On 09-02-2014, at 2:56 PM, Frank Shearar <[hidden email]> wrote:

> On 9 February 2014 22:22, tim Rowledge <[hidden email]> wrote:
>>
>> On 09-02-2014, at 2:19 PM, Frank Shearar <[hidden email]> wrote:
>>> So despite the #respondsTo: guard, a ByteString still gets into the
>>> second block. Thoughts?
>>
>> Well you *are* testing ‘ref’ rather than ‘key’.
>
> Eh? It's "ref respondsTo: #costume" and then "ref costume”.

Sorry -  miscounted blocks. I saw  [ References removeKey: key ] as the second one… thought you were checking ref and then using key. Getting a ‘true’ from the respondsTo: and then a dNU: is more than a bit worrying.

I’m always a bit worried when  I see code iterating across a collection that includes removing something from that collection. Can’t quite see how that would affect your code though.

References is empty in my image so I can’t really examine anything for class. Looks to me like only Players ought to be in there so a ByteString seems like evidence of some interesting bug.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ED: Eject Disk

On 9 February 2014 23:18, tim Rowledge <[hidden email]> wrote:
There's something else weird going on, in that the build says it's
using a 4.5-13352 image. That's very, very old. So perhaps there's
some lurking bad state causing an apparently unrelated symptom. I've
just nuked the relevant workspace, and let's see if that doesn't fix
things.

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: ED: Eject Disk
>
>
>