[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bugs blocking the 6.1 release
From: |
John W. Eaton |
Subject: |
Bugs blocking the 6.1 release |
Date: |
Wed, 13 May 2020 14:18:39 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
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
- Bugs blocking the 6.1 release,
John W. Eaton <=
- Re: Bugs blocking the 6.1 release, Dmitri A. Sergatskov, 2020/05/13
- Re: Bugs blocking the 6.1 release, Markus Mützel, 2020/05/14
- Re: Bugs blocking the 6.1 release, Markus Mützel, 2020/05/14
- Re: Bugs blocking the 6.1 release, John W. Eaton, 2020/05/14
- Re: Bugs blocking the 6.1 release, John W. Eaton, 2020/05/14
- Re: Bugs blocking the 6.1 release, Markus Mützel, 2020/05/16
- Re: Bugs blocking the 6.1 release, John W. Eaton, 2020/05/16
- Re: Bugs blocking the 6.1 release, Markus Mützel, 2020/05/16
- Re: Bugs blocking the 6.1 release, Markus Mützel, 2020/05/22
- Re: Bugs blocking the 6.1 release, Markus Mützel, 2020/05/23