<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Christoph,<br><div><br></div><div> apologies for the late reply. Busy weekend trying to get the Vm to run if compiled with MSVC. Still not out of the woods...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2020 at 9:10 AM Christoph Thiede <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de">christoph.thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Eliot,<br>
<br>
> Quite right. Can you find out how common cases like these are? I bet you<br>
> there will be five methods or less in trunk that are affected.<br>
<br>
I did a full search in my image:<br>
<br>
pattern := '.*to\:[\s\r\n]*\w+[\s\r\n]*do\:[\s\r\n]*\[[^\]]*\[.*' asRegex.<br>
self systemNavigation allMethods select: [:m |<br>
pattern matches: m getSource].<br></blockquote><div><br></div><div>Well, that's not what I meant by a search. However, as Levente pointed out, textual searches should be surrounded with CurrentReadOlySouceFiles cacheDuring:. I think this is an awful implementation and would implement it very differently but that's the work-around we have in place now,</div><div><br></div><div>What I meant my a search was to look at MesasageNode>>transform: which is sent in MessageNode>>receiver:selector:arguments:precedence:from:. This means it is ideal. First of all it is bottom up; the to:[by:]do: message node is only created and transformed once all its sub components have been parsed. So one is in a position in MessageNode>>transformToDo: to search the parse tree of the last block argument looking for accesses in non-optimized blocks (*) to its argument. (*) remember its *any* reference in an unoptimized block, no mater how deeply nested. So a reference to the block argument within an optimized block that is within an unoptimized block is till a reference. e.g.</div><div><br></div><div> 1 to: 5 do:</div><div> [:arg|</div><div> arg even</div><div> ifTrue: [evens add: [arg]]</div><div> ifFalse: [odds add: [arg]]</div><div><br></div><div>are still references even though they're both in optimized blocks. That's not a good example. I should say something like</div><div><br></div><div><div style="color:rgb(0,0,0)"> 1 to: 5 do:</div><div style="color:rgb(0,0,0)"> [:arg|</div><div style="color:rgb(0,0,0)"> them add: [arg even</div><div style="color:rgb(0,0,0)"> ifTrue: [arg]</div><div style="color:rgb(0,0,0)"> ifFalse: [arg+arg]]]</div></div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">whereas here it doesn't matter:</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)"><div> 1 to: 5 do:</div><div> [:arg|</div><div> them add: (arg even</div><div> ifTrue: [arg]</div><div> ifFalse: [arg+arg])]</div><div><br></div></div><div style="color:rgb(0,0,0)">you get the idea. So the search is tricky. Basically as the tree is descended we need to either set a flag that says the search is now in an unoptimized block, or the search needs to look up towards the root block arg to to:[by:]do: to find an intervening unoptimized block.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">My Source Files are very slow,<br>
<<a href="http://forum.world.st/The-Inbox-ShoutCore-ct-78-mcz-tp5109909p5110050.html" rel="noreferrer" target="_blank">http://forum.world.st/The-Inbox-ShoutCore-ct-78-mcz-tp5109909p5110050.html</a>> <br>
so I interrupted the script after one hour, but I still found more than 250<br>
matches. I took some samples and they looked indeed relevant. Nested #to:do:<br>
loops, for example ...<br>
Or do I misunderstand your idea of a rule?<br></blockquote><div><br></div><div>Yes. It has to be something in the parse tree hiersecy, actually in transformToDo:. And its th cost of applying this rule during compilation that is one3 thing to be concerned about.</div><div><br></div><div>Now, in orde4r to accelerate a search for candidates remember that Nicolas wonderfully changed the compiler to add as literals the selectors of even optimized message sends. So for example all uses of #to:[by:]do: have the selectors in their literal frame. So to find out all the methods that you want to analyze further simply start from</div><div><br></div><div>((self systemNavigation allCallsOn: #to:do:), </div><div>(self systemNavigation allCallsOn: #to:by:do:)) asSet asArray sorted</div><div><br></div><div>BTW in my VMMaker image </div><div> ((self systemNavigation allCallsOn: #to:do:), <br></div><div> (self systemNavigation allCallsOn: #to:by:do:)) asSet asArray sorted size 2628</div><div><br></div><div>So you could enumerate over these, grab the parse trees, and then search the parse trees to try and find how many methods are affected and to get a rush idea of how expensive the search is.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">However, if we can agree on leaving it as it is, it's irrelevant ;-)<br>
<br>
Best,<br>
Christoph<br>
--<br>
Sent from: <a href="http://forum.world.st/Squeak-Dev-f45488.html" rel="noreferrer" target="_blank">http://forum.world.st/Squeak-Dev-f45488.html</a><br>
</blockquote></div><div><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></div></div></div>