On Mon, 5 Apr 2010, Frank Shearar wrote:

> Many tests below fail for the same reason. As such I've categorised them as 
> [1], [2], etc. and given a description of the failure under the table.
>
> laza at blobworks.com wrote:
>> All Tests that failed or have errors:
>>
>>           class           |            selector            | result 
>> --------------------------+--------------------------------+---------
> <snip>
>>  DecompilerTests          | testDecompilerInClassesAAtoAM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesBAtoBM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesCAtoCM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesCNtoCZ  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesDAtoDM  | failure [2]
>>  DecompilerTests          | testDecompilerInClassesENtoEZ  | error    [3]
>>  DecompilerTests          | testDecompilerInClassesFAtoFM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesFNtoFZ  | failure [4]
>>  DecompilerTests          | testDecompilerInClassesGNtoGZ  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesHNtoHZ  | failure [5]
>>  DecompilerTests          | testDecompilerInClassesINtoIZ  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesJNtoJZ  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesLNtoLZ  | failure [4]
>>  DecompilerTests          | testDecompilerInClassesMAtoMM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesMNtoMZ  | failure [6]
>>  DecompilerTests          | testDecompilerInClassesNAtoNM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesOAtoOM  | failure [4]
>>  DecompilerTests          | testDecompilerInClassesPAtoPM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesPNtoPZ  | failure [5]
>>  DecompilerTests          | testDecompilerInClassesRAtoRM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesSAtoSM  | error   [3]
>>  DecompilerTests          | testDecompilerInClassesSNtoSZ  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesTAtoTM  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesTNtoTZ  | failure [1]
>>  DecompilerTests          | testDecompilerInClassesWAtoWM  | failure [4]
> <snip>
>
> [1] tests fail because variables are being "named" (I don't know the correct 
> terminology) in a different order. For instance:
>
> old AA->AM
> 'at: t1 ifAbsentPut: t2
> 	| t4 |
> 	1
> 		to: self basicSize
> 		do: [:t3 | (t4 := self basicAt: t3) key == t1
> 				ifTrue: [^ t4 isVariableBinding
> 						ifTrue: [t4 value]
> 						ifFalse: [t4]]].
> 	^ method propertyValueAt: t1 put: t2 value'
>
> new AA->AM
> 'at: t1 ifAbsentPut: t2
> 	| t3 |
> 	1
> 		to: self basicSize
> 		do: [:t4 | (t3 := self basicAt: t4) key == t1
> 				ifTrue: [^ t3 isVariableBinding
> 						ifTrue: [t3 value]
> 						ifFalse: [t3]]].
> 	^ method propertyValueAt: t1 put: t2 value'
>
> The block temps get named before the local variables, or a block temp skips a 
> number: GNtoGZ's oldCodeString uses "t7" as a block temp name, while 
> newCodeString uses "t8".
>
> [2] fails because the Symbols are now being output as #Foo not Foo inside 
> literal ByteArrays.
>
> [3] has a Syntax Error in, for example, EventSensor>>eventTickler - "Period 
> or right bracket expected ->_r2 := Time millisecondClockValue - 
> lastEventPoll." Maybe it's that underscore?

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.


Levente

>
> [4] fails in a similar way to [1] tests, but here the old code string has, 
> for instance, "t4" and the new code string has "t3". A temp name's skipped in 
> the oldCodeString.
>
> [5] oldCodeString for HttpUrl>>checkAuthorization:retry:, 
> PNGReadWriter>>copyPixelsGray: returns nil while newCodeString returns (by 
> not having a return) self.
>
> [6] is also a naming issue. The oldCodeString for MVCProject>>textWindow 
> shows two differently named block temps (t9, t10) for the two #detect:ifNone: 
> calls, while the newCodeString shows the two block temps with the same name 
> (t10).
>
> frank
>
>