octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #36686] Saving and loading function handles th


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #36686] Saving and loading function handles that point to subfunctions is not working correctly
Date: Thu, 14 May 2020 16:41:21 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #8, bug #36686 (project octave):

I've been working on improving function handles.  See this mailing list
thread:

https://lists.gnu.org/archive/html/octave-maintainers/2020-05/msg00066.html

Saving and loading handles to functions is kind of a weird thing to do,
especially so for functions that are private in some way (subfunctions, local
functions, private functions) or that carry additional info with them (nested
functions) or that depend class data to work (class methods).  In any case,
maybe we can make some of these features work.

In my recent changes, Octave now creates a proper scopedfunction function
handle object that contains a reference to the scoped fucntion, the name of
the file where the function is found, and parent function info.  This should
allow us to correctly save and load handles to subfunctions, local functions,
and private functions and make them available on loading even after "clear
functions" or in a new Octave session.

If I understand correctly, we need to do something like the following after
loading the function handle from the file:

* check the currently loaded functions to see whether the referenced function
is already loaded.

* If it is, add a reference to it to the newly loaded handle object.

* If not, attempt to load the primary parent function, then search for the
appropriate subfunction.

Determining whether the function is already loaded is a bit tricky because of
possible changes in the load path.  It's not entirely clear how to do this in
a 100% reliable way.  It seem there could be many ways to end up referencing
the wrong function.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?36686>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]