Hi David,
On Tue, May 18, 2010 at 4:33 PM, David T. Lewis lewis@mail.msen.com wrote:
On Tue, May 18, 2010 at 02:17:40PM -0700, Eliot Miranda wrote:
Hi Hans-Martin,
On Tue, May 18, 2010 at 12:15 PM, Hans-Martin Mosner hmm@heeg.de
wrote:
Hello, while looking at the decompiled code of some OMeta methods I noticed that the temp name handling in the decompiler seems to be broken. When you compile a method with temps that are referenced from blocks, the decompiler tends to rearrange the temp names, so this method
test | one two | two := 2. ^{[one := 1]. [ [one + two] value]}
gets decompiled to this:
test | one two | one := 2. ^ {[two := 1]. [[two + one] value]}
OK, the issue in Squeak 4.1 is that the CodeHolder>>decompiledSourceIntoContents method is out of date. Find attached.
I tried the Decompiler.1.cs patch in Squeak trunk, and it produces some undesirable side effects. Here is what I did:
- saved a copy of changes file
- created a new method in a browser
- save and exit
- copy saved changes file back to changes file (to eliminate the source for
new method)
- restart image
- decompiled code in browser shows bug reported by Hans-Martin Mosner
- loaded Decompiler.1.cs
- decompiled code in browser produces a "Note:" dialog, and the following
(garbage) in the codeholder window:
"ueak/Squeak3.10-dev/squeak.10.image"
that's a different issue caused by your effectively truncating the changes file. What you've done is arrange that the method's source pointer points into the SNAPSHOT marker in the original changes file. What you need to do is select decompile from the source button dropdown menu in the browser, not switch the changes file underneath the method and expect the system to automatically figure out that the source is corrupt and it should decompile.
cheers Eliot
Dave