bugGNU Octave - Bugs: bug #55519, shadowing built-in functions:...

 
 

bug #55519: shadowing built-in functions: incorrect results for which(), doc_cache_create()

Submitter:  Andrew Janke <apjanke>
Submitted:  Sat 19 Jan 2019 07:48:52 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.4.1 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 19 Jan 2019 11:16:37 PM UTC, comment #2: 

Ah, okay. Yep, dupe of bug #49434 and bug #43047.

Andrew Janke <apjanke>
Sat 19 Jan 2019 05:08:07 PM UTC, comment #1: 

I think these are duplicates of existing bugs.

which() always returns "built-in" for classdef objects.  This is wrong, but not particular to your datetime class.

The documentation for classdef objects is also not extracted correctly.  Try 'help inputParser' and you also get no documentation.

Rik <rik5>
Group administrator
Sat 19 Jan 2019 07:48:52 AM UTC, original submission:  

I've craeated a `datetime` classdef class and added it to the front of the Octave path so it shadows the built-in datetime() function.

Calling its constructor works correctly:


>> datetime
ans =
 19-Jan-2019 02:37:23
>> class(ans)
ans = datetime


But which() and get_help_text() give the wrong answer:


>> which datetime
'datetime' is a built-in function
>> get_help_text ('datetime')
ans =


And when I install the pkg package it's in, doc_cache_create() issues warnings:


>> pkg install https://github.com/apjanke/octave-addons-chrono/releases/download/v0.1.2/chrono-0.1.2.tar.gz
warning: doc_cache_create: unusable help text found in file 'calendarDuration'
warning: doc_cache_create: unusable help text found in file 'datetime'
warning: doc_cache_create: unusable help text found in file 'duration'


Educated-guess analysis:

On the documentation side, I think maybe this is because help_system::raw_help is looking in the symbol table first before looking in files, which prioritizes built-in functions over M-file functions? I think this might be incorrect, because it doesn't match the function invocation precedence.

In libinterp/corefcn/help.cc:


  std::string
  help_system::raw_help (const std::string& nm, bool& symbol_found) const
  {
    std::string h;
    std::string w;
    std::string f;

    bool found;

    found = raw_help_from_symbol_table (nm, h, w, symbol_found);

    if (! found)
      found = raw_help_from_file (nm, h, f, symbol_found);



Andrew Janke <apjanke>

 

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

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-19 rik5 StatusNone Duplicate
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code