[Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility
Chris Cunnington
brasspen at gmail.com
Fri Sep 11 23:17:35 UTC 2015
On 2015-09-11 3:00 PM, Eliot Miranda wrote:
>
>
>
> Hi Chris,
>
> On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <brasspen at gmail.com
> <mailto:brasspen at gmail.com>> wrote:
>
> 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.
>
>
> The problems I see with this are
>
> 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.
>
> b) 32-bit plugins won't work with 64-bit VMs, and 64-bit plugins won't
> work with 32-bit VMs. Period.
>
> 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.
>
> 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.
I looked up some old Igor pdfs and I think I see what you mean.
#primtitiveFailFor: and #initializePrimitiveErrorCodes.
Yea, that looks like a better focus of energy.
>
> Does this make sense? I know its a downer, but what you propose is,
> IMO, not affordable given our resources.
Agreed.
> And I must say, *this is a VM-DEV discussion, not a general purpose
> Squeak discussion*, yes?
>
Yes.
Chris
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Chris
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150911/731aaffa/attachment-0001.htm
More information about the Vm-dev
mailing list