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

 
 

bug #60729: print_usage within classdef constructor breaks subsequent calls to the class

Submitted by:  Nicholas Jankowski <nrjank>
Submitted on:  Fri 04 Jun 2021 08:38:46 PM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Confirmed Assigned to:  None
Originator Name:  Nicholas Jankowski 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.

 

Sat 05 Jun 2021 07:55:55 PM UTC, comment #4: 

If you're looking into this, there is also the related bug #48682, where print_usage doesn't know that it's being called from within a method defined in a classdef block.

Mike Miller <mtmiller>
Project Administrator
Sat 05 Jun 2021 10:49:44 AM UTC, comment #3: 

In this case, print_usage ultimately calls the get_help_from_file function that is defined in oct-parse.yy and that attempts to parse the file again.  That doesn't work for classdef files.  I'll take a look at fixing this problem.

John W. Eaton <jwe>
Project Administrator
Sat 05 Jun 2021 12:55:14 AM UTC, comment #2: 

> it messes with the behavior of the class definition already loaded into memory.


so how does it manage that? Shouldn't it be a esad only operation? Variable name collision? Overzealous cleanup?

Nicholas Jankowski <nrjank>
Project Member
Fri 04 Jun 2021 08:55:53 PM UTC, comment #1: 

Confirmed on the development branch.

Here is an even more minimal set of steps, with the same class example you provided.

>> a = myclass ();
>> b = myclass (2);
>> [text, format] = get_help_text ('myclass');
>> b = myclass (2);
>> [text, format] = get_help_text ('/full/path/to/myclass.m');
>> b = myclass (2);
error: class not found: myclass
error: called from
    myclass at line 14 column 16

When 'get_help_text' is called on the full file name of the m-file containing the classdef definition, it returns the help text, but it messes with the behavior of the class definition already loaded into memory.

When it's called on just the short class name, it works fine.

Mike Miller <mtmiller>
Project Administrator
Fri 04 Jun 2021 08:38:46 PM UTC, original submission:  

tested on Octave 6.2.1 (hg id: f6f664d1027a) on Windows (zip package installer)

as mentioned in bug #48682 and originating from the Octave Discourse [1],  calling print_usage() within a contructor method in a classdef class causes errors in certain subsequent calls to that class, until a clear -c is called.

Using the following test class myclass:

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

  properties
    A = []
  endproperties
  methods
    function this = myclass(varargin)
      if nargin == 0
        #leave empty
      elseif nargin == 1
        this.A = varargin{1};
      else
        print_usage ();
      endif
    endfunction
  endmethods
endclassdef

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

The print_usage appears to actually execute okay (at least it displays the right help text), but for some reason it breaks subsequent attempts to assign a value to class properties. and only after a 'clear -c' does it return to normal.

adding in a breakpoint, stepping through print_usage and trying `A = myclass(1)` at each line, the "class not found" error occurs immediately after the line 62:

[text, format] = get_help_text (fullname);

as that's a compiled function I wasn't able to step through further, and I didn't see anything particularly obvious with a glance at corefcn\help.cc that would explain this.

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

Nicholas Jankowski <nrjank>
Project Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 nrjank (Submitted the item)
  • -email is unavailable- added by nrjank
  • -email is unavailable- added by nrjank
  •  

    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 StatusNone => Confirmed
        Release6.2.0 => dev
    2021-06-04 nrjank Carbon-Copy- => Added mtmiller
        Carbon-Copy- => Added siko1056

    Back to the top


    Powered by Savane 3.7