[squeak-dev] Re: testrun results

Frank Shearar frank.shearar at angband.za.org
Mon Apr 5 20:41:05 UTC 2010


Eliot Miranda wrote:
> 
> 
> On Mon, Apr 5, 2010 at 10:37 AM, Andreas Raab <andreas.raab at gmx.de 
> <mailto:andreas.raab at gmx.de>> wrote:
> 
>     On 4/5/2010 4:04 AM, Levente Uzonyi wrote:
> 
>         It's a decompiler bug. Eliot has fixes for these issues but I
>         don't know
>         if he has time to add them to the Trunk.
> 
> 
>     I just spoke with Eliot and it seems unlikely that he'll have much
>     time to work on this. Also, there are cases that the decompiler
>     handles correctly, but differently from the compiler.
> 
>     Eliot's recommendation to extent DecompilerTests>>decompilerFailures
>     with the failing sites.
> 
> 
> Some saintly person should go through the failures and add to 
> decompilerFailures all those that fail because of known limitations in 
> the decompiler.  These limitations are things like
> 
> Floating point reader precision, e.g. the source specifies more 
> precision than is supported and so the compilation of the decompilation 
> is slightly different.
> 
> Unreachable statements. e.g. foo ifTrue: [^bar] ifFalse: [^baz]. ^huh? 
> decompiles as foo ifTrue: [^bar] ifFalse: [^baz]. and so ^'huh?' is missing.
> 
> Null statements.  e.g. foo ifTrue: []. decompiles as foo.  which, if foo 
> is an inst var, compiles as empty.
> 
> These are limitations in the decompiler we simply have to tolerate. 
>  decompilerFailures is a list that documents the reasons for failure.
> 
> Of course another, also valid, approach is to fix the code in the 
> failures so that they don't contain unreachable or null statements.

Done, in the form of Tests-fbs.68.mcz. The errors that I looked into (as 
detailed in a previous mail) were mostly harmless: variables looked to 
be named in a slightly different order. Because we check the old code 
string against the new code string we get a false negative: a test that 
fails but the behaviour's correct.

At worst, I hope my work at least narrows down the field of inquiry for 
someone else.

frank



More information about the Squeak-dev mailing list