[squeak-dev] [Please Review] Refactoring for #literalsDo: etc.
Marcel Taeumel
marcel.taeumel at hpi.de
Mon Jun 24 12:32:46 UTC 2019
Hi all,
next round. Please find attached a changeset:
- senders browsing is only slightly slower but *thorough* all the time
- #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:.
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 [mailto: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 [mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190624/6b7a0fa7/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: literals-do.7.cs
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190624/6b7a0fa7/attachment.ksh>
More information about the Squeak-dev
mailing list
|