Bugs blocking the 6.1 release

We have three bugs tagged as blockers for the 6.1 release:

   * GUI hangs on use of uiputfile
     https://savannah.gnu.org/bugs/index.php?52840
     (Apparently MacOS only?

   * Segmentation faults with clang when running the test suite
     https://savannah.gnu.org/bugs/index.php?57591
     (Intermittent failure that happens only with Clang?)

   * handles to private functions may fail after "clear functions"
     https://savannah.gnu.org/bugs/index.php?57439
     (Also revealed many function handle issues.)

I'm not sure what to do about the first two but I've been working on 
function handle issues related to the third one.  I have a series of 
pending changes that you can see here:

   https://hg.octave.org/octave-jwe

Here's a summary with additional commentary not included in the commit 
messages.  By far, the largest change is the most recent one:

   * 64b7dedbc220
     wip: refactor octave_fcn_handle class

     Split the octave_fcn_handle class internally into several 
sub-classes for the following types of function handles:

       - simple
       - scopedfunction
       - nested
       - classsimple
       - anonymous

     These changes and others leading up to this point were initially 
motivated by bug #57439 (handles to private functions may fail after 
"clear functions").  Investigating that bug revealed many more issues 
with function handles.  A rewrite seemed like a better long-term 
solution than simply fixing symptoms.

     This change is still a work in progress.  The most important 
remaining task is to make saving and loading handles work for all types 
of handles and file types (text, binary, hdf5, and mat5) but this has a 
lower priority for me than making handles themselves work properly.

Other related changes leading up to this one are, in reverse 
chronological order:

   * 4c35fd270522
     try harder to find functions in some symbol_table find_* functions

     If a function names is not already in the cache of known functions, 
add it to the list and search again.  Some search functions already 
worked this way, so this change makes the behavior more consistent.

   * c2a7460d1900
     new functions for finding scoped functions and class methods

     Moving these searches into separate functions helps to make 
changeset 64b7dedbc220 (wip: refactor octave_fcn_handle class) simpler.

   * 7d3280c8373b
     move make_fcn_handle to tree_evaluator class

     The make_fcn_handle function belongs in the evaluator.  This helps 
to make changeset 64b7dedbc220  (wip: refactor octave_fcn_handle class) 
simpler.

   * a40c4af1c73d
     refactor handling of parent functions and localfunctions

     A step toward proper scopedfunction function handles.

   * e8b8f7ea102c
     new cellstring constructor

     Trivial change that helps with implementing changeset a40c4af1c73d.

   * 4c3873bf7b9a
     store local init vars for anonymous functions in handle, not 
function object

     As with nested functions, the local variables associated with 
anonymous functions should be stored in the function handle instead of 
the function referenced by the handle.

   * 61fbce0b302b
     refactor octave_function call method

     This change is a step toward storing stack frames associated with 
handles to nested functions in the function handle instead of the 
function referenced by the handle.

   * 45227dd1dbb3
     don't document the vectorize function.

     Use of this function is discouraged.  It has limited usefulness, 
even for the obsolete @inline class.

   * a90e8d0da19d
     convert obsolete octave_fcn_inline object to @inline class

     Use of @inline objects is discouraged and should be replaced by 
anonymous functions.  Moving @inline into an M-file legacy class instead 
of deriving it from the internal function handle object makes it easier 
to remove later, and simplifies refactoring the internal function handle 
object.

   * 6900f86908af
     use shared_ptr for stack frames in call stack and for accesss and 
static links

     This makes it easy for us to grab references to subsets of stack 
frames that are used to access values of non-local symbols in nested 
functions.  Having shared access to these stack frames is necessary to 
properly implement handles to nested functions.

   * f959268bca07
     hide specific stack frame and stack frame walker classes

     The specific stack frame classes are not needed explicitly so it 
seems better to only manipulate them through the generic interface to 
the stack_frame object.  This is a fairly minor change.

Another change that will eventually be needed is to modify function 
handles to hold a weak_ptr reference to the actual function object. 
That way, handles that are used after functions are cleared can noticed 
that the function was cleared an properly attempt to reload them. 
Ultimately, this change is the one that will correctly fix the bug that 
motivated all of these other changes(!).  But until that is done, at 
least Octave won't fail and the performance issue that Philip noticed on 
Windows systems will be minimized.

I've been working on stable with the idea that these changes could be 
applied to stable and included in the release.  I know that this is a 
big set of changes to push at the last minute, but it seems best to me 
to make handles to nested functions actually work properly since that 
was one of the big changes that was supposed to happen in version 6.

A big positive from these changes is that the function handle 
implementation is much clearer and more reliable than it was before as 
well as being more compatible with Matlab behavior.  The way function 
calls are performed has also improved.

This is a lot of information to digest in one message, so we can break 
the discussion up in pieces if needed.  Either way, I welcome any comments.

jwe