On 25 April 2013 07:41, Frank Shearar frank.shearar@gmail.com wrote:
On 25 April 2013 03:31, Levente Uzonyi leves@elte.hu wrote:
On Wed, 24 Apr 2013, Frank Shearar wrote:
So I wrote a very basic CommandLineToolSet (please! save me and suggest a better name!). It can "debug" errors by dumping a stack trace to stderr and kill the image.
So now the CI tests use this, and the following tests fail:
ToolsTests.Browser.BrowseTest.testBrowseClass ToolsTests.Browser.BrowseTest.testBrowseHierarchyClass ToolsTests.Browser.BrowseTest.testBrowseHierarchyInstance ToolsTests.Browser.BrowseTest.testBrowseHierarchyMataclass ToolsTests.Browser.BrowseTest.testBrowseInstance ToolsTests.Browser.BrowseTest.testBrowseMetaclass ToolsTests.Browser.DependencyBrowserTest.testBrowse ToolsTests.Inspector.WeakSetInspectorTest.testSymbolTableM6812
That's because these tests actually want the StandardToolSet. One idea that occurs to me is to use a #setUp/#tearDown combo to re-set the ToolSet. That comes at the risk of things blowing up in a test causing CI jobs to hang; the very reason I wrote the CommandLineToolSet.
So before I do that, any other ideas? Essentially I'm looking for a scoped ToolSet change. I think?
What about making CommandLineToolSet a subclass of StandardToolSet? That way everything would work unless there's an error.
Yes, I suppose I could do that. It would certainly scratch my current itch. Thanks!
The other option is to fill out the ToolSet protocol with empty methods. But that wouldn't be very least-surprise-ish.
Yep, we're down to 5 failing tests!
Only one of those is Environments related - Tests.Release.ReleaseTest.testMethodsWithUnboundGlobals - which times out because it's trying to concatenate the world's biggest string.
Actually, Tests.Bugs.ClassRemovalTest.testClassRemovalAndRecompilationWontCreateDuplicateVariableBinding might be Environment related.
frank
Levente
frank
squeak-dev@lists.squeakfoundation.org