<br><br><div class="gmail_quote">2011/5/26 Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 26 May 2011 14:16, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
> I am not sure if it applies to your proposal here, but just in<br>
> case I want to mention one note of caution. The #primLoadModule<br>
> that was discussed previously in the "Sandbox" thread will not<br>
> work on a 64-bit platform, for the same reason that FFI does not<br>
> work on a 64-bit platform.<br>
><br>
</div>Sorry, i din't followed that issue (cant remember). The reason because<br>
of mixing 32/64bit libraries, or something else?<br>
<br>
The primitive you mentioning reusing the same routine to load external module<br>
as VM internally for primitives do. So, it is step in right direction<br>
(explicitly instruct VM to load modules),<br>
but more work needs to be done.<br>
<br>
Now imagine that you have a primitives:<br>
<br>
loadInternalModule: moduleName<br>
loadExternalModule: moduleName path: pathToModuleLibrary<br>
<br>
and by analogy, for FFI:<br>
<br>
loadExternalLibrary: pathToExternalLibrary<br>
<br>
and in case of failure, these prims could then give you an extended response:<br>
- module already loaded<br>
- internal module not exists<br>
- external library file not found<br>
- external library file found but cannot be loaded (not a library,<br>
mix 64/32bit mode etc)<br>
- module loaded but failed to initialize<br>
.. etc<br>
<br>
Then you can easily diagnose the problems per each attempt to load some library.<br>
But not like today.. if you telling to load module named 'GL' , VM<br>
tries all different combinations<br>
like<br>
libGL.so GL.so<br>
libGL.dynlib<br>
multiplied on various crazy locations in file system..<br>
<br>
Is it only me who thinks that, this looks like shooting blindly into<br>
the sky hoping there are enough ducks flying so you can hit one?<br>
<br>
Also, if you explicitly control the module loading then you can also<br>
control which module takes priority<br>
- internal or external one.<br>
<br>
if you know, today's VMs first attempting to load external library<br>
with given name, and only then internal plugins.<br>
<br>
Apparently, if you wanna play games in sandbox, you'd be willing to<br>
change a priority or even do not attempt to use<br>
any external modules at all.<br></blockquote><div><br>+1<br>paths used to look for external libraries (FFI or plugins) should be simpler and documented. I am always looking into log to know why it failed.<br>IMO, it should also be easy to share external libs between VMs.<br>
I already share some libraries but it requires to discover some strange paths.<br><br>#Luc<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br>