[squeak-dev] [BUG] Cannot compile cascade sent to block

Levente Uzonyi leves at caesar.elte.hu
Sat Dec 28 16:48:12 UTC 2019


On Sat, 28 Dec 2019, Nicolas Cellier wrote:

> Hi Christoph,
> it's possible that I've already fixed that a few years ago, but it was not considered useful enough.
> Is this really a problem?

This time it's a different problem. The second special selector 
(#whileFalse in this case) leaves the BlockNode with nil blockExtent, 
which causes various issues depending on how you try to compile the code.

IIRC, what you fixed was the case:

true
 	ifTrue: [ 1 ];
 	ifFalse: [ 2 ].


Levente

> 
> Le sam. 28 déc. 2019 à 15:53, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> a écrit :
>
>       Hi all! :-)
> 
>
>       Steps to reproduce:
>
>       Do it:
>
>             [true]
> whileTrue;
> whileFalse
> 
> 
> Expected behavior:
> The script is compiled and executed (and an infinite loop occurs).
> 
> Actual behavior:
> [IMAGE]
> 
> Further investigations:
> In #analyseTempsWithin:rootNode:assignmentPools:, the inner BlockNode [true] is not computed a blockExtent, because it is optimized.
> This leads to a nil key in the ByteCodeEncoder's blockExtentsToLocals.
> A fast solution would be to skip nil blockExtents in #noteBlockExtent:hasLocals:, but that's a dirty workaround.
> 
> Similar bug:
> Try to do:
>       Object newSubclass compile:  'iWontCompile: foo
> foo.
> [true]
> whileTrue;
> whileFalse'
> 
> Fails with:
> [IMAGE]
> Again, the problem is that blockExtent isNil.
> 
> Workaround:
> Send #yourself to the block before sending the cascade. This prevents the receiver from being optimized.
> 
> Please note that this problem does not only occur in case of special blocks. For example, [Sensor anyButtonPressed] whileTrue; whileFalse fails as well.
> 
> 
> How to fix this appropriately? I'm not sure whether I understand the whole idea of blockExtent so far. According to the documentation comment, it should be okay to be nil; however, the #blockExtent comment does not
> mention this fact.
> Please see the attached changeset for an approach to fix the issue. All tests from KernelTests-Methods and most tests from Test-Compiler pass it, except of the testAllNodePCs* which time out in my fresh image. It would
> be great to hear if this is the right way to solve the bug, or just extending a workaround :-)
> 
> Best,
> Christoph
> 
> 
>


More information about the Squeak-dev mailing list