<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 January 2014 21:53, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 12.01.2014, at 20:42, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
<br>
> On Sun, Jan 12, 2014 at 02:02:08PM -0500, Colin Putney wrote:<br>
>> On Sun, Jan 12, 2014 at 1:45 PM, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>><br>
>><br>
>>> Say you want to wrap every object in the system in a proxy.<br>
>>> You would need to use #allObjectsDo:. but when we enumerate all<br>
>>> object, the new ones too, we end up having proxies for proxies for<br>
>>> proxies ad infinitum (endless non-loop?) and we can?t know it?<br>
>>><br>
>><br>
>> Yeah, that's an example of creating objects faster than we can enumerate<br>
>> them. (Or, exactly as fast as we can enumerate them, I suppose). It<br>
>> wouldn't have worked pre-closures, either.<br>
>><br>
>> The consensus so far is that we like the safety of a sentinel object, as it<br>
>> lets us do whatever we want within the loop, and potentially not seeing all<br>
>> the objects in the image is an acceptable trade-off for that safety. Fair<br>
>> enough.<br>
>><br>
><br>
> (Changing subject line because original discussion spans commit notices)<br>
><br>
> The most recent inbox entry System-cwp.663 seems to work fine on an<br>
> interpreter VM.<br>
><br>
> For my understanding, can you clarify, with respect to the original concern<br>
> that involves MC proxies - does the problem occur with the interpreter VM<br>
> as well as Cog, or was it specific to one kind of VM?<br>
><br>
> It is worth noting that allObjectsDo: relies on assumptions about how<br>
> the objects memory works internally. It requires that #someObject will<br>
> always answer the object at the lowest address in the object memory, and<br>
> also that a newly allocated object will always be placed at a higher<br>
> address location than all other objects. Either of these assumptions is<br>
> likely to be a problem as new and better object memories and garbage<br>
> collectors are implemented.<br>
><br>
> Dave<br>
<br>
</div></div>Right (as Eliot's vm-dev post shows).<br>
<br>
So IMHO the only sensible semantics of allObjectsDo: is as in "allObjects do:" - which might be implemented as a primitive in some VMs soonish. It *should not* enumerate objects created after calling the method.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>+1<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
- Bert -<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>