Re: [Bug-apl] Shared library survives session

[Blake McBride]

Dear Juergen,

That is not good.  I feel very strongly about this.  If it didn't survive a )SAVE / )LOAD then the executing code would see that the function is undefined and it can do whatever it needs to do to load the library - you know - like get the shared library from some setting, or go through an algorithm to find it.  The way it works, a workspace that I share is almost guaranteed not to work.  My code will see the function is defined and assume it works.

FILE_IO is not a plain function.  Attempting to make it appear so is a problem.

Look, some things are separate from a workspaces (like ⎕TZ).  SQL data is persisted separately.  There is no attempt to make the data act like variables that get saved.  Also, SQL database connections are not persisted.  Your code had to make a connection each time a new WS is loaded.  Shared libraries should work the same.

Thanks.

Blake

On Tue, Nov 11, 2014 at 5:38 AM, Juergen Sauermann <address@hidden> wrote:

Hi Blake,

if you save a workspace containing a native function then the name of the shared library
is saved and when GNU APL loads such a workspace then it attempts to reload the shared library.
If you move the workspace to a different machine then it should still work unless the shared library is missing.

The idea is that a native function should behave like a normal APL function as much as possible.

/// Jürgen

On 11/11/2014 06:01 AM, Blake McBride wrote:

Greetings,

If I do:

'lib_file_io.so'⎕FX'FILE_IO'

I get a function that is bound to the shared library.  If I then do:

      )SAVE XYZ

      )OFF

apl

      )LOAD XYZ

I see FILE_IO is defined.  How can this be?  How could it already be bound to the shared library?  Wouldn't I have to do this afresh with (at least) every new evocation of APL?  How could it possibly still be bound?  What if I moved that workspace to a different machine?

Thanks.

Blake