[Vm-dev] Stupidifying FFI/library loading mechanism

[David T. Lewis]

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.