bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Shared library survives session


From: Juergen Sauermann
Subject: Re: [Bug-apl] Shared library survives session
Date: Tue, 11 Nov 2014 17:20:45 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0

Hi Blake,

there is a big difference between shared variables and shared libraries: shared variables have state.
For that reason shared variables cannot be restored from a file in a reasonable way.

Assume for the moment that we don't reload shared libraries. Then it would not be possible
to continue any workspace with a non-clear )SI and shared libraries.

It is actually the shared library that decides what to do when a workspace is cleared (such as before )LOAD).
The shared library is informed just before that happens and may or may not unload itself. Some libraries do that
(most likely SQL) while others don't (FILE_IO and also, I believe, emacs mode).

In the case of FILE_IO it is mostly stateless so it doesn't unload itself.

/// Jürgen


On 11/11/2014 04:11 PM, Blake McBride wrote:
Shared variables is a good example and is somewhat similar to shared libraries.  Shared variables never survive a restart of APL.  What you are doing is utterly the same as trying to re-establish a shared variables on )LOAD.  It just doesn't make sense to do that for many obvious reasons.


On Tue, Nov 11, 2014 at 9:04 AM, Blake McBride <address@hidden> wrote:
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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]