Test run, new errors since last build (advice requested)

> Currently we have three more errors than we had in the last build that I
> rolled. I'm looking at a run on #10532.
>
> In general I'd recon it's an improvement, except for the errors (I don't
> mind new failures as long as the total number of tests has gone up by an
> equal or greater amount, but errors just give me the willies.) Also, the
> errors are to do with some stuff that looks like it could be hairy. Blocks
> and finalization. If these can be blessed by more experienced folks than me
> as "not that big a deal" then I would be quite happy to roll a build
> tomorrow night.
> Here's the numbers:
>
> 2803 run, 2762 passes, 9 expected failures, 28 failures, 4 errors, 0
> unexpected passes
>
> 25 new tests
>
> 9 expected failures (no change)
>
> 28 failures (2 more than the previous image)
>
> 4 errors (3 more than the previous image)
>
> Errors:
>
> EventManagerTest>>
>
> #testBlockReceiverNoArgs
>
> #testBlockReceiverOneArg
>
> #testBlockReceiverTwoArgs
>

> 2010/9/21 Casey Ransberger <[hidden email]>:
>> Currently we have three more errors than we had in the last build that I
>> rolled. I'm looking at a run on #10532.
>>
>> In general I'd recon it's an improvement, except for the errors (I don't
>> mind new failures as long as the total number of tests has gone up by an
>> equal or greater amount, but errors just give me the willies.) Also, the
>> errors are to do with some stuff that looks like it could be hairy. Blocks
>> and finalization. If these can be blessed by more experienced folks than me
>> as "not that big a deal" then I would be quite happy to roll a build
>> tomorrow night.
>> Here's the numbers:
>>
>> 2803 run, 2762 passes, 9 expected failures, 28 failures, 4 errors, 0
>> unexpected passes
>>
>> 25 new tests
>>
>> 9 expected failures (no change)
>>
>> 28 failures (2 more than the previous image)
>>
>> 4 errors (3 more than the previous image)
>>
>> Errors:
>>
>> EventManagerTest>>
>>
>> #testBlockReceiverNoArgs
>>
>> #testBlockReceiverOneArg
>>
>> #testBlockReceiverTwoArgs
>>
>
> Oh, I see, it was me introducing clean-up from Juan for
> http://bugs.squeak.org/view.php?id=7352 in
> http://source.squeak.org/trunk/Kernel-nice.482.mcz
>
> Obviously, WeakActionSequence now restricts element class to
> MessageSend and WeakMessageSend...
> I see three solutions:
>
> 1) implement the 3 compatibility messages into classes of "valuable"
> objects (like BlockClosure)
> 2) wrap those valuable object into a (MessageSend receiver:
> valuableObject selector: #value) at creation time
> 3) revert the changes... and reintroduce the bug :(
>
> I don't like 1 because it's spreading very specific messages in the system.
> I don't like 3 because there's enough bugs in the image.
> I much prefer 2)
>
> Any other idea?
>

> Nicolas
>
>> WeakFinalizersTest>>#testNewFinalizationSupported
>>
>> --
>> Casey Ransberger
>>
>>
>>
>>
>

>
>
> On Tue, Sep 21, 2010 at 1:14 AM, Nicolas Cellier
> <[hidden email]> wrote:
>>
>> 2010/9/21 Nicolas Cellier <[hidden email]>:
>> > 2010/9/21 Casey Ransberger <[hidden email]>:
>> >> Currently we have three more errors than we had in the last build that
>> >> I
>> >> rolled. I'm looking at a run on #10532.
>> >>
>> >> In general I'd recon it's an improvement, except for the errors (I
>> >> don't
>> >> mind new failures as long as the total number of tests has gone up by
>> >> an
>> >> equal or greater amount, but errors just give me the willies.) Also,
>> >> the
>> >> errors are to do with some stuff that looks like it could be hairy.
>> >> Blocks
>> >> and finalization. If these can be blessed by more experienced folks
>> >> than me
>> >> as "not that big a deal" then I would be quite happy to roll a build
>> >> tomorrow night.
>> >> Here's the numbers:
>> >>
>> >> 2803 run, 2762 passes, 9 expected failures, 28 failures, 4 errors, 0
>> >> unexpected passes
>> >>
>> >> 25 new tests
>> >>
>> >> 9 expected failures (no change)
>> >>
>> >> 28 failures (2 more than the previous image)
>> >>
>> >> 4 errors (3 more than the previous image)
>> >>
>> >> Errors:
>> >>
>> >> EventManagerTest>>
>> >>
>> >> #testBlockReceiverNoArgs
>> >>
>> >> #testBlockReceiverOneArg
>> >>
>> >> #testBlockReceiverTwoArgs
>> >>
>> >
>> > Oh, I see, it was me introducing clean-up from Juan for
>> > http://bugs.squeak.org/view.php?id=7352 in
>> > http://source.squeak.org/trunk/Kernel-nice.482.mcz
>> >
>> > Obviously, WeakActionSequence now restricts element class to
>> > MessageSend and WeakMessageSend...
>> > I see three solutions:
>> >
>> > 1) implement the 3 compatibility messages into classes of "valuable"
>> > objects (like BlockClosure)
>> > 2) wrap those valuable object into a (MessageSend receiver:
>> > valuableObject selector: #value) at creation time
>> > 3) revert the changes... and reintroduce the bug :(
>> >
>> > I don't like 1 because it's spreading very specific messages in the
>> > system.
>> > I don't like 3 because there's enough bugs in the image.
>> > I much prefer 2)
>> >
>> > Any other idea?
>> >
>>
>> On the other hand there is already a protocol 'events-support' in
>> BlockClosure with two messages #asMinimalRepresentation #isValid, so
>> 1) was the previous option adopted in Squeak.
>
> +1.  But is 'events-support' correct or is 'finalization support' better?

>>
>> Note that the second message #isValid is not used anymore after Juan's
>> clean-up and could be removed.
>>
>> Nicolas
>>
>> > Nicolas
>> >
>> >> WeakFinalizersTest>>#testNewFinalizationSupported
>> >>
>> >> --
>> >> Casey Ransberger
>> >>
>> >>
>> >>
>> >>
>> >
>>
>
>
>
>
>