<div dir="ltr">Hi Chris,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <span dir="ltr">&lt;<a href="mailto:brasspen@gmail.com" target="_blank">brasspen@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    
    <p>I had the idea that a plugin from
      one VM could be dragged into another VM&#39;s directory and that it
      could be used just by starting up the image. I&#39;ve done a little
      experimenting and it seems more of an idea of a reality. The
      functionality is there, but VM developers over the years have not
      seen this as a priority. Typically plugins and their VMs are
      compiled together. Or a person adds one by recompiling a VM
      compilation rig they already have.</p></div></blockquote><div><br></div><div>The problems I see with this are</div><div><br></div><div>a) a plugin compiled for Spur may not work with V3 or vice verse.  The issue is the header size of an object.  Some plugins, but not all, use this define, and the header sizes between Spur and V3 are incompatible.</div><div><br></div><div>b) 32-bit plugins won&#39;t work with 64-bit VMs, and 64-bit plugins won&#39;t work with 32-bit VMs. Period.</div><div><br></div><div>Now there are platform-level packaging technologies, such as fat binaries on Mac OS X, that allow one to construct plugins that contain more than one binary.  But this is a lot of work to build and maintain.</div><div><br></div><div>So personally I wouldn&#39;t put much effort into this level of drag-and-drop compatibility.  Instead I&#39;d put energy into good error messages so that when plugins don&#39;t work the user can find out why, and that when the wrong kind of plugin is used the VM doesn&#39;t just stumble along, maybe producing incorrect results, but instead puts the plugin out with a comprehensible complaint.</div><div><br></div><div>Does this make sense?  I know its a downer, but what you propose is, IMO, not affordable given our resources.</div><div><br></div><div><br></div><div>And I must say, *this is a VM-DEV discussion, not a general purpose Squeak discussion*, yes?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <p>As I had a rig for the
      Interpreter VM I decided to compile a plugin and see if I could
      drag it around to other VM directories for use. Most times it
      didn&#39;t work.</p>
    <p>I compiled a TheUniversalAnswer
      plugin which returns 42. I moved it from a 4.14.1-3430 VM to a
      4.14.1-3414 VM. I could get it to work if I did not use the
      squeak.sh start script. That is, I dragged so.vm-sound-null,
      so.TheUniversalAnswer and so.vm-display-X11 into the same
      directory as the VM binary. That worked.</p>
    <p>The only way to see the external
      plugins is with #listLoadedModules. But, irritatingly, modules are
      loaded as needed, so once you have proof of using the primitive
      from the plugin, yea, it will appear as a result of that Smalltalk
      listLoadedModules message. So, it&#39;s not that useful.</p>
    <p>I dragged so.TheUniversalAnswer
      around to other VMs such as 4.0.3-2202 and 4.13.10-3268 without
      success. And the unload selectors #forgetModule: and
      unloadModule:, which both use primitive 571 don&#39;t appear to work
      on my Ubuntu 15.04.</p>
    <p>So, I don&#39;t know if a community
      of plugins passed around is in the offing. What I have learned is
      that many of the answers are in sqUnixExternalPrims.c. The issues
      are really where does the VM look for primitives and what does it
      do when it finds one. It appears to me, after reading both the
      non-Cog and Cog versions of that file, that this an interesting
      area poorly documented that VM developers alter in haste to get on
      to something else.</p>
    <p>It&#39;s pretty important stuff,
      though. Do you start the VM with the binary on the path? Do you
      use squeak.sh? Where is the VM looking for stuff. Where will FFI
      look for stuff. And so on.<span class="HOEnZb"><font color="#888888"><br>
    </font></span></p><span class="HOEnZb"><font color="#888888">
    <p>Chris <br>
    </p>
  </font></span></div>

<br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>