[Vm-dev] Auto-load plugins from the net (was: VM Maker: VMMaker.oscog-eem.2347.mcz)
David T. Lewis
lewis at mail.msen.com
Fri Mar 9 01:25:26 UTC 2018
On Thu, Mar 08, 2018 at 09:56:29AM -0800, tim Rowledge wrote:
> > On 08-03-2018, at 7:57 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > but since we no longer include the processor simulator plugins in the standard vm builds, the VM obtained by
> > image/getGoodSpurVM.sh
> > won't allow simulating the CoInterpreter (the JIT), only the StackInterpreter. So this needs to be fixed.
> > I could build the processor simulator plugins and put them on my website or we could set up a build on the CI infrastructure.
> I'd urge having them built by the autobuild stuff for consistency. It must
> surely be possible to have the built external plugins moved off to one
> side as part of that build? Then we'd 'merely' need a suitable link in
> the download page(s) to point to them for manual fetching and a stable
> address so that Eliot's build-vmmaker script can reliably find them.
> In fact, having reliable URLs for any of the external plugins (strictly
> speaking any plugin, since we can over-ride an internal plugin if needed)
> would be interesting because then we could actually do what was originally
> intended with the "I can't find no stinkin plugin of that name!" error,
> which was to handle it by looking up on the net for a plausible version
> and installing it and restarting the operation. Maybe a mere 20 years later
> we can actually implement this?
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?
More information about the Vm-dev