<div dir="ltr"><div><div><div><div><div><div>The bug is that (true ifTrue:[^true] ifFalse:[^false]) won't push any value on the stack (same as emitEffect: rather than emitValue:)<br></div>The decompiler wants to find the argument of self value: ... on the stack and it's not there.<br>
<br></div>So either we should forbid such construct at compile time<br>(emit an 'un-reachable code' error when emitValue: does not emit any value)<br><br></div>Or patch Decompiler like mad to work around...<br>(but Decompiler's methods are yet well below usual quality in term of complexity - long methods, many instance variables, incredibly complex state, ...)<br>
<br></div>I agree, this is going to be a rare problem only for newbies, because an experimented Smalltalker will avoid writing unreachable code.<br></div>So, the third solution is DO NOTHING, or more exactly add a test and an expected failure.<br>
</div><div>Like that we'll say next time, hey bad luck, this is a known limitation.<br></div><div><br></div>Nicolas<br><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/20 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 20 June 2013 02:12, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
> On Thu, Jun 20, 2013 at 01:26:14AM +0200, Nicolas Cellier wrote:<br>
>> See<br>
>> <a href="http://stackoverflow.com/questions/17129583/smalltalk-collection-is-empty-error-when-saving/17202938#17202938" target="_blank">http://stackoverflow.com/questions/17129583/smalltalk-collection-is-empty-error-when-saving/17202938#17202938</a><br>
>><br>
>> This bug was found by a newbie on pharo 1.1, but it's still there in 4.5<br>
>> trunk image<br>
>><br>
>> Try to decompile this (no matter in which class)<br>
>><br>
>> < aNumberWithUnits<br>
>> (self compareUnits: aNumberWithUnits)<br>
>> ifTrue: [self value: ((aNumberWithUnits value) < (self value)<br>
>> ifTrue: [^true] ifFalse: [^false]).]<br>
>> ifFalse: [^Error new signal: 'Incompatible unit types.'].<br>
>><br>
>> Thanks to the newbie!<br>
>> I would just have hated that!<br>
>> Learning from one's own error is great, but from a dysfunctional system not<br>
>> so :(<br>
><br>
> Good bug catch! Here is a reduced version of the method that produces the<br>
> same error when decompiled:<br>
><br>
><br>
> Foo>>decompilerBug<br>
> self value: (true<br>
> ifTrue: [^ true]<br>
> ifFalse: [^ false])<br>
<br>
</div></div>I'm guessing that this is because<br>
<div class="im"><br>
true<br>
ifTrue: [^ true]<br>
ifFalse: [^ false]<br>
<br>
</div>decompiles as<br>
<br>
true ifTrue: [^ true]<br>
^ false<br>
<br>
?<br>
<br>
I'm not terribly worried about claims of a "dysfunctional system".<br>
This bug is so severe that noone has noticed it before! I agree that<br>
we need to fix the bug, but the original code makes no sense in the<br>
first place. #value: is unreachable.<br>
<br>
frank<br>
<br>
> Dave<br>
><br>
><br>
<br>
</blockquote></div><br></div>