<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><div><br></div><div>It is internal in the Cog VMs. And before you condemn that choice it /is/ slightly more efficient as it doesn't have to indirect to access the interpreterProxy API. But in any case new Cog VMs are already available.</div>
<div><br></div><div><br></div></div>
</div></div>
</blockquote>I know - your more direct macro access is a good idea. But that wasnt the point I intended; unless we've broken the plugin mechanism over the years a fixed-up zip plugin will over-ride the broken internal code, offering a very easy fix. It should even work in a running system where you don't want to quit and restart with a new vm for whatever reason. Something like <div>Smalltalk unloadModule: 'ziplthingy'</div><div>Should disconnect from the old version and the next call to anything in the plugin ought to load the new external copy. Obviously this could be complicated by any stored state, so caveat emptor.</div><div><br></div><div>It's a really neat trick when developing a plugin.</div></body></html>