bugGNU Octave - Bugs: bug #59737, end keyword not passed to...

 
 

bug #59737: end keyword not passed to overloaded subsref function within custom classdef

Submitter:  None
Submitted:  Sun 20 Dec 2020 05:01:19 AM UTC
   
 
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 6.1.0
Operating System:  * Any Fixed Release:  9.1.0
Planned Release:  9.1.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 11 Feb 2024 03:34:05 PM UTC, comment #20: 

Yes, if the layout is satisfactory I'm considering this closed. If anyone wants to suggest other related doc improvements they can be made here or in a new report as appropriate.  Thanks for the help.

Nicholas Jankowski <nrjank>
Group Member
Sun 11 Feb 2024 02:29:45 AM UTC, comment #19: 

The anchoring seems to be working really well now.  That's a big improvement. Is this bug ready to be closed now?

Rik <rik5>
Group administrator
Sat 10 Feb 2024 03:00:51 AM UTC, comment #18: 

make some changes to the anchor links in the category lists. The pdf was fine but the doc browser was jumping you below the title (title scrolled above the visible screen) with their current window.  general online suggestion was to just have the anchor at the front of the line before the heading/title etc, which works and no errors/warnings.  fine now in both graphics prop and keyword pages.
https://hg.savannah.gnu.org/hgweb/octave/rev/fcf504e687c0

haven't played with other list layouts. I spent too long trying to figure out why my links to individual properties were fine in pdf but not working in the doc browser like mentioned in my last comment (links to functions or keywords just jump you to the top of the page, not down to the item, so the 'list of keyword links' don't actually take you anywhere. Then i realize all links in the help doc was doing that, even in sections i never touched. 

then i went back to 8.4.0 on my windows machine and realized they were doing the same thing there. so I'll make another report about that.

Nicholas Jankowski <nrjank>
Group Member
Thu 08 Feb 2024 05:57:38 PM UTC, comment #17: 

yeah, I realized thankfully it's just a comment, so in the end it's about as low a concern as it gets.

I may still play with the layout a bit, as I thought the current look was fine for html display but the pdf is a bit of a mess.

actually, now it looks like only in the pdf do the list links jump you down to the actually term. in the html/online doc it jumps you to the top of the page.  but the graphics objects links work fine...  i can't see what's different right now, but will try to figure it out.

Nicholas Jankowski <nrjank>
Group Member
Thu 08 Feb 2024 04:24:56 PM UTC, comment #16: 


> it gave a suggestion to suppress that comma. pushed as

https://hg.savannah.gnu.org/hgweb/octave/rev/69f1135e44d2

This change works for me.

Rik <rik5>
Group administrator
Thu 08 Feb 2024 04:23:03 PM UTC, comment #15: 


> separately in the built grammar.texi I noticed that when expanding persistent (line 132 currently) it grabs the comments for properties too.  don't know how those macros work, should there be whitespace separators in


Your comment got cut off, but I see what you mean.  I think I messed with a long time ago to get it to work.  Basically, one can't use the 0x1D record separator between entries which then has a blank expansion because everything is a comment (preceded by @c Texinfo comment marker).  The hack is just to include it with the keyword above in op-kw-docs and realize that it will never be printed in output.

Rik <rik5>
Group administrator
Thu 08 Feb 2024 12:22:48 PM UTC, comment #14: 

looking at https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Cross-Reference-Parts.html

it gave a suggestion to suppress that comma. pushed as
https://hg.savannah.gnu.org/hgweb/octave/rev/69f1135e44d2

will look at the general layout some more tonight.

separately in the built grammar.texi I noticed that when expanding persistent (line 132 currently) it grabs the comments for properties too.  don't know how those macros work, should there be whitespace separators in

Nicholas Jankowski <nrjank>
Group Member
Thu 08 Feb 2024 11:27:29 AM UTC, comment #13: 

Thanks, didn't realize the whitespace space within ref behaved that way. Probably explains why i. Was having a heck of a time getting it to "behave". was mainly using the online doc as render check. Will check the PDF later and try for a v2. I'm guessing the Graphics object property pages look similar. At least in HTML I thought the horizontally wrapped lists would be more compact. I guess could go back to the multicolumn table for those.

Re: anchor warnings - I actually left the anchors on the deftypefn with the warnings because its the only location that would jump the page to the line with the property title. Putting it below would jump it below the name cutting off the title. For some reason putting it above would make the link just jump to the top of the page (at first appearing not to work). maybe related to the other ref issues. Will check again

Nicholas Jankowski <nrjank>
Group Member
Thu 08 Feb 2024 05:04:42 AM UTC, comment #12: 

I fixed some Texinfo warnings and the @ref macro usage for FILE_ and _LINE_ in this changeset https://hg.savannah.gnu.org/hgweb/octave/rev/e1351a7cdc4d.

Note that the output is still a little strange.  If the @ref macro is not immediately followed by a character, such as a comma or a period, then Texinfo automatically inserts a comma.  Because the code is "@ref{...} | @ref{...}" the space triggers this automatic behavior and the result is "comma, space, bar".  Check the resulting octave.pdf to see what I mean.

I would switch to using commas to separate the keywords, or place each on its own line.  The PDF feels hard to read right now.

Rik <rik5>
Group administrator
Thu 08 Feb 2024 04:31:26 AM UTC, comment #11: 

added _FILE_ and _LINE_ keyword defs in
https://hg.savannah.gnu.org/hgweb/octave/rev/476a7ecc1f4c

and expanded the keyword page from a list into a full set of categorized @docstrings in
https://hg.savannah.gnu.org/hgweb/octave/rev/f1bf2e22a94f

then pointed the index expression page reference to end to it's definition in the list in
https://hg.savannah.gnu.org/hgweb/octave/rev/277c54607153


assuming i didn't miss anything with the docs, this is probably about ready to close. marking as ready for test.

Nicholas Jankowski <nrjank>
Group Member
Sat 03 Feb 2024 04:10:17 AM UTC, comment #10: 

It probably would have been clearer to say

  "When the lexer recognizes the _FILE_ and _LINE_ keywords, it returns character and numeric tokens, respectively, in..."

instead of

  "__FILE__ and _LINE_ are expanded character and numeric tokens in..."

John W. Eaton <jwe>
Group administrator
Sat 03 Feb 2024 03:50:04 AM UTC, comment #9: 

_FILE_ and _LINE_ are expanded character and numeric tokens in base_lexer::make_keyword_token in lex.ll, here:

http://hg.savannah.gnu.org/hgweb/octave/file/c96d0470a582/libinterp/parse-tree/lex.ll#l2837

John W. Eaton <jwe>
Group administrator
Sat 03 Feb 2024 03:20:18 AM UTC, comment #8: 

looking to add the keywords, i noticed that _FILE_ and _LINE_ are the only two that don't have docstrings. those don't seem to be defined in the same files as the others.  Since they're a bit obscure, it wouldn't be a bad idea to add them, something like:

_FILE_ expands to the name of the file that is being read or @code{stdin} if called from the command line.

_LINE_ expands to the current input line number of the function or file being executed.

I'm assuming it could get added to op-kw-docs, but the pattern there seems to need to refer back to the source, which doesn't seem to be oct-parse.yy like the others. looking around for _FILE_ and magic_file_kw, I got lost. :) if someone could provide a compass ?

Nicholas Jankowski <nrjank>
Group Member
Sat 03 Feb 2024 02:04:15 AM UTC, comment #7: 

also added notes to the subsref/subsasgn functions with
https://hg.savannah.gnu.org/hgweb/octave/rev/6fba256defcb

Nicholas Jankowski <nrjank>
Group Member
Fri 02 Feb 2024 05:32:03 PM UTC, comment #6: 

i noticed when playing with adding the keywords the first time i got an error when one was already defined.  if we wanted to keep the end docstring in the Indexing section, is there an alternative to @docstring{end} to include it in the keyword list even if it would be redundant?

Nicholas Jankowski <nrjank>
Group Member
Fri 02 Feb 2024 05:30:08 PM UTC, comment #5: 

i saw that too, went looking for it, and noticed the same. that seems to be where most of the other keywords are defined, so i guessed it was just a legacy artifact. will clip it when doing other changes.

expanding that page from a list to actual docstrings seems like a reasonable fit.  I'll look at expanding that.

Nicholas Jankowski <nrjank>
Group Member
Fri 02 Feb 2024 04:53:40 PM UTC, comment #4: 

I'm not sure why the "// END is documented in op-kw-docs." comment is in pt-eval.cc.  That seems like a mistake, as it is documented in pt-eval.cc and there is no documentation for "end" in op-kw-docs.

But anyway, maybe we should add @DOCSTRING tags for "end" and all keywords documented in op-kw-docs to the grammar.txi file?

John W. Eaton <jwe>
Group administrator
Fri 02 Feb 2024 01:53:30 PM UTC, comment #3: 

Yes, this should be documented. The question is where.

'help end' produces a keyword description, but it seems end and most other keywords don't actually appear anywhere I can find in the online documentation.  (And adding @DOCSTRING{end} add it to the end of https://docs.octave.org/latest/Index-Expressions.html, which i believe is the first time it's topically introduced, generates a bunch of errors because the @seealso's point to other keywords not in the documentation. Apparently that doesn't work.)  For now I've added the following to the end docstring:

  Programming notes:
       1. The ‘end’ keyword cannot be used within ‘subsref’, ‘subsasgn’,
          or ‘substruct’ for manual indexing operations.

       2. For custom classes, ‘end’ can be overloaded to enable use in
          class indexing expressions with a function definiton such as:

                  function last_index = end (obj, end_dim, ndim_obj)
                    if (end_dim == ndim_obj)
                      last_index = prod (size (obj)(end_dim:ndim_obj));
                    else
                      last_index = size (obj, end_dim);
                    endif
                  endfunction

          For more information see Object Oriented Programming.

pushed to stable as:
https://hg.savannah.gnu.org/hgweb/octave/rev/cf43680cd221

Will look at getting the keyword docstring into Indexing Operations, where the Programming Notes should cover this issue.
Inability to use end should probably also be mentioned within the subs___ functions.  Will look at whether it also makes sense to add something somewhere under Object Oriented Programming.

Nicholas Jankowski <nrjank>
Group Member
Sun 20 Dec 2020 11:02:38 PM UTC, comment #2: 

Please change this bug report to a request to change documentation. I agree this bug as reported is not a bug. Is it possible to add a sentence like:

If you would like to use the end keyword with subsref you will also need to overload end.

and/or

add end to the see also list

See also: subsasgn, substruct, end.

The reason I overloaded every size function I could think of was to see if one of them was being used by end. There was no hint in the documentation, the syntax highlighter or from my google searches (I was not searching overload end. I was searching my problem.) that I could overload end.

The working as expected class with overloaded end:


classdef cantuseend
  properties
    value;
  endproperties
  methods
    function obj=cantuseend(a)
      obj.value=a;
    endfunction
    function obj=subsref(a,s)
      if strcmp(s.type,"()")
        obj=cantuseend(subsref(a.value,s));
        s
      else
        obj=builtin('subref',a,s);
      end
    endfunction
    function display(a)
      disp(a.value);
    endfunction
    function lastindex=end(a,k,n)
      lastindex=size(a,k);
    endfunction
    function varargout=size(a,varargin)
      nout=nargout;
      if nout<=1
        varargout={size(a.value,varargin{:})};
      else
        varargout=nthargout(1:max(nargout,1),@size,a.value,varargin{:});
      end
    end
  endmethods
endclassdef


Anonymous
Sun 20 Dec 2020 07:43:40 PM UTC, comment #1: 

This is not an error, it is the expectected behaviour of END when used as an index expression. You will get the same result in Matlab (I just tried it with Matlab 2020a). When used in an index expression, END acts as a method that is called on the object being indexed. You have more information here:

https://es.mathworks.com/help/matlab/matlab_oop/object-end-indexing.html

Fernando <tutissanalio>
Sun 20 Dec 2020 05:01:19 AM UTC, original submission:  

Problem Description


The end keyword is not passed to an overloaded subsref function.

How to reproduce


Copy the following into cantuseend.m


classdef cantuseend
  properties
    value;
  endproperties
  methods
    function obj=cantuseend(a)
      obj.value=a;
    endfunction
    function obj=subsref(a,s)
      if strcmp(s.type,"()")
        obj=cantuseend(subsref(a.value,s));
        s
      else
        obj=builtin('subref',a,s);
      end
    endfunction
    function display(a)
      disp(a.value);
    endfunction
    function varargout=size(a,varargin)
      nout=nargout;
      if nout<=1
        varargout={size(a.value,varargin{:})};
      else
        varargout=nthargout(1:max(nargout,1),@size,a.value,varargin{:});
      end
    end
    function v=columns(a)
      v=columns(a.value);
    endfunction
    function v=rows(a)
      v=rows(a.value);
    endfunction
    function v=numel(a,varargin)
      v=numel(a.value,varargin{:});
    endfunction
    function v=ndims(a)
      v=ndims(a.value);
    end
    function v=length(a)
      v=length(a.value);
    end
  endmethods
endclassdef


At the command prompt type:

q=cantuseend(rand(4,1))
q(2:4)%works as expected
q(2:end)%Expected the above output got 1 by 0 empty result
q(end)%returns the first element not the last

I am printing what is in the sub-reference structure every time the function is called. For the second call I get an empty subs for the third call I get the number one within subs.

Suggested Fixes


Pass through a token which can be interpreted as end - even better if this token can be interpreted by builtin functions.

Use the size method (or another method, document which one) of the classdef object to convert end into the correct index. Give an error if the size method has not been overloaded.

Raise an error telling the user end is not supported for custom objects and tell the user to pass the last index of the object instead of end. This can't currently be done within an overloaded subsref function as the input looks valid. Without an error being thrown this bug could result in undetected incorrect results and code that is very difficult to debug because without looking at each output and finding this bug the code will look correct.



Anonymous

 

(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 rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by tutissanalio (Posted a comment)
  •  

    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 group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-02-11 nrjank StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 9.1.0
    2024-02-08 nrjank StatusIn Progress Ready For Test
    2024-02-03 nrjank StatusConfirmed In Progress
        Planned ReleaseNone 9.1.0
    2020-12-21 mmuetzel CategoryOctave Function Documentation
        Item GroupIncorrect Result Documentation
        StatusNone Confirmed
        Summaryend keyword not passed to oveloaded subsfef function within custom classdef end keyword not passed to overloaded subsref function within custom classdef

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code