<br><br><div class="gmail_quote">On Sun, May 23, 2010 at 3:40 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de">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="im">On 23.05.2010, at 23:24, Eliot Miranda wrote:<br>
> Hi Michael, Michael, Dennis, Hi All,<br>
><br>
> I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on.<br>
><br>
> The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive.<br>
<br>
</div>That's been bugging me for some time. Yay!<br></blockquote><div><br></div><div>What I admire more and more and more is Alan and co's overall system design with a minimal VM and most of the smarts in the image and Dan's VM design (e.g. primitives either succeeding or failing with no effect, and hence a really clean separation between image and primitive). One of the results is, as in this case, core system bugs being fixable with a simple patch that can be applied instantaneously. I can't imagine the kind of pain deploying this kind of fix would be in e.g. Java.</div>
<div><br></div><div>best</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
- Bert -<br>
<br>
<br>
<br>
</font></blockquote></div><br>