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 AM, Juergen Sauermann < juergen.sauerm...@t-online.de> wrote: > 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 should > be unloaded or not > than the user of the library. Making this a user preference would cause > more harm than > benefits because all such a preference could achieve is additional errors > in cases that > would properly work when the preference is not set. > > If we would not )SAVE native functions then some workspaces, for example > the FILE_IO workspace > would no longer work, A )LOADed workspace could re-establish to-level > native functions (but not, for > example, localized native functions). A COPYed workspace could not even > re-establish its native functions. > > That all sounds like something that you want to avoid in the first place. > > /// Jürgen > > > On 11/11/2014 06:21 PM, Blake McBride wrote: > > 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > >