<br><br><div class="gmail_quote">On Thu, May 7, 2009 at 8:44 AM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5"><br>
<br>
On 07.05.2009, at 17:38, Andreas Raab wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Igor Stasenko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It makes absolutely no sense to say &quot;oh, we&#39;ll all just look it up and then<br>
somehow it&#39;s going to magically work&quot;. Version information is *critical* if<br>
you want to play things together in the long term - it has allowed us to<br>
have a very smooth ride for a very long time in this area and I wish Squeak<br>
would have more of that in general.<br>
<br>
</blockquote>
Taking a function pointer by name, is nothing more than enumerating<br>
the VM capabilities.<br>
Take a look at OpenGL extension mechanism. Do they have to change the<br>
version of OpenGL each time they want to add new functionality? No.<br>
You can simply ask the library about support of certain capability -<br>
and depending on answer decide what to do.<br>
</blockquote>
<br>
Yes, OpenGL is a great example. Because what the OpenGL consortium does is moving extensions into core functionality, increasing the version number of OpenGL so that clients know they can rely on a documented and stable API. Exactly my point.<br>

<br>
I have no problems with a named lookup mechanism in addition to a core interface. In fact we have one, it&#39;s ioLoadFunctionFrom. It solves a useful problem, namely that of how to support entry points where you don&#39;t know whether they will be available in the future or if it&#39;s only for use in this one version. But it&#39;s not a replacement for a documented core API.<br>

</blockquote>
<br>
<br></div></div>
+1<br>
<br>
But back to the original question - do we want to change the plugin API for 4.0 VMs?</blockquote><div><br></div><div>Yes.  I propose the following changes:</div><div><br></div><div>- change the interface to the API to one based on function pointers, not interpreterProxy.  The function pointers are initialized in a plugin&#39;s setInterpreter: which does the traditional compatibility check and then fetches the function pointers from the argument (exactly how we can discuss further).</div>
<div><br></div><div>- remove stack access from the API, writing them as SmartSyntaxPlugins where arguments are passed in as parameters, returning the result on success and 0 (not SmallInteger 0) on failure</div><div><br></div>
<div>- eliminate pushRemappableOop/popRemappableOop and make the allocation interface one that can fail, so when memory runs out a primitive will return an out-of-memory error code</div><div><br></div><div>- use primitive error codes where appropriate.  e.g. in a plugin</div>
<div>    ^self primitiveFailFor: PrimErrNoMem</div><div>is equivalent to</div><div>    primErrorCode = 0 ifTrue: [primErrCode := PrimErrNoMem].</div><div>    ^nil</div><div><br></div><div>- provide isImmediateObject: and use it in place of isIntegerObject: when the objective is to select heap objects.  Use isCharacterObject: when the objective is to select a character. I intend to add immediate characters within the next few months.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><font color="#888888">
<br>
- Bert -<br>
<br>
<br>
</font></blockquote></div><br>