Hi Nicolas,


> Is this really a problem?

>From my point of view, this is clearly a bug. Otherwise, it would be an unnecessary restriction. Personally, it hurts my pride of the wonderful Smalltalk implementation a bit that such an edge case does not work properly ;)

Why shouldn't we fix a bug? Or why would you not consider it a bug? We already check blockExtent for nil at some other places. And the changeset is really small.

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
Gesendet: Samstag, 28. Dezember 2019 16:41:40
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [BUG] Cannot compile cascade sent to block

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?

Le sam. 28 déc. 2019 à 15:53, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto: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:
[cid:16f4d2a6581f456b1e51]

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:
[cid:16f4d2a6581f456b1e52]
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191228/75758039/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 43032 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191228/75758039/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 38107 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191228/75758039/attachment-0003.png>