Why would it fail? FILE_IO is part of the GNU APL distribution. Regards, Elias On 12 Nov 2014 00:35, "Blake McBride" <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> 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 >>>> >>>> >>>> >>>> >>> >> >> >
