Re: [Bug-apl] Shared library survives session

2014-11-12 Thread Blake McBride
Dear Juergen, What I have done is change my code to have my ⎕LX function ⎕EX 'FILE_IO'. This way my later code can see that FILE_IO doesn't exist through ⎕NC, and it can instantiate it when needed utilizing parameters I choose at runtime. This works for me. Blake On Wed, Nov 12, 2014 at 5:19 A

Re: [Bug-apl] Shared library survives session

2014-11-12 Thread Juergen Sauermann
Hi Blake, as I mentioned earlier, the designer of a native function can decide if she wants the corresponding shared library to be unloaded or not. I would claim that the designer of a library is in a better position to decide whether her library

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread Blake McBride
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

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread Elias Mårtenson
Why would it fail? FILE_IO is part of the GNU APL distribution. Regards, Elias On 12 Nov 2014 00:35, "Blake McBride" 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 sh

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread Blake McBride
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 ar

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread Juergen Sauermann
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 shar

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread Blake McBride
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,

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread 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 throu

Re: [Bug-apl] Shared library survives session

2014-11-11 Thread Juergen Sauermann
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

[Bug-apl] Shared library survives session

2014-11-10 Thread Blake McBride
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 afr