Laurent,

I was reading a little about Eliot's proposed FPU init changes to FFI and then 
took another look at your evolving Pharo vm source and I was struck by either: 
(1) a brilliant (well, fairly clever) workaround to my external library 
hassles; (2) a completely and totally stupid idea.

You have based the vm on the 3.11-3 sources, so it hopefully fixes the double 
return defect that has been driving me nuts.  My remaining problem is to get 
the vm to load external libraries.  Would a simple plugin to expose dlopen() 
(and perhaps dlsym() while we're at it) solve the problem?  I should then be 
able to bypass the FFI code that calls dlopen() (I suspect that it's pretty 
badly broken) by setting the handle of any ailing library by using absolute 
paths if necessary.  From there, I *think* everything will just work.

What do you think?

Somewhat related, have you looked at compiling the Alien plugin?  The more I 
look at posts on Alien, the more I wonder whether it will help, as there are 
suggestions that it is weak on external calls.  Still, it would be nice to get 
it going and look over the tests the boldness that comes from watching them 
pass having actually done something.

Bill


________________________________
From: [email protected] 
[mailto:[email protected]] On Behalf Of laurent 
laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: [email protected]
Subject: Re: [Pharo-project] Linux vm: assertions and strategy


I'm totally noob on FFI. Maybe the vm-dev mailing list is more appropriate ?  
It seems there's actually some problems with it 
http://n4.nabble.com/forum/Search.jtp?tpl=search-page&node=104410&query=ffi

On my machine, 20/21 FFI unit tests fails...

I haven't been able to build last revision of squeak-vm trunk.

Laurent Laffont


On Thu, Apr 8, 2010 at 1:53 PM, Schwab,Wilhelm K 
<[email protected]<mailto:[email protected]>> wrote:
Laurent, all,

If I may jump to conclusions a little, the 3.11-3 vm's changes break the 
loading of libraries, certainly to the point of being arkane.  Beyond that, 
LinuxODBC is transparent to it, so I am left wondering how it is suppose to 
work at all??

The RC3 one-click image and vm produce very nice fonts on my Ubuntu laptop, but 
it retains the FFI/double defect, and from the naming of the plugins, must be 
based on a pre 3.11-3 vm.

Is the plan to use 3.11-3 for the one-click?  If so, we need to do something 
about external libraries; at a minimum, LinuxODBC should work, whether by fully 
understanding how to use environment variables, or (as I suspect) getting the 
dlopen() call to work again.

Another option is to identify the FPU related fixes and apply them to the 
current one-click vm.

Any preferences?  Any success with 3.11-3 and LinuxODBC?  I'd be happy to be 
wrong about this.

Bill


_______________________________________________
Pharo-project mailing list
[email protected]<mailto:[email protected]>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to