refactoring function handle implementation for version 6

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

refactoring function handle implementation for version 6

John W. Eaton
Administrator
I pushed a series of changesets to stable to improve the implementation
of function handles.

   a5be4fc661d6  hide specific stack frame and stack frame walker classes
   9a3deb17b4ea  use shared_ptr for stack frames in call stack and for
accesss and static links
   7a8c69c4eb55  convert obsolete octave_fcn_inline object to @inline class
   e9a12be5fd79  don't document the vectorize function.
   8eb8ba8aff9a  refactor octave_function call method
   5bfa8e018704  store local init vars for anonymous functions in
handle, not function object
   0ffae065ca03  new cellstring constructor
   71c34141cc2d  refactor handling of parent functions and localfunctions
   d05a4194f1ad  move make_fcn_handle to tree_evaluator class
   48c1e8d88ea2  new functions for finding scoped functions and class
methods
   76a9f31540e3  try harder to find functions in some symbol_table
find_* functions
   22e90bdcf47f  make find_scoped_function available in symbol_table class
   8f3aedc5ab4f  split search for private functions into separate function
   55f82d23fe5e  new octave_classdef_meta::is_classdef_method function
   e760fef2829c  refactor octave_fcn_handle class
   23fe97205db5  new tests for bug #57941
   8dd50efa3c47  new nested function handle tests
   5bca1527b034  new tests for bug #51567
   bdd52f5e4170  new test for bug #58519

These changes have also been merged with default.

I know that it's a big set of changes to go on stable, but it fixes a
number of issues with function handles and sets up a better framework to
further improve compatibility in the future.

I presented a description on this list of most of these changes about a
month ago:

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

and we discussed them briefly during the recent developers meeting.

Please open bug reports if there are any issues.

Comments also welcome here.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: refactoring function handle implementation for version 6

John W. Eaton
Administrator
On 6/11/20 1:41 PM, Rik wrote:

> I think this is a good and necessary step.  However, it has
> de-stabilized things a bit and we just need to cycle through the
> design/build/test loop as fast as possible to get back to a
> release-quality stable branch.
>
> I am getting 7 failures now when I run 'make check'.  These seem easy to
> resolve.

>>>>>> processing /home/rik/wip/Projects_Mine/octave-stable/libinterp/octave-value/ov-fcn-inline.cc-tst  ***** error <STR argument must be a string> inline (1)

Sorry, I should have mentioned this one.  The ov-fcn-inline.cc file has
been removed from the source tree, so the generated -tst file is
obsolete and should be removed from your build tree.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: refactoring function handle implementation for version 6

John W. Eaton
Administrator
In reply to this post by John W. Eaton
On 6/11/20 1:41 PM, Rik wrote:

> Also, it seems that vectorize() has gone away in Octave, but it still
> exists in Matlab when applied to function handles.  The following code works
>
> f = @(x,y) x * y
> f = function handle with value:
>     @(x,y)x*y
> f2 = vectorize (f)
> f2 = function handle with value:
>     @(x,y)x.*y

The Matlab docs mark vectorize as "not recommended" and only state that
the input can be a character vector, string scalar, or inline function
object.

Octave's vectorize function has always been bad.  For example, try

   vectorize ("fprintf ('the file is: /foo/bar\n')")

in an old version.

If you think it is worth doing, I could probably restore the old buggy
behavior for anonymous function handles and character strings.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: refactoring function handle implementation for version 6

John W. Eaton
Administrator
On 6/11/20 3:13 PM, Rik wrote:

> I doubt it gets used very much, but as long as Matlab has it, we could
> continue to support the behavior for strings and inline function objects
> alone, no need to extend to function handles.  You could put the
> vectorize.m in scripts/legacy and have it produce a warning when it is
> first used.  A prototype example is isdir.m in that directory.

OK, I'll do that.  It should be easy to also do it for anonymous
functions: just check for function handle with class(), determine
whether it is an anonymous function and get the text of the function
body with functions().  Then apply the same transformation as we use for
inline functions to that string, then return a new function handle
constructed from that string.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: refactoring function handle implementation for version 6

John W. Eaton
Administrator
On 6/11/20 3:33 PM, John W. Eaton wrote:

> On 6/11/20 3:13 PM, Rik wrote:
>
>> I doubt it gets used very much, but as long as Matlab has it, we could
>> continue to support the behavior for strings and inline function objects
>> alone, no need to extend to function handles.  You could put the
>> vectorize.m in scripts/legacy and have it produce a warning when it is
>> first used.  A prototype example is isdir.m in that directory.
>
> OK, I'll do that.  It should be easy to also do it for anonymous
> functions: just check for function handle with class(), determine
> whether it is an anonymous function and get the text of the function
> body with functions().  Then apply the same transformation as we use for
> inline functions to that string, then return a new function handle
> constructed from that string.

I pushed two changes to restore this function:

   https://hg.savannah.gnu.org/hgweb/octave/rev/925c169a4958
   https://hg.savannah.gnu.org/hgweb/octave/rev/53d8e7ca99c5

It's in legacy instead of deprecated because like the other "legacy"
functions, it is still part of Matlab so there's no way to know when we
can remove it.

I forgot to include the warning discouraging its use.  And now I see
that genvarname also lacks a warning.  Should they all have warnings?
Should the inline constructor also issue a legacy function warning?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: refactoring function handle implementation for version 6

John W. Eaton
Administrator
On 6/11/20 6:37 PM, Rik wrote:

> I'd vote yes for having vectorize and genvarname produce warnings.
>
> I'm ambivalent about inline().  I just tried "f = inline ('x + 1')" with
> Matlab 2020a and it succeeds with no warning.  On the other hand, inline()
> is really, really old and it is trivial to update code to use function
> handles instead.  And, if people really have old legacy code that they
> don't want to re-write they can slap
>
> warning ("off", "Octave:legacy-function")
>
> in their .octaverc and never hear another complaint.

I pushed the following changeset to add warnings for vectorize,
genvarname, and the inline constructor:

   http://hg.savannah.gnu.org/hgweb/octave/rev/ef8cf8dda0ba

jwe