[squeak-dev] DecompilationTests failures [was: About DecompilerTests >> decompilerDiscrepancies]

Eliot Miranda eliot.miranda at gmail.com
Wed Jan 20 18:12:14 UTC 2010


On Wed, Jan 20, 2010 at 12:41 AM, Michael Roberts <mike at mjr104.co.uk> wrote:

> IIRC this suite is fairly specialised as part of eliot's closure work.
> I think we disabled it from running because we did not have time to
> fix it. I don't have an image at the moment but it would be better to
> leave it alone if you can until someone can study the decompiler in
> depth. Unless Eliot can comment?
>

Actually I suspect decompilerDiscrepancies is equivalent to my 3.8-derived
image's DecompilerTests>>decompilerFailures which exists to list methods
that will cause decompilation tests to fail and predates my work with
closures.  My version reads

decompilerFailures
"here is the list of failures: DNU resulting in trying to decompile the
following methods"

^ #((BalloonEngineSimulation circleCosTable "-0.3826834323650903 =>
-0.38268343236509 or -0.3826834323650902")
 (BalloonEngineSimulation circleSinTable "-0.3826834323650903 =>
-0.38268343236509 or -0.3826834323650902")
 (GeniePlugin
primSameClassAbsoluteStrokeDistanceMyPoints:otherPoints:myVectors:otherVectors:mySquaredLengths:otherSquaredLengths:myAngles:otherAngles:maxSizeAndReferenceFlag:rowBase:rowInsertRemove:rowInsertRemoveCount:
"Cannot compile -- stack including temps is too deep")
(QPickable2D pick:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"
(QUsersPane userEntryCompare:to:) "foo ifTrue: [^bar] ifFalse: [^baz].
^huh?"
(TShaderProgram vertexStrings) "foo ifTrue: []. => foo. => ."
(TShaderProgram fragmentStrings) "foo ifTrue: []. => foo. => ."
(TWindow zoomWindow:) "foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?"

"(PNMReadWriter nextImage) (Collection #ifEmpty:ifNotEmpty:) (Collection
#ifEmpty:) (Collection #ifNotEmpty:ifEmpty:) (Text #alignmentAt:ifAbsent:)
(ObjectWithDocumentation propertyAt:ifAbsent:)")


They all list methods whose compilation of their decompilation won't match
what one started with either because of limitations in the decompiler or
optimizations in the compiler.  For example if one writes
    foo ifTrue: [].
the compiler will emit that as foo, eliminating the branch around the empty
block.  So when that is decompiled it'll decompile as
    foo.
and the compiler will then compile that as empty.  So ...

When you decompile the source code of the method containing foo ifTrue: []
it contains a parse node that prints as
    foo ifTrue: [].
But the bytecode contains only the code for
    foo.
so when you decompile that you get
    foo.
and when you compile that you get no bytecode generated for foo.

Other examples include cases where to:by:do: is decompiled as whileTrue:,
where the precision of a written float exceeds the representation of
underlying float objects, and so on.

I don't see the point of fixing these things in either the compiler or the
decompiler.  They're legal Smalltalk, the optimizations the compiler
performs is perfectly reasonable, and there seems no point in e.g.
annotating the bytecode with information on the optimization so that the
decompilation would be correct.  Hence I think we have to live with the
work-around which is filtering-out expected failures.  Implementing the
filter as a list is poor; better would be to have rules that match expected
failures, but that's potentially a lot of tricky work for not much benefit.
What would help is a) a simple tool to look at the discrepancies
side-by-side (I have a workspace I can send you), and b) people who run the
tests updating the filer-list with exceptions and documenting what causes
each exception.

HTH
Eliot



> Cheers mike
>
> On Tuesday, January 19, 2010, Mariano Martinez Peck
> <marianopeck at gmail.com> wrote:
> > Hi folks: does someone know what is this method for ?
> >
> > In my case, it has included the message saveImageSegments   which I
> rename it to saveImageSegments:
> >
> > So...what should I do ? I put saveImageSegments:  instead of
> saveImageSegments  or I just remove it from there?
> >
> > Thanks
> >
> > Mariano
> >
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100120/02ece73f/attachment.htm


More information about the Squeak-dev mailing list