On Wed, Jan 20, 2010 at 12:41 AM, Michael Roberts <mike@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project