[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