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

Reply via email to