Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Status of Tests in trunk

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

laza

[squeak-dev] Status of Tests in trunk

Hi!

Running the tests for a recent trunk image I get the following:

error | ClosureCompilerTest | testSourceRangeAccessForBlueBo

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?

Tim Felgentreff

Re: [squeak-dev] Status of Tests in trunk

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

Andreas.Raab

[squeak-dev] Re: Status of Tests in trunk

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

Eliot Miranda-2

Re: [squeak-dev] Status of Tests in trunk

In reply to this post by laza

On Sat, Aug 29, 2009 at 8:23 PM, Alexander Lazarević <[hidden email]> wrote:

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 <[hidden email]> wrote:

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

laza

Re: [squeak-dev] Status of Tests in trunk

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 <[hidden email]> wrote:

On Sat, Aug 29, 2009 at 8:23 PM, Alexander Lazarević <[hidden email]> wrote:
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 <[hidden email]> wrote:

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

Tim Felgentreff

Re: [squeak-dev] Status of Tests in trunk

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

Andreas.Raab

[squeak-dev] Re: Status of Tests in trunk

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

laza

Re: [squeak-dev] Status of Tests in trunk

In reply to this post by Tim Felgentreff

On Mon, Aug 31, 2009 at 7:49 AM, Tim Felgentreff <[hidden email]> 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

Bert Freudenberg

Re: [squeak-dev] Status of Tests in trunk

On 31.08.2009, at 23:56, Alexander Lazarević wrote:

> On Mon, Aug 31, 2009 at 7:49 AM, Tim Felgentreff <[hidden email]> 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 -

Edgar J. De Cleene

Re: [squeak-dev] Status of Tests in trunk

On 8/31/09 7:05 PM, "Bert Freudenberg" <[hidden email]> 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

laza

Re: [squeak-dev] Status of Tests in trunk

Where are these repositories?

Alex

On Tue, Sep 1, 2009 at 1:22 AM, Edgar J. De Cleene <[hidden email]> wrote:

On 8/31/09 7:05 PM, "Bert Freudenberg" <[hidden email]> 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

Edgar J. De Cleene

Re: [squeak-dev] Status of Tests in trunk

Re: [squeak-dev] Status of Tests in trunk

On 9/1/09 5:58 AM, "Alexander Lazarević" <[hidden email]> 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