[Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility

David T. Lewis lewis at mail.msen.com
Fri Sep 11 19:16:27 UTC 2015


I agree. Indeed, even with an interpreter VM it has long been the case
that a plugin compiled as 64 bit will not work on a VM compiled for 64 bit
and vice versa. With the number of variations of 32/64, Spur/V3, and so
forth, I don't think that this is a problem worth worrying about. Better
to just be a aware that plugins are not readily interchangeable in those


>  Hi Chris,
> On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <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.
> Does this make sense?  I know its a downer, but what you propose is, IMO,
> not affordable given our resources.
> And I must say, *this is a VM-DEV discussion, not a general purpose Squeak
> discussion*, yes?
> 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

More information about the Vm-dev mailing list