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 |
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 |
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 >> > > > > |
Yes but Environments are not stabilized yet. Look for example at CompiledMethodTest>>#testMethodClass2013/5/3 Frank Shearar <[hidden email]> Well, what's really strange is that ScriptLoader has nothing to do at |
On Fri, May 3, 2013 at 1:18 PM, Nicolas Cellier <[hidden email]> wrote:
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]>
|
And about moving the biding to undeclared, this might be a good thing, because removing class TUTU, then adding it again will re-bind all references.
2013/5/5 Nicolas Cellier <[hidden email]>
|
On Sun, May 5, 2013 at 8:09 AM, Nicolas Cellier <[hidden email]> wrote:
Right. I made the change in order to get ClassRemovalTest>>testClassRemovalAndRecompilationWontCreateDuplicateVariableBindings to pass.
|
Free forum by Nabble | Edit this page |