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


bug #48682: print_usage fails within classdef block

Submitter:  Colin Macdonald <cbm>
Submitted:  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
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( 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>
Project Member
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>
Project Member
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>
Project Member
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

   bug dependencies.


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)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-10-24 siko1056 Dependencies- bugs #61362 is dependent
    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.9