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 >>> >>> >>> >>> >> > >
