I am not sure if it applies to your proposal here, but just in case I want to mention one note of caution. The #primLoadModule that was discussed previously in the "Sandbox" thread will not work on a 64-bit platform, for the same reason that FFI does not work on a 64-bit platform.
Dave
On Thu, May 26, 2011 at 01:48:42PM +0200, Igor Stasenko wrote:
Hello, i am fed up seeing the messages like "FFI can't find a library" or "VM can't find my plugin".
I think we should trash too clever intrinsic library lookup mechanism and provide a simple primitive, which attempts to load a library by given file name & path and if it fails, give an extended response, why:
- library found, but can't be loaded (because it 64bit while you
running 32 bit), or it can't be found and so on.
It should be up to the user to find and load the library first, and only after you obtained a valid library handle, attempt to do FFI calls.
IMO, same should be done to plugin loading mechanism. VM should give you the paths:
- what is the current directory
- what is the directory where VM located
then user code could attempt to load external plugin by specifying one of these paths or any other to the library which representing plugin. And only after he knows that library successfully loaded, he could attempt to use its primitives (or do FFI calls).
The approach is simple:
- first you making sure that you loaded external module/plugin, then
you start using it. And it is your responsibility to make sure you loaded it, not VM's. This could be done at image startup or at code entry point, or even inside a generic code which handling a primitive failure.
VM should behave like a stupid idiot:
- if module with name, which specified in primitive pragma
<primitive: 'foo' module: 'bar' > not registered already in internal list of VM's modules, it should fail unconditionally without even trying to load external library. Even for internal plugins: A user code can handle this error and instruct VM explicitly to load & initialize internal plugin, but not implicitly like currently VM does for internal and external plugins.
If we put a module loading mechanism at image side, it will give us much more flexibility, and all future/potential problems with it could be fixed there without touching VM code anymore.
I know that it means quite a lot of work (some named primitives even assume that they never fail). But i think it is worth it. Because if it will stay like that, we will always have issues with it, over and over again.
-- Best regards, Igor Stasenko AKA sig.