bugGNU Octave - Bugs: bug #55501, subsequent calls to "help...


bug #55501: subsequent calls to "help @sym/beta" gives "help beta" text

Submitted by:  Colin Macdonald <cbm>
Submitted on:  Thu 17 Jan 2019 06:08:22 PM UTC  
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  5.0.1 Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 22 Jan 2019 09:00:44 PM UTC, comment #19:

Okay, closing report and checking it off on the 5.0 Bug Fix List (https://wiki.octave.org/Bug_Fix_List_-_5.0_Release#Bugs_marked_as_regressions).

I think we can proceed to making an RC1 candidate now.

Rik <rik5>
Project Administrator
Tue 22 Jan 2019 07:51:51 PM UTC, comment #18:

I'm sorry I didn't notice there was a different change made to stable---I was still talking about jwe's patch.

I confirm this is indeed fixed for @class. And doesn't seem any worse for classdef so I agree the regression is fixed.

Please close.

Colin Macdonald <cbm>
Tue 22 Jan 2019 06:53:57 PM UTC, comment #17:

@Colin, make sure that you are testing the sources from hg, not the patch I posted here because the changeset I eventually pushed is different from the one I posted here. It should fix the problem for which and help because it does the work of decoding @CLASS/FCN in the symbol table find_function method instead of just inside the help_system which function.

John W. Eaton <jwe>
Project Administrator
Tue 22 Jan 2019 06:32:30 PM UTC, comment #16:

Maybe try 'make clean' or 'make distclean' just in case there is compiled cruft on your system?

Rik <rik5>
Project Administrator
Tue 22 Jan 2019 06:27:10 PM UTC, comment #15:

@Rik Strange! It does not work for me: it fixes only "__which__" but not help (see output below)

I will try again in case I messed something up...

Colin Macdonald <cbm>
Tue 22 Jan 2019 04:38:07 PM UTC, comment #14:

This works for me now. I can run 'help @ftp/mkdir' multiple times and always get the correct text. This is on the stable branch at hg id

I won't close the bug though until Colin can also verify.

Rik <rik5>
Project Administrator
Tue 22 Jan 2019 06:13:50 AM UTC, comment #13:

Ok I've tested the patch. It seems to fix "__which__":

But "help" is still screwy:

Note that the "is a function from the file /home/cbm/src/octave.hg/scripts/@ftp/mkdir.m" is now correct but its still grabbing the wrong help text.

So there is still a regression just for plain 'ol @classes.

Colin Macdonald <cbm>
Mon 21 Jan 2019 11:26:17 PM UTC, comment #12:

Oops, I didn't use the character position correctly in the first changeset. Try the one posted here instead.

For classdef, I think it "works" about the same as before:

I see a couple of problems with what is happening in help_system::which. First, if the classdef file (in this case, inputParser.m) has not yet been parsed, then a call like

doesn't cause it to be parsed, so it falls back on looking in the load path and somehow returns the incorrect result shown above.

If the classdef file has been parsed, then symbol_table::find_method returns a valid object, but it is an octave_classdef_meta object, not an octave_function object that contains the addRequired method.

So some additional work is needed to properly handle classdef, but that was true with 4.4.1 as well. At least with the patch that I'm proposing, I think things are working as well as before, so I would no longer count this as a regression.

(file #46065)

John W. Eaton <jwe>
Project Administrator
Mon 21 Jan 2019 09:05:13 PM UTC, comment #11:

Maybe it depends on what you mean by "work" in "did they work with _which_ previously".

Octave 4.4.1:

Now (without your patch):

Things generally work better with methods implemented in their own m-files:
I will try your patch later and see how this example behaves...

There are certainly problems about doc strings and classdef, e.g., https://savannah.gnu.org/bugs/index.php?48041

Colin Macdonald <cbm>
Mon 21 Jan 2019 08:47:31 PM UTC, comment #10:

The attached patch will solve the immediate problem for legacy @CLASS methods, but won't help for classdef methods, at least according to the FIXME comment for find_method. Did they work with _which_ previously? I'm guessing no as there are similar problems with classdef for finding doc strings.

(file #46062)

John W. Eaton <jwe>
Project Administrator
Sat 19 Jan 2019 10:08:57 PM UTC, comment #9:

I will try to take a look at this problem in the next couple of days.

John W. Eaton <jwe>
Project Administrator
Sat 19 Jan 2019 05:01:03 PM UTC, comment #8:

@Colin: Thanks for doing the bisection. I think this has to be fixed before the 5.0 release.

Newly filed bug #55519 looks like a duplicate of this.

Rik <rik5>
Project Administrator
Sat 19 Jan 2019 09:35:03 AM UTC, comment #7:

From bisect:

Colin Macdonald <cbm>
Fri 18 Jan 2019 09:02:02 PM UTC, comment #6:

This probably does need to be fixed before the release. I upped the severity to 4. If you can run a bisection that would be helpful. My intuition is the same as yours, something related to changes in the symbol table regarding scope, subfunctions, etc.

Rik <rik5>
Project Administrator
Fri 18 Jan 2019 07:56:29 PM UTC, comment #5:

Thank you both. So its clear its something with broader implications than Octave Forge packages.

Do you need me to bisect this? Seems likely this is related to changes made for scope, subfunctions etc.

Is this severity 4 for the release?

Colin Macdonald <cbm>
Fri 18 Jan 2019 07:23:38 PM UTC, comment #4:

I get the same behavior with '@ftp/mkdir'.

Demo with Octave 5.0.1, no packages loaded, using '__which__':

Mike Miller <mtmiller>
Project Administrator
Thu 17 Jan 2019 09:54:53 PM UTC, comment #3:

Also just confirmed that this is a regression from 4.4.1.

The file which.m call the C++ function _which_ located in help.cc. It is the C++ function which is returning the incorrect results which the m-file then just formats before printing.

Rik <rik5>
Project Administrator
Thu 17 Jan 2019 09:46:21 PM UTC, comment #2:

I think this is related to the handling of the load path, rather than the help function.

I loaded the symbolic package, and then used which to find out what m-file was associated with "@sym/beta". Turns out, it thinks its the core Octave function. If you use the full filename with extension then it works ("@sym/beta.m").

Not that you should need to do this, but "help @sym/beta.m" works for me.

Rik <rik5>
Project Administrator
Thu 17 Jan 2019 06:15:06 PM UTC, comment #1:

Should've mentioned: I cannot reproduce on 4.4.1.

Colin Macdonald <cbm>
Thu 17 Jan 2019 06:08:22 PM UTC, original submission:

If I load the symbolic package in the latest 5.0.1 (well within a day or two), "help" sometimes fails.

1. "help @sym/beta". This works.

2. "help @sym/beta". Now it gives the result of the core "help beta".

All subsequent calls to "help @sym/beta" give the core beta function.

100% reproducible for me. "clear classes" resets the behaviour so that "help @sym/beta" works once correctly again.

Notably I cannot reproduce with "help @sym/sin": perhaps because of built-in versus m-file (but that's just a guess).

Here's another overloaded function, with slightly different but related results:

So maybe different behaviours depending on whether the core function is a .oct file, .cc file or .m file.

Colin Macdonald <cbm>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #46065:  diffs-1.txt added by jwe (1KiB - text/plain)
file #46062:  diffs.txt added by jwe (1KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by cbm (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-22 rik5 Open/ClosedOpen => Closed
    2019-01-22 rik5 StatusConfirmed => Fixed
    2019-01-21 jwe Attached File- => Added diffs-1.txt, #46065
    2019-01-21 jwe Attached File- => Added diffs.txt, #46062
    2019-01-18 rik5 Severity3 - Normal => 4 - Important
    2019-01-17 rik5 StatusNone => Confirmed
        Carbon-Copy- => Added jwe

    Back to the top

    Powered by Savane 3.4