Yea, two thoughts here. 1. Shared libraries that come with GNU APL and are installed in a known place, could possibly be the only exceptions.
2. Create a preferences option to force unloading of all shared libraries on )CLEAR or )LOAD -AND- don't save shared variable functions. Option 2 might be the perfect solution. Thanks. Blake On Tue, Nov 11, 2014 at 10:41 AM, Elias Mårtenson <loke...@gmail.com> wrote: > Why would it fail? FILE_IO is part of the GNU APL distribution. > > Regards, > Elias > On 12 Nov 2014 00:35, "Blake McBride" <blake1...@gmail.com> wrote: > >> Dear Juergen, >> >> Saving a workspace with a )SI is for debugging. ⎕LX is for >> auto-starting a WS. >> >> Shared libraries can and do have state. One state is where the shared >> library is. Also, a shared library that has the sort of state that shared >> variables can easily be imagined. I do not think they are different. >> >> I suppose I can get around this by making my ⎕LX function always erase >> FILE_IO so that when I go to print (and FILE_IO would be expected to be >> created), I can create it at that time like I intend. >> >> It is wrong for one obvious reason. If I share my workspace with another >> machine, it will likely fail unless my ⎕LX function erases FILE_IO. >> >> Blake >> >> >> >> >> On Tue, Nov 11, 2014 at 10:20 AM, Juergen Sauermann < >> juergen.sauerm...@t-online.de> wrote: >> >>> 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 <blake1...@gmail.com> >>> 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 < >>>> juergen.sauerm...@t-online.de> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>
