Re: [squeak-dev] Criteria For Plugin Compatibility
Locked
Re: [squeak-dev] Criteria For Plugin Compatibility
 
|
Hi Chris,
On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <[hidden email]> wrote:
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?
_,,,^..^,,,_ best, Eliot |
Re: [Vm-dev] Re: [squeak-dev] Criteria For Plugin Compatibility
|
|
Eliot,
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 cases. Dave > Hi Chris, > > On Fri, Sep 11, 2015 at 9:01 AM, Chris Cunnington <[hidden email]> > 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 > |
| Free forum by Nabble | Edit this page |