<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2015-09-11 3:00 PM, Eliot Miranda
wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE3GUhsgoH7vWnAZZQDZ5aTO7UgmK6-rvgGK+sMB03Z=yw@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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"><<a
moz-do-not-send="true" href="mailto:brasspen@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:brasspen@gmail.com">brasspen@gmail.com</a></a>></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's directory and that it could
be used just by starting up the image. I'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't work with 64-bit VMs, and
64-bit plugins won'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't put much effort into this
level of drag-and-drop compatibility. Instead I'd put
energy into good error messages so that when plugins don't
work the user can find out why, and that when the wrong
kind of plugin is used the VM doesn't just stumble along,
maybe producing incorrect results, but instead puts the
plugin out with a comprehensible complaint.</div>
</div>
</div>
</div>
</blockquote>
I looked up some old Igor pdfs and I think I see what you mean.
#primtitiveFailFor: and #initializePrimitiveErrorCodes. <br>
Yea, that looks like a better focus of energy. <br>
<blockquote
cite="mid:CAC20JE3GUhsgoH7vWnAZZQDZ5aTO7UgmK6-rvgGK+sMB03Z=yw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
Agreed. <br>
<br>
<blockquote
cite="mid:CAC20JE3GUhsgoH7vWnAZZQDZ5aTO7UgmK6-rvgGK+sMB03Z=yw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>And I must say, *this is a VM-DEV discussion, not a
general purpose Squeak discussion*, yes?</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
Yes. <br>
<br>
Chris <br>
<blockquote
cite="mid:CAC20JE3GUhsgoH7vWnAZZQDZ5aTO7UgmK6-rvgGK+sMB03Z=yw@mail.gmail.com"
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">
<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'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'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't
appear to work on my Ubuntu 15.04.</p>
<p>So, I don'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'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>
</blockquote>
<br>
</body>
</html>