Weird transient Traits test error

http://build.squeak.org/job/SqueakTrunk/296/testReport/ shows a bunch
of failing tests.

The only difference between that build and the previous is the
upgrading of ScriptLoader from fbs.336 to fbs.337.

And then the next run the tests all passed...

Lots of the failures were in Parser >> #notify:at:, which throws a
SyntaxErrorNotification. As it happens, the CommandLineToolSet doesn't
implement that method.

But any ideas why those tests might have failed?

frank

Well, what's really strange is that ScriptLoader has nothing to do at
all with Traits. I just moved a class from one package to another, and
then the tests failed. I mean, I wouldn't bet my life on saying "the
build is deterministic", but it really ought to be very close to it.

frank

On 3 May 2013 21:04, Nicolas Cellier <[hidden email]> wrote:
> Any relation with Method/Class package relocation and package loadOrder?
>
>
> 2013/5/3 Frank Shearar <[hidden email]>
>>
>> http://build.squeak.org/job/SqueakTrunk/296/testReport/ shows a bunch
>> of failing tests.
>>
>> The only difference between that build and the previous is the
>> upgrading of ScriptLoader from fbs.336 to fbs.337.
>>
>> And then the next run the tests all passed...
>>
>> Lots of the failures were in Parser >> #notify:at:, which throws a
>> SyntaxErrorNotification. As it happens, the CommandLineToolSet doesn't
>> implement that method.
>>
>> But any ideas why those tests might have failed?
>>
>> frank
>>
>
>
>
>

On Fri, May 3, 2013 at 1:18 PM, Nicolas Cellier <[hidden email]> wrote:

Yes but Environments are not stabilized yet.

Look for example at CompiledMethodTest>>#testMethodClass

It is failing because Environment>>#forgetClass:logged: moves the class binding in undeclared (Dictionary>>#declare:from: ), but then overwrite the value with nil.

Thus the references to AnObsoleteTUTU are then nilled out...

Isn't that the correct behaviour? Direct references to the class by name should be nil, but any variables that refer to the class object still have a reference to the obsolete class, and instances still have their state but don't understand messages because their class is obsolete. 

If that's not the correct behaviour, what is?

Colin

Previous versions did not move the binding to undeclared. They did just remove it.

The binding did still point to the obsolete class, and that is what is tested in testMethodClass.

I don't know what the correct Behaviour is...

I can just tell that it has changed.

In VW, there is a direct pointer from a CompiledMethod to the class because become is cheap.

In Squeak, the pointer is indirect thru the binding, so IMO it's an implementation detail.

Since we still have the binding name though, I wonder if it's really interesting to have the value pointing to obsolete class...

If not, we can eventually change the test.

2013/5/4 Colin Putney <[hidden email]>

On Fri, May 3, 2013 at 1:18 PM, Nicolas Cellier <[hidden email]> wrote:

Yes but Environments are not stabilized yet.

Look for example at CompiledMethodTest>>#testMethodClass

It is failing because Environment>>#forgetClass:logged: moves the class binding in undeclared (Dictionary>>#declare:from: ), but then overwrite the value with nil.

Thus the references to AnObsoleteTUTU are then nilled out...

Isn't that the correct behaviour? Direct references to the class by name should be nil, but any variables that refer to the class object still have a reference to the obsolete class, and instances still have their state but don't understand messages because their class is obsolete. 

If that's not the correct behaviour, what is?

Colin