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)

parent:      26655:21708bdc1c07
use @CLASS name when searching for @CLASS/METHOD (bug #55501)

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

parent: 26594:088b8a2dcb06
use @CLASS name when searching for @CLASS/METHOD (bug #55501)

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__":

octave:1> __which__ @ftp/mkdir
ans =
  scalar structure containing the fields:
    name = @ftp/mkdir
    file = /home/cbm/src/octave.hg/scripts/@ftp/mkdir.m
    type = function

octave:2> __which__ @ftp/mkdir
ans =
  scalar structure containing the fields:
    name = @ftp/mkdir
    file = /home/cbm/src/octave.hg/scripts/@ftp/mkdir.m
    type = function

But "help" is still screwy:

octave:1> help @ftp/mkdir
'@ftp/mkdir' is a function from the file /home/cbm/src/octave.hg/scripts/@ftp/mkdir.m

-- mkdir (F, PATH)
     Create the remote directory PATH, over the FTP connection F.

     F is an FTP object returned by the 'ftp' function.
octave:2> help @ftp/mkdir
'@ftp/mkdir' is a function from the file /home/cbm/src/octave.hg/scripts/@ftp/mkdir.m

-- mkdir DIRNAME
-- mkdir PARENT DIRNAME
-- mkdir (DIRNAME)
-- mkdir (PARENT, DIRNAME)
-- [STATUS, MSG, MSGID] = mkdir (...)
     Create a directory named DIRNAME in the directory PARENT, creating
     any intermediate directories if necessary.

     If DIR is a relative path, and no PARENT directory is specified,
     then the present working directory is used.

     If successful, STATUS is 1, and MSG and MSGID are empty strings
     ("").  Otherwise, STATUS is 0, MSG contains a system-dependent
     error message, and MSGID contains a unique message identifier.

     When creating a directory permissions will be set to '0777 -
     UMASK'.

     See also: rmdir, pwd, cd, umask.

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:

 octave:1> __which__ ("@inputParser/addRequired")
ans =

  scalar structure containing the fields:

    name = @inputParser/addRequired
    file =
    type =

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

symtab.find_method ("addRequired", "inputParser");

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:

octave:2> __which__ @pyobject/delete
ans =
  scalar structure containing the fields:
    name = @pyobject/delete
    file =
    type =

octave:3> __which__ @pyobject/pyobject
ans =
  scalar structure containing the fields:
    name = @pyobject/pyobject
    file =
    type = built-in function

Now (without your patch):

octave:1> __which__ @pyobject/delete
ans =
  scalar structure containing the fields:
    name = @pyobject/delete
    file =
    type =

octave:2> __which__ @pyobject/pyobject
parse error near line 102 of file /home/cbm/src/pytave/@pyobject/pyobject.m

  external methods are only allowed in @-folders

>>>     dummy (x)
                ^

Things generally work better with methods implemented in their own m-files:

octave:5> __which__ @pyobject/fieldnames
ans =
  scalar structure containing the fields:
    name = @pyobject/fieldnames
    file = /home/cbm/src/pytave/@pyobject/fieldnames.m
    type = function

octave:6> __which__ @pyobject/fieldnames
ans =
  scalar structure containing the fields:
    name = @pyobject/fieldnames
    file = /home/cbm/.octavehg/share/octave/5.0.1/m/miscellaneous/fieldnames.m
    type = function

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:

Due to skipped revisions, the first bad revision could be any of:
changeset:   26131:2eb71b83d3e2
user:        John W. Eaton <jwe@octave.org>
date:        Tue Nov 13 02:26:52 2018 -0500
summary:     partially refactor function lookup in symbol table

changeset:   26132:759740b9454b
user:        John W. Eaton <jwe@octave.org>
date:        Tue Nov 13 02:51:34 2018 -0500
summary:     fix trivial mistake from previous change

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__':

>> __which__ ('@ftp/mkdir')
ans =

  scalar structure containing the fields:

    name = @ftp/mkdir
    file = /path/to/share/octave/5.0.1/m/@ftp/mkdir.m
    type = function

>> __which__ ('@ftp/mkdir')
ans =

  scalar structure containing the fields:

    name = @ftp/mkdir
    file = /path/to/share/octave/5.0.1/m/miscellaneous/mkdir.m
    type = function

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").

octave:19> which @sym/beta
'@sym/beta' is a function from the file /home/rik/local/share/octave/5.0.1/m/specfun/beta.m
octave:20> which @sym/beta.m
'@sym/beta.m' is the file /home/rik/.octavepkg/symbolic-2.7.1/@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).

>> help beta
'beta' is a function from the file /home/cbm/.octavehg/share/octave/5.0.1/m/specfun/beta.m

>> help sin
'sin' is a built-in function from the file libinterp/corefcn/mappers.cc

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

>> clear classes
>> help @sym/qr
'@sym/qr' is a function from the file /home/cbm/work/octsympy/octsympy.git/inst/@sym/qr.m

-- Method on @sym: [Q, R] = qr (A)
-- Method on @sym: [Q, R] = qr (A, 0)
     Symbolic QR factorization of a matrix.

    ---- 8< ----

    without the extra argument.

    See also: qr, @sym/lu.

>> help @sym/qr
error: help: '@sym/qr' not found

>> help qr
'qr' is a function from the file /home/cbm/.octavehg/lib/octave/5.0.1/oct/x86_64-pc-linux-gnu/qr.oct

-- [Q, R] = qr (A)

    ----- 8< -----

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:
   
   
Comment:
   

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.5