Hi!
Running the tests for a recent trunk image I get the following:
error | ClosureCompilerTest | testSourceRangeAccessForBlueBo okInjectInto error | ClosureCompilerTest | testSourceRangeAccessForInjectInto error | ClosureCompilerTest | testSourceRangeAccessForClosureLongFormBytecodeInjectInto error | ClosureCompilerTest | testSourceRangeAccessForClosureBytecodeInjectInto error | ClosureCompilerTest | testSourceRangeAccessForBlueBookLongFormInjectInto error | ClosureCompilerTest | testInjectIntoDecompiledDebugs failure | ClosureCompilerTest | testInjectIntoDecompilations failure | ClosureCompilerTest | testDebuggerTempAccess
I guess this all will turn green after an update from eliot?
On Thu, Aug 13, 2009 at 7:10 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Also, FYI, last week I fixed all the bugs in the compiler that caused failures in ClosureCompilerTest & ClosureTests. I haven't had time to attempt to integrate these but hope to soon.
failure | DebuggerUnwindBug | testUnwindDebuggerWithStep
Same for this one?
error | BlockContextTest | testTallyMethods error | BlockContextTest | testTrace error | BlockContextTest | testValueWithExitBreak error | BlockContextTest | testValueWithExitContinue error | BlockContextTest | testBlockIsBottomContext error | BlockContextTest | testCopyStack error | BlockContextTest | testFindContextSuchThat failure | BlockContextTest | testSupplySeveralAnswersToSeveralQuestions failure | BlockContextTest | testValueWithArguments failure | BlockContextTest | testSetUp failure | BlockContextTest | testSupplyAnswerThroughNestedBlocks failure | BlockContextTest | testSupplyAnswerUsingTraditionalMatchOfQuestion failure | BlockContextTest | testSupplySameAnswerToAllQuestions
Same for those?
failure | FontTest | testFallback failure | FontTest | testResetAfterEmphasized error | LocaleTest | testLocaleChanged failure | LocaleTest | testIsFontAvailable failure | MCSnapshotBrowserTest | testNoSelection failure | MethodPragmaTest | testReformat failure | MorphicToolBuilderTests | testGetButtonSideEffectFree failure | ObjectFinalizerTests | testFinalization failure | ReleaseTest | testUndeclared error | SMDependencyTest | test2 failure | TestIndenting | testNewLineStartsIndentedWhenWrapped failure | TestIndenting | testSetUp failure | TraitFileOutTest | testFileOutCategory
Any status on these?
Alex
On 30 Aug 2009, at 05:23, Alexander Lazarević wrote:
failure | FontTest | testFallback
This method apparently a width of the printed character in the failing assertion, however, on tracing the calls I could only find that the tested method, displayString:on:from:to:at:kern: always returns the point passed to it after the 'at:', so this test seems bound to fail this way. I don't know what the meaning of this test is, so I'm not sure what should be done here.
failure | FontTest | testResetAfterEmphasized
This test seems to assume the StrikeFont>>reset method empties the array, which it doesn't. Not sure if the test is wrong or the behaviour of the reset method.
failure | MCSnapshotBrowserTest | testNoSelection
Similar with this. The test assumes that when you select nothing in the Snapshot browser an empty string would be displayed, however, it displays the package scripts, or '(package defines no scripts)' if there are none, which is the case in the test. Again, not sure which side to trust here, I changed the test-case and pushed that to the inbox, though.
-- Regards, Tim
Tim Felgentreff wrote:
On 30 Aug 2009, at 05:23, Alexander Lazarević wrote:
failure | FontTest | testFallback
This method apparently a width of the printed character in the failing assertion, however, on tracing the calls I could only find that the tested method, displayString:on:from:to:at:kern: always returns the point passed to it after the 'at:', so this test seems bound to fail this way. I don't know what the meaning of this test is, so I'm not sure what should be done here.
The displayString method should return the advance width. That was broken a while ago in BitBlt (I've pointed this out on vm-dev) but for now I've added a workaround which fixes this issue (and some related, very odd issues when looking at binary stuff in the file list).
failure | FontTest | testResetAfterEmphasized
This test seems to assume the StrikeFont>>reset method empties the array, which it doesn't. Not sure if the test is wrong or the behaviour of the reset method.
The test hasn't been updated. We now also have non-synthetic derived fonts that should not be thrown away upon reset. I fixed that.
failure | MCSnapshotBrowserTest | testNoSelection
Similar with this. The test assumes that when you select nothing in the Snapshot browser an empty string would be displayed, however, it displays the package scripts, or '(package defines no scripts)' if there are none, which is the case in the test. Again, not sure which side to trust here, I changed the test-case and pushed that to the inbox, though.
Thanks for the help!
Cheers, - Andreas
On Sat, Aug 29, 2009 at 8:23 PM, Alexander Lazarević laza@blobworks.comwrote:
Hi!
Running the tests for a recent trunk image I get the following:
error | ClosureCompilerTest | testSourceRangeAccessForBlueBo okInjectInto error | ClosureCompilerTest | testSourceRangeAccessForInjectInto error | ClosureCompilerTest | testSourceRangeAccessForClosureLongFormBytecodeInjectInto error | ClosureCompilerTest | testSourceRangeAccessForClosureBytecodeInjectInto error | ClosureCompilerTest | testSourceRangeAccessForBlueBookLongFormInjectInto error | ClosureCompilerTest | testInjectIntoDecompiledDebugs failure | ClosureCompilerTest | testInjectIntoDecompilations failure | ClosureCompilerTest | testDebuggerTempAccess
I guess this all will turn green after an update from eliot?
Yes for some. Others are obsolete.
On Thu, Aug 13, 2009 at 7:10 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Also, FYI, last week I fixed all the bugs in the compiler that caused failures in ClosureCompilerTest & ClosureTests. I haven't had time to attempt to integrate these but hope to soon.
failure | DebuggerUnwindBug | testUnwindDebuggerWithStep
Same for this one?
Yes.
error | BlockContextTest | testTallyMethods error | BlockContextTest | testTrace error | BlockContextTest | testValueWithExitBreak error | BlockContextTest | testValueWithExitContinue error | BlockContextTest | testBlockIsBottomContext error | BlockContextTest | testCopyStack error | BlockContextTest | testFindContextSuchThat failure | BlockContextTest | testSupplySeveralAnswersToSeveralQuestions failure | BlockContextTest | testValueWithArguments failure | BlockContextTest | testSetUp failure | BlockContextTest | testSupplyAnswerThroughNestedBlocks failure | BlockContextTest | testSupplyAnswerUsingTraditionalMatchOfQuestion failure | BlockContextTest | testSupplySameAnswerToAllQuestions
Same for those?
No. The BlockContext tests are obsolete.
failure | FontTest | testFallback failure | FontTest | testResetAfterEmphasized error | LocaleTest | testLocaleChanged failure | LocaleTest | testIsFontAvailable failure | MCSnapshotBrowserTest | testNoSelection failure | MethodPragmaTest | testReformat failure | MorphicToolBuilderTests | testGetButtonSideEffectFree failure | ObjectFinalizerTests | testFinalization failure | ReleaseTest | testUndeclared error | SMDependencyTest | test2 failure | TestIndenting | testNewLineStartsIndentedWhenWrapped failure | TestIndenting | testSetUp failure | TraitFileOutTest | testFileOutCategory
Any status on these?
Not from me. I'll try and take a look at MethodPragmaTest>>testReformat
Alex
Thanks for your replies and adaptations guys. So I will remove all the BlockContextTests and look at least into the failure of testFinalization, which only occurs in the unattended testruns and must be induced by something I do to log the testresults.
Alex
On Mon, Aug 31, 2009 at 12:20 AM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Sat, Aug 29, 2009 at 8:23 PM, Alexander Lazarević laza@blobworks.comwrote:
Hi!
Running the tests for a recent trunk image I get the following:
error | ClosureCompilerTest | testSourceRangeAccessForBlueBo okInjectInto error | ClosureCompilerTest | testSourceRangeAccessForInjectInto error | ClosureCompilerTest | testSourceRangeAccessForClosureLongFormBytecodeInjectInto error | ClosureCompilerTest | testSourceRangeAccessForClosureBytecodeInjectInto error | ClosureCompilerTest | testSourceRangeAccessForBlueBookLongFormInjectInto error | ClosureCompilerTest | testInjectIntoDecompiledDebugs failure | ClosureCompilerTest | testInjectIntoDecompilations failure | ClosureCompilerTest | testDebuggerTempAccess
I guess this all will turn green after an update from eliot?
Yes for some. Others are obsolete.
On Thu, Aug 13, 2009 at 7:10 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Also, FYI, last week I fixed all the bugs in the compiler that caused failures in ClosureCompilerTest & ClosureTests. I haven't had time to attempt to integrate these but hope to soon.
failure | DebuggerUnwindBug | testUnwindDebuggerWithStep
Same for this one?
Yes.
error | BlockContextTest | testTallyMethods error | BlockContextTest | testTrace error | BlockContextTest | testValueWithExitBreak error | BlockContextTest | testValueWithExitContinue error | BlockContextTest | testBlockIsBottomContext error | BlockContextTest | testCopyStack error | BlockContextTest | testFindContextSuchThat failure | BlockContextTest | testSupplySeveralAnswersToSeveralQuestions failure | BlockContextTest | testValueWithArguments failure | BlockContextTest | testSetUp failure | BlockContextTest | testSupplyAnswerThroughNestedBlocks failure | BlockContextTest | testSupplyAnswerUsingTraditionalMatchOfQuestion failure | BlockContextTest | testSupplySameAnswerToAllQuestions
Same for those?
No. The BlockContext tests are obsolete.
failure | FontTest | testFallback failure | FontTest | testResetAfterEmphasized error | LocaleTest | testLocaleChanged failure | LocaleTest | testIsFontAvailable failure | MCSnapshotBrowserTest | testNoSelection failure | MethodPragmaTest | testReformat failure | MorphicToolBuilderTests | testGetButtonSideEffectFree failure | ObjectFinalizerTests | testFinalization failure | ReleaseTest | testUndeclared error | SMDependencyTest | test2 failure | TestIndenting | testNewLineStartsIndentedWhenWrapped failure | TestIndenting | testSetUp failure | TraitFileOutTest | testFileOutCategory
Any status on these?
Not from me. I'll try and take a look at MethodPragmaTest>>testReformat
Alex
On 31 Aug 2009, at 01:15, Alexander Lazarević wrote:
failure | ReleaseTest | testUndeclared
This test fails because some undeclared symbols are used, namely: FlashMorph in PasteUpMorph>>isSafeToServe LogicalFont in TextEditor>>changeTextFontDialog PlusToolSet in ScriptLoader>>unloadToolPlus FixInvisible in ScriptLoader>>updateFrom7024 Those classes do not appear in the Image, is the referencing code safe to remove? MethodNode>>generateWith:using: was missing a variable declaration, I put it in and pushed that to the inbox.
-- Regards, Tim
Tim Felgentreff wrote:
MethodNode>>generateWith:using: was missing a variable declaration, I put it in and pushed that to the inbox.
I just spoke to Eliot and he voted for nuking the method since it is not used and not even correct in its current form. I concur with his analysis. Can you resubmit the package with the method gone instead?
Thanks! - Andreas
On Mon, Aug 31, 2009 at 7:49 AM, Tim Felgentreff tim@nada1.de wrote:
This test fails because some undeclared symbols are used, namely: PlusToolSet in ScriptLoader>>unloadToolPlus FixInvisible in ScriptLoader>>updateFrom7024 Those classes do not appear in the Image, is the referencing code safe to remove?
What is the status of ScripLoader anyway. Is this replaced by ReleaseBuilder?
Alex
On 31.08.2009, at 23:56, Alexander Lazarević wrote:
On Mon, Aug 31, 2009 at 7:49 AM, Tim Felgentreff tim@nada1.de wrote: This test fails because some undeclared symbols are used, namely: PlusToolSet in ScriptLoader>>unloadToolPlus FixInvisible in ScriptLoader>>updateFrom7024 Those classes do not appear in the Image, is the referencing code safe to remove?
What is the status of ScripLoader anyway. Is this replaced by ReleaseBuilder?
By the MCM updater.
- Bert -
On 8/31/09 7:05 PM, "Bert Freudenberg" bert@freudenbergs.de wrote:
What is the status of ScripLoader anyway. Is this replaced by ReleaseBuilder?
By the MCM updater.
- Bert -
Could unload ScripLoader and ReleaseBuilder in trunk image? Both was in repositories and if any wish load later when needed. Still a reduced , safe , modular Squeak is a good thing IMHO
Edgar
Where are these repositories?
Alex
On Tue, Sep 1, 2009 at 1:22 AM, Edgar J. De Cleene < edgardec2001@yahoo.com.ar> wrote:
On 8/31/09 7:05 PM, "Bert Freudenberg" bert@freudenbergs.de wrote:
What is the status of ScripLoader anyway. Is this replaced by ReleaseBuilder?
By the MCM updater.
- Bert -
Could unload ScripLoader and ReleaseBuilder in trunk image? Both was in repositories and if any wish load later when needed. Still a reduced , safe , modular Squeak is a good thing IMHO
Edgar
On 9/1/09 5:58 AM, "Alexander Lazarević" laza@blobworks.com wrote:
Where are these repositories?
Alex
ScritptLoader have his in this http://source.squeak.org/trunk 'http://www.squeaksource.com/Pharo'
ReleaseBuilder in http://source.squeak.org/trunk
Edgar
squeak-dev@lists.squeakfoundation.org