<br><br><div class="gmail_quote">On Mon, Apr 5, 2010 at 12:04 PM, Levente Uzonyi <span dir="ltr">&lt;<a href="mailto:leves@elte.hu">leves@elte.hu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Mon, 5 Apr 2010, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Apr 5, 2010 at 10:37 AM, Andreas Raab &lt;<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4/5/2010 4:04 AM, Levente Uzonyi wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It&#39;s a decompiler bug. Eliot has fixes for these issues but I don&#39;t know<br>
if he has time to add them to the Trunk.<br>
<br>
</blockquote>
<br>
I just spoke with Eliot and it seems unlikely that he&#39;ll have much time to<br>
work on this. Also, there are cases that the decompiler handles correctly,<br>
but differently from the compiler.<br>
<br>
Eliot&#39;s recommendation to extent DecompilerTests&gt;&gt;decompilerFailures with<br>
the failing sites.<br>
<br>
</blockquote>
<br>
Some saintly person should go through the failures and add to<br>
decompilerFailures all those that fail because of known limitations in the<br>
decompiler.  These limitations are things like<br>
<br>
Floating point reader precision, e.g. the source specifies more precision<br>
than is supported and so the compilation of the decompilation is slightly<br>
different.<br>
<br>
Unreachable statements. e.g. foo ifTrue: [^bar] ifFalse: [^baz]. ^huh?<br>
decompiles as foo ifTrue: [^bar] ifFalse: [^baz]. and so ^&#39;huh?&#39; is missing.<br>
<br>
Null statements.  e.g. foo ifTrue: []. decompiles as foo.  which, if foo is<br>
an inst var, compiles as empty.<br>
<br>
These are limitations in the decompiler we simply have to tolerate.<br>
decompilerFailures is a list that documents the reasons for failure.<br>
<br>
Of course another, also valid, approach is to fix the code in the failures<br>
so that they don&#39;t contain unreachable or null statements.<br>
</blockquote>
<br></div></div>
What about the &quot;real&quot; bugs when the decompiler cannot reproduce the declaration of temporiaries (for example EventSensor &gt;&gt; #eventTickler)?<br></blockquote><div><br></div><div>There are two tasks here.  One is to collect the set of genuine decompiler failures.  The other is to compare the current trunk code with my Teleplace decompiler state and do a merge, hopefully eliminating some of the genuine failures.  Unfortunately I don&#39;t have any space cycles right now.  So if you&#39;re interested I can supply the Teleplace decompiler code to anyone that wants to take a look.</div>
<div><br></div><div>best</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Levente<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
HTH<br>
Eliot<br>
<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
 - Andreas<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote></div><br>