[Vm-dev] Auto-load plugins from the net (was: VM Maker: VMMaker.oscog-eem.2347.mcz)

Eliot Miranda eliot.miranda at gmail.com
Fri Mar 9 16:30:32 UTC 2018


Hi Tim,

> On Mar 8, 2018, at 5:46 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
> 
>> On 08-03-2018, at 5:25 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> 
>> 
>> That's an interesting idea, first I've heard of it. Can you sketch out how
>> such a loading scheme might work?
>> 
>> I am envisioning something along the lines of:
>> 
>> - try loading the primitive
>> - if not found determine name of the plugin for that primitive
>> - look up href location for the plugin (modulo 32/64 bit host/image)
>> - also check if we tried this once before, don't try it again
>> - download plugin file to a writeable location on your computer, where that
>> location would be in the lookup path for module loading
>> - maybe validate the file in some way for security
>> - try loading the primitive again
>> - if not successful, remember that this primitive is not available, then fall
>> back on the actual fallback code
>> 
>> Is that the idea?
> 
> Pretty much got it. The only extra info we'd need is a root for module URLs - something like modules.squeak.org maybe? and work out the vm details to complete the path to something like https://module.squeak.org/linux/32/armv6/blogsmasherplugin
> 
> We'd know at that point that there isn't an installed copy already on the machine since it would have been found by the external lookup. It wouldn't need redownloading unless we did something to delete that copy - say a date related thing to say it's out of date or the rental is due :-)


In doing this it would be nice to decouple the plugin primitive binding mechanism from invocation a la VisualWorks. The issue here is that in the Squeak VM binding is done on first invocation.  The n VisualWorks an inbound invocation results in a callback. Although a specific primitive failure with its own failure code is feasible, it means we would have to rewrite every plugin primitive method so it's infeasible.  The callback selector would have to be in the specialObjectsArray.  The system's response would be to bind the primitive and retry, but this would happen at the Smalltalk level, not hidden in the VM.  Esteban has already provided some of the binding machinery (a primitive to look up function addresses by name in a loaded library).

> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> "How many Motie Warriors does it take to change a lightbulb?” 
> "None. One of the dead ones will do it."
> 
> 
> 


More information about the Vm-dev mailing list