[squeak-dev] Decompilation problem

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Thu May 3 04:39:14 UTC 2012


At Thu, 12 Apr 2012 18:08:01 -0700,
Eliot Miranda wrote:
> 
>         So has OMeta patched some old bug in the decompiler which is now obsoleted by some other fix?
> 
>     The difference appears to be that the OMeta compiler answers '(t)[(t)[(t)]]' for the schematicTempNamesString. The regular compiler answers 't'. This trips the Decompiler over.
> 
> Bingo.  OMeta looks to be computing the schematic temps for the method before inlining and closure analysis, in that the ifTrue: argument is an actual block according to that string.  Good
> catch!

I understand what you mean, but I still cannot see how this can
happen.  What I do is to load OMeta2 from
http://www.squeaksource.com/OMeta.html, go to a method like
OMeta2Examples>>fact in the broser and and press the "decomple"
button.  (The actual schematicTempNamesString is different and you get
different symptom, but it seems to be stemming from the same problem.)

In the current implementation it comes down to something like:

(Parser new parse:  'fact
	| m n |
	^ self ometaOr: {[true
			ifTrue: [true
					ifTrue: [self apply: #exactly withArgs: {0}].
				self ometaOr: {[true
						ifTrue: [1]]}]]. [true
			ifTrue: [true
					ifTrue: [n := self apply: #anything].
				self ometaOr: {[true
						ifTrue: [m := self apply: #fact withArgs: {n - 1}.
							n * m]]}]]}' readStream class: Object noPattern: false context: nil notifying: nil ifFail: []) generate: CompiledMethodTrailer defaultMethodTrailer;
										schematicTempNamesString.

and I get "'(m n)[[]][(m n)[(m n)]]'" as its results.  Is there a call
to make other than parse:class:noPattern:context:notifying:ifFail:?

-- Yoshiki


More information about the Squeak-dev mailing list