[squeak-dev] Question about inlining | How to access named temps in FullBlockClosure?

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Mon Mar 30 13:21:12 UTC 2020


Hi Nicolas,


> CurrentReadOnlySourceFiles cacheDuring: [ ... ]


thanks, but this still kept my image busy for more than ten minutes!


> The problem is not so when evaluating nested block.

> It's when returning a nested block for later evaluation.

I know, but unless the nested block is unlined, you cannot tell whether any message that is sent to it, such as #cull:, will store it for later?
The compiler cannot know that #cull: does not look like this, for example:

cull: anObject
    Project current addDeferredUIMessage: [self value].
    ^ self value: anObject

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: Montag, 30. März 2020 12:54:20
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Question about inlining | How to access named temps in FullBlockClosure?

Hi Christoph,

Le ven. 27 mars 2020 à 17:10, Christoph Thiede <christoph.thiede at student.hpi.uni-potsdam.de<mailto:christoph.thiede at student.hpi.uni-potsdam.de>> a écrit :
Hi Eliot,

> Quite right.  Can you find out how common cases like these are?  I bet you
> there will be five methods or less in trunk that are affected.

I did a full search in my image:

pattern := '.*to\:[\s\r\n]*\w+[\s\r\n]*do\:[\s\r\n]*\[[^\]]*\[.*' asRegex.
self systemNavigation allMethods select: [:m |
        pattern matches: m getSource].

My Source Files are very slow,

You might want to use:

    CurrentReadOnlySourceFiles cacheDuring: [ ... ]


<http://forum.world.st/The-Inbox-ShoutCore-ct-78-mcz-tp5109909p5110050.html>
so I interrupted the script after one hour, but I still found more than 250
matches. I took some samples and they looked indeed relevant. Nested #to:do:
loops, for example ...
Or do I misunderstand your idea of a rule?

The problem is not so when evaluating nested block.
It's when returning a nested block for later evaluation.

However, if we can agree on leaving it as it is, it's irrelevant ;-)

Best,
Christoph



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200330/6777eb6e/attachment.html>


More information about the Squeak-dev mailing list