Linux vm: assertions and strategy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Linux vm: assertions and strategy

Schwab,Wilhelm K
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Linux vm: assertions and strategy

laurent laffont
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Linux vm: assertions and strategy

Schwab,Wilhelm K
Laurent,
 
The tests fail loudly, but that appears to be a known problem, and they can fail with FFI working (save doubles).  Maybe the problem John mentions is behind the library loading troubles??
 
Bill

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: [hidden email]
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Linux vm: assertions and strategy

Schwab,Wilhelm K
In reply to this post by laurent laffont
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: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: [hidden email]
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Linux vm: assertions and strategy

laurent laffont
2010/4/8 Schwab,Wilhelm K <[hidden email]>
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?

Well, I'm noob on VM stuff, I've just worked on how to generate VM source for Linux, that's all :)  So I cannot tell anything...I have to learn before.


 
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.

Yes I can compile it, but the VM crashes loudly when trying to use it.  This thread has a lot of informations:



Laurent Laffont
 
 
Bill
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: [hidden email]
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Linux vm: assertions and strategy

Schwab,Wilhelm K
Laurent,
 
A part-time boss/full-time friend once advised me to "get the machine to tell you what it's doing" (I was doing just that at the time, but I've never forgotten his advise<g>).
 
I compiled your vm and then decided to stick some tracing code in strategic places to find what the vm thinks it is doing in trying to load unixODBC.  Get ready:
 
     tryLoading(/sr/local/slib/squeak/3.11.13-/so.libodbc.so) = (nil)
 
In short, it does not appear to recognize a difference between plugins (the names of which it twists around to avoid collisions with external libraries - that's fine) and external libraries that have been minding their own business for many clock cycles.  The latter deserve special attention.
 
So I had an absolutely nutty idea: give dlopen() the name of the library as written :)  Clearly, that works only if one provides an absolute path in #moduleName, but (forgive/correct possible *nix-noob syndrome here) that is easy to test and even easier to do in the code.
 
So, in sqUnixExternalPrims.c in the unix/vm directory, look near the end of tryLoadModule().  My proposed workaround is to add some code before the !handle test at the end.  I will send a cut-down version of it in a separate email.  Unless someone has a better idea, I suggest we make this change to you source to give people an opportunity to use external libraries: (1) I fear at all(!!); (2) by absolute path if desired.
 
BTW, the 3.11-3 vm indeed appears to have fixed my problem w/ double return values, at least the boiled-down test works.
 
Bill
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 3:22 PM
To: [hidden email]
Subject: Re: [Pharo-project] Linux vm: assertions and strategy

2010/4/8 Schwab,Wilhelm K <[hidden email]>
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?

Well, I'm noob on VM stuff, I've just worked on how to generate VM source for Linux, that's all :)  So I cannot tell anything...I have to learn before.


 
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.

Yes I can compile it, but the VM crashes loudly when trying to use it.  This thread has a lot of informations:



Laurent Laffont
 
 
Bill
 


From: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: [hidden email]
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Linux vm: assertions and strategy

Schwab,Wilhelm K
Laurent,

The promised code for tryLoadModule(); it goes just before

  if (!handle) {
    struct stat buf;
    if ((0 == stat(path, &buf)) && ! S_ISDIR(buf.st_mode))
      fprintf(stderr, "%s\n", dlerror());
  }
  return handle;

Drop the fprintf() calls if you want - I know what was happening now?

Bill

========================


  /*
    wks - have not loaded a library?  Is the path absolute?  Use the name as given.
  */
  if( (!handle) && ( (int)(name[0])==47 ) )
  {
     handle=dlopen(name, RTLD_NOW | RTLD_GLOBAL);
     fprintf(stdout,"WKS-load-by-name(%s) = %p\n", path,handle);
  }
  else {
     if(!handle){
        fprintf(stdout,"WKS-refuse-load-by-name(%s) - not absolute path\n", path);
     }
  }



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schwab,Wilhelm K [[hidden email]]
Sent: Thursday, April 08, 2010 6:10 PM
To: [hidden email]
Subject: Re: [Pharo-project] Linux vm: assertions and strategy

Laurent,

A part-time boss/full-time friend once advised me to "get the machine to tell you what it's doing" (I was doing just that at the time, but I've never forgotten his advise<g>).

I compiled your vm and then decided to stick some tracing code in strategic places to find what the vm thinks it is doing in trying to load unixODBC.  Get ready:

     tryLoading(/sr/local/slib/squeak/3.11.13-/so.libodbc.so) = (nil)

In short, it does not appear to recognize a difference between plugins (the names of which it twists around to avoid collisions with external libraries - that's fine) and external libraries that have been minding their own business for many clock cycles.  The latter deserve special attention.

So I had an absolutely nutty idea: give dlopen() the name of the library as written :)  Clearly, that works only if one provides an absolute path in #moduleName, but (forgive/correct possible *nix-noob syndrome here) that is easy to test and even easier to do in the code.

So, in sqUnixExternalPrims.c in the unix/vm directory, look near the end of tryLoadModule().  My proposed workaround is to add some code before the !handle test at the end.  I will send a cut-down version of it in a separate email.  Unless someone has a better idea, I suggest we make this change to you source to give people an opportunity to use external libraries: (1) I fear at all(!!); (2) by absolute path if desired.

BTW, the 3.11-3 vm indeed appears to have fixed my problem w/ double return values, at least the boiled-down test works.

Bill


________________________________
From: [hidden email] [mailto:[hidden email]] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 3:22 PM
To: [hidden email]
Subject: Re: [Pharo-project] Linux vm: assertions and strategy

2010/4/8 Schwab,Wilhelm K <[hidden email]<mailto:[hidden email]>>
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?

Well, I'm noob on VM stuff, I've just worked on how to generate VM source for Linux, that's all :)  So I cannot tell anything...I have to learn before.



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.

Yes I can compile it, but the VM crashes loudly when trying to use it.  This thread has a lot of informations:
http://n4.nabble.com/Trying-to-build-alien-plugin-in-linux-tc1562896.html



Laurent Laffont


Bill


________________________________
From: [hidden email]<mailto:[hidden email]> [mailto:[hidden email]<mailto:[hidden email]>] On Behalf Of laurent laffont
Sent: Thursday, April 08, 2010 7:32 AM
To: [hidden email]<mailto:[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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
[hidden email]<mailto:[hidden email]>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


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


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