<div dir="ltr">David,<div><br></div><div>    when you make this change (if you haven&#39;t already) you might also integrate the Cog-style plugin glue, e.g. instead of using interpreterProxy-&gt;foo the generator always uses foo and either links directly to foo or keeps it&#39;s own local function pointer to foo which is initialized in setInterpreter:.  It&#39;s faster for internal plugins and a little faster for external plugins.  ANSI C removed the need for a syntactic difference between a direct function call and a call through a function pointer hence...</div>
<div><br></div><div>towards the start of the file you see e.g.</div><div><br></div><div><div>#if !defined(SQUEAK_BUILTIN_PLUGIN)</div><div>static sqInt (*byteSizeOf)(sqInt oop);</div></div><div>...</div><div><div>static sqInt (*storeIntegerofObjectwithValue)(sqInt index, sqInt oop, sqInt integer);</div>
<div>#else /* !defined(SQUEAK_BUILTIN_PLUGIN) */</div><div>extern sqInt byteSizeOf(sqInt oop);</div></div><div>...</div><div><div>extern sqInt storeIntegerofObjectwithValue(sqInt index, sqInt oop, sqInt integer);</div><div>
<br></div><div>extern</div><div>#endif</div><div>struct VirtualMachine* interpreterProxy;</div></div><div>...</div><div><br></div><div>in the middle you see</div><div>        destBitsSize = byteSizeOf(destBits);<br></div>
<div><br></div><div>and in setInterpreter: you see</div><div><br></div><div><div>#if !defined(SQUEAK_BUILTIN_PLUGIN)</div><div>        byteSizeOf = interpreterProxy-&gt;byteSizeOf;</div></div><div>        ...<br></div><div>
<div>        storeIntegerofObjectwithValue = interpreterProxy-&gt;storeIntegerofObjectwithValue;</div><div>#endif /* !defined(SQUEAK_BUILTIN_PLUGIN) */</div></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Apr 9, 2013 at 8:41 PM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Tue, Apr 09, 2013 at 03:25:52PM -0700, tim Rowledge wrote:<br>
&gt;<br>
&gt; I&#39;m making a start at building the RISC OS StackVM and running into some fun problems.<br>
&gt;<br>
&gt; First one was the code in VMMaker class&gt;generateConfiguration that builds directory names by means of evil URI related methods. Strange and ugly results occur for RISC OS and tracing the code reveals many strange and ugly things happening for every platform - it&#39;s just that on an OS where something like / is  acceptable as a root directory it sort of ends up ok. RISC OS does not do that and I&#39;m a little surprised that it doesn&#39;t cause problems on Windows too. My perfectly nice SDFS:RISCOSPi.$ root gets mangled to something like /SDFS%3ARISCOSPi%2F%2a/ or whatever. A simple fix for that is to change to &quot;(FileDirectory default directoryNamed:&#39;foo/bar&#39;) fullName&quot;<br>

&gt;<br>
<br>
On a related (?) note, I would like to ask if the RISC OS build could be<br>
changed to allow all plugins (whether internal or external) to be generated<br>
to a single source directory, i.e.<br>
<br>
  src/plugins/FilePlugin/<br>
  src/plugins/OSProcessPlugin/<br>
<br>
Instead of:<br>
<br>
  src/vm/intplugins/FilePlugin/<br>
  src/plugins/OSProcessPlugin/<br>
<br>
I think that we have had agreement from Eliot and Andreas (who moved to this<br>
structure for the Cog work) as well as Ian (who also strongly encouraged<br>
it and plans to make the change in trunk). But I don&#39;t know if the flattened<br>
directory structure might cause problems for RISC OS.<br>
<br>
The VMM support is in place if we are ready to make this change:<br>
<br>
  VMMaker class&gt;&gt;useSinglePluginsDirectory:<br>
<br>
So, question to Tim - would it cause problems for you if we move to a single<br>
directory for internal and external generated plugins?<br>
<br>
Dave<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div>