bugGNU Octave - Bugs: bug #48682, print_usage fails within classdef...


bug #48682: print_usage fails within classdef block

Submitted by:  Colin Macdonald <cbm>
Submitted on:  Tue 02 Aug 2016 10:05:20 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

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)

Fri 04 Jun 2021 09:05:00 PM UTC, comment #7: 

A workaround for this bug is to use the 1-argument form of print_usage when calling it inside of a classdef definition. This avoids the need for the function to try to guess the name of the caller. The code inside of print_usage that tries to derive the file name of the caller and extract its help text is what fails here.

Mike Miller <mtmiller>
Project Administrator
Fri 04 Jun 2021 08:39:44 PM UTC, comment #6: 

was suggested that this behavior is different enough to warrant a separate bug report, since print usage itself doesn't appear to fail (which this bug was about), but it's breaking later calls to the class.

Have created bug #60729 to capture this occurrence.

Nicholas Jankowski <nrjank>
Fri 04 Jun 2021 07:17:26 PM UTC, comment #5: 

adding a breakpoint to myclass and stepping into print_usage, the class not found error occurs immediately after line 62:

[text, format] = get_help_text (fullname);

so it seems that while help seems to work, get_help_text is still problematic.

Nicholas Jankowski <nrjank>
Fri 04 Jun 2021 06:59:08 PM UTC, comment #4: 

this just popped up again in an Octave discourse conversation [1]. print_usage within the classdef constructor causes some odd behavior that was originally thought to be a classdef/BIST problem.

the following simple class triggers the particular error:

classdef myclass
## -*- texinfo -*-
## @deftypefn  {} {@var{A} =} myclass (@dots{})
## @end deftypefn

    A = []
    function this = myclass(varargin)
      if nargin == 0
        #leave empty
      elseif nargin == 1
        this.A = varargin{1};
        print_usage ();

running through the nargin = 0, 1 and 2 cases triggers the print usage and subsequent error:

>> A = myclass(), A.A
A =

  myclass object with properties:

      A: [0x0 double]

ans = [](0x0)
>> A = myclass(1), A.A
A =

  myclass object with properties:

      A: [1x1 double]

ans = 1
>> A = myclass(3,4), A.A
error: Invalid call to myclass.  Correct usage is:

-- A = myclass (...)

Additional help for built-in functions and operators is
available in the online version of the manual.  Use the command
'doc <topic>' to search the manual index.

Help and information about Octave is also available on the WWW
at https://www.octave.org and via the help@octave.org
mailing list.
>> A = myclass(), A.A
A =

  myclass object with properties:

      A: [0x0 double]

ans = [](0x0)
>> A = myclass(1), A.A
error: class not found: myclass
error: called from
    myclass at line 14 column 16

For some reason it only affects attempts to assign a value to class properties. and only after a 'clear -c' does it return to normal.

calling `help myclass` works fine now, so wondering if the earlier comment #3 thought that fixing print_usage would be 'fairly easy' is still the case.

[1] https://octave.discourse.group/t/classdef-inconsistent-testing-errors/

Nicholas Jankowski <nrjank>
Thu 11 Aug 2016 05:51:44 AM UTC, comment #3: 

See bug #43047 for the original bug about the help function (and get_help_text) not working on classdef classes or methods.

Once we get help and get_help_text working on classdef symbols, then print_usage will probably be fairly easy.

Mike Miller <mtmiller>
Project Administrator
Thu 11 Aug 2016 05:46:34 AM UTC, comment #2: 

Additionally we may need to update the function 'get_help_text' defined in C++ 'src/help.cc' to handle the parsing of the classdef objects.


Looks like some work to be done!

Muthu A <muthua>
Thu 11 Aug 2016 05:25:50 AM UTC, comment #1: 

Looking at the code,

we see there is a branch where fullname is not defined and the class method takes it.

We should probably update the print_usage function.

Muthu A <muthua>
Tue 02 Aug 2016 10:05:20 PM UTC, original submission:  

Suppose I have a classdef block which defines a "myclass", which defines a "length" method.  If I call "print_usage" from within "length", it fails.  For example:

length(L, 2)
error: 'fullname' undefined near line 55 column 33
error: called from
    print_usage at line 55 column 16
    length at line 168 column 5

On the other hand, methods of the class defined in external .m files (e.g., in "@myclass/foo.m" rather than within the classdef block) can successfully call print_usage.

I can cook up a minimal nonworking example if needed.

Colin Macdonald <cbm>


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

Attach Files:

No files currently attached


   bug dependencies.

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by muthua (Posted a comment)
  • -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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-04 mtmiller Carbon-CopyRemoved 80942 => -
    2016-08-11 mtmiller CategoryInterpreter => Octave Function
        StatusNone => Confirmed
        Dependencies- => Depends on bugs #43047

    Back to the top

    Powered by Savane 3.6