[squeak-dev] [Please Review] Refactoring for #literalsDo: etc.

Eliot Miranda eliot.miranda at gmail.com
Wed Jun 26 22:41:42 UTC 2019


Hi Marcel,

On Mon, Jun 24, 2019 at 5:32 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi all,
>
> next round. Please find attached a changeset:
>

thanks.  Sorry to be late to this party.


>
> - senders browsing is only slightly slower but *thorough* all the time
>

I think that's safe.  Thorough might be retained as a way of not descending
into Array literals and Pragmas.  But if you're happy that we always
traverse these (and avoid being caught by recursion in circular strucutres0
THEN FINE.


> - #hasLiteral: now also works for #>= and other special literals, even
> though not enumerable
> - #literalsDo: enumerates the *raw* literals (for copy etc.) in that byte
> array (i.e. after header, before first byte code)
> - #allLiteralsDo: enumerates the *real* literals, that is, it is thorough
> but skips special objects such as outer scope, method selector, and class
> binding -- (for #hasLiteral:, tools etc.)
>
> I just thought about writing some tests for it but those would have to
> account for V3 vs. SistaV1. Hmmm... maybe just tests for #hasLiteral: and
> #allLiteralsDo:. Not that low-level #literalsDo:.
>

Alas yes.  ut there are some prototype tests you can use.
See LiteralRefLocatorTest.  These tests compile two versions of each tested
method, in the primary and secondary bytecode sets.  So if you start there
you'll find that testing both V3PlusClosures and SistaV1 is taken care of.



>
> Best,
> Marcel
>
> Am 24.06.2019 11:27:31 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Nicolas,
>
> thanks. :-) That's correct. It's an extension to high-level test and
> enumeration. I just discovered that I have to integrate (or update)
> CompiledCode >> #refersTo:bytecodeScanner:thorough: to respect those
> special selectors.
>
> Best,
> Marcel
>
> Am 24.06.2019 10:56:21 schrieb Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
> Hi Marcel,
> beware, there are specialSelectors and inlined selectors too (do: ifTrue:
> etc...), so it might happen that low level literals enumeration does not
> fit higher level...
>
> Le lun. 24 juin 2019 à 10:48, Marcel Taeumel <marcel.taeumel at hpi.de> a
> écrit :
>
>> Hi, there.
>>
>> Please find attached a new version of this refactoring.
>>
>> I discovered more recent code for scanning literals (that seems to be at
>> the *bytecode* level, not *object* level):
>>
>> BytecodeEncoder class >> #scanBlockOrNilForLiteral:
>> EncoderForSistaV1 class >> #scanBlockOrNilForLiteral:
>> EncoderForV3 class >> #scanBlockOrNilForLiteral:
>>
>> However, I could not see a way to *enumerate* literals this way. Did I
>> miss something? Makes me wonder about the entire use of CompiledCode >>
>> #literalsDo:. We could replace #hasLiteral: with an implementation similar
>> to Behavior >> #whichSelectorsreferTo:thorough: using
>> #scanBlockOrNilForLiteral:.
>>
>>
>> Thoughts? Eliot? :-) How is the conceptional relationship between "has
>> literal" and "literals do"?
>>
>> Best,
>> Marcel
>>
>> Am 28.05.2019 14:49:59 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>> Hi, there.
>>
>> Please find attached a change set that (tries to) clean up everything
>> related to enumerating or testing literals in CompiledCode, CompiledMethod,
>> and CompiledBlock.
>>
>> I have three important questions:
>>
>> - The purpose of #hasLiteralThorough is not needed anymore because we
>> enumerate and test always in a "thorough" way?
>> - Are the enumeration boundaries in CompiledCode, CompiledMethod,
>> CompiledBlock in #literalsDo: correct?
>> - What is a literal as expected in #hasLiteral: etc. to answer true? Just
>> symbols or also bindings (symbol-to-class) and classes themselves?
>>
>> Try exploring this result: "(Morph >> #fullDrawOn:) literals" or similar.
>>
>>
>> Best,
>> Marcel
>>
>>
>>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190626/b45629ef/attachment.html>


More information about the Squeak-dev mailing list