bugGNU Octave - Bugs: bug #50035, OO @class/display.m: something is...

 
 

bug #50035: OO @class/display.m: something is wrongly caching inputname

Submitter:  Colin Macdonald <cbm>
Submitted:  Thu 12 Jan 2017 12:09:18 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 12 Jan 2017 08:40:52 PM UTC, comment #7: 

I pushed the following changeset:

  http://hg.savannah.gnu.org/hgweb/octave/rev/60cf700e04ef

It seems to be fixed for me, so I'm closing this report.

Thanks.

John W. Eaton <jwe>
Group administrator
Thu 12 Jan 2017 06:41:13 PM UTC, comment #6: 

I've bisected it to jwe's display rework (as you suggested)


changeset:   22906:9baa19102908
user:        John W. Eaton <jwe@octave.org>
date:        Fri Dec 16 00:10:27 2016 -0500
summary:     refactor display and disp functions (bug #49794)


Before this commit, we have:


octave:1> x = me(2)
input name is x
octave:2> y = me(3)
input name is y
octave:3> me(4)
input name is ans
octave:4> x
input name is x
octave:5> me(4)
input name is ans


And after that commit, it is as I describe below.

Colin Macdonald <cbm>
Thu 12 Jan 2017 06:01:12 PM UTC, comment #5: 

Two other notes:

1. I noticed is that "x=me(1); display(x)" and "display(me(2))" work correctly.  Its just when the implicit display call (no semicolon) is made that I see this bug.

2. On start-up I get this warning:

warning: function /home/cbm/.octavehg/share/octave/4.3.0+/m/general/display.m shadows a built-in function

Ok, off to try some bisecting.

Colin Macdonald <cbm>
Thu 12 Jan 2017 05:57:53 PM UTC, comment #4: 

Constructor attached, sorry about that.  (Its not crucial, same problem happens with "x = sym(1)" then "sym(2)" using the Symbolic pkg).

"clear inputname" inside display.m does not help: same problem.

I will try to bisect, although as I said I cannot compile too far back (because of a signbit compile problem with newish gcc).

I also noticed that the Interval pkg errors on display:


>> pkg load interval
>> x = infsup(1, 2);
>> x
error: Invalid call to display.  Correct usage is

(which might be related)

(file #39451)

Colin Macdonald <cbm>
Thu 12 Jan 2017 01:47:43 AM UTC, comment #3: 

Is there more in the directory @me besides display.m?  Like a constructor?  Could that be uploaded as well?

jwe also significantly reworked the display routines.  See


changeset:   22898:9baa19102908
user:        John W. Eaton <jwe@octave.org>
date:        Fri Dec 16 00:10:27 2016 -0500
summary:     refactor display and disp functions (bug #49794)


You might try using 'hg bisect' to discover when this stopped working.


Rik <rik5>
Group administrator
Thu 12 Jan 2017 01:09:42 AM UTC, comment #2: 

That, or somehow the inputname object is not being cleared between calls when it should be.  That is, somehow Octave is generating that list of input variable names ('x' and 'y' look like outputs to me, but I guess technically they are the variable names "input" to the function).  If Octave forgets to clear that object (is it a cell?), it will be hanging around from the previous call.

Do you get some kind of error message or result by putting "clear inputname" in the display(x) routine?  E.g.,

function display(x)
  x
  inputname
  disp(['input name is ' inputname(1)])
  clear inputname
endfunction

Dan Sebald <sebald>
Thu 12 Jan 2017 12:21:23 AM UTC, comment #1: 

The only functional change I see recently is 2892f62fb37cb9586f98c26948bf8683ddbb9833

Unfortunately I don't seem to be able to compile from back then :(

Rik, can you investigate?

Colin Macdonald <cbm>
Thu 12 Jan 2017 12:09:18 AM UTC, original submission:  

Suppose I have a simple class "@me" with the following simple "@me/display.m":


function display(x)
  disp(['input name is ' inputname(1)])
endfunction


With hg tip, I no longer get the empty string when I should, but rather some cached version:


>> me(2)       % correct
input name is
>> y = me(3)   % correct
input name is y
>> me(4)       % wtf!, should be blank
input name is y
>> x = me(5)   % correct
input name is x
>> me(6)       % should be blank
input name is x
>> me(7)       % should be blank
input name is x


If I make some random change to the file "@me/display.m" then it works again, until I display one that is assigned to a variable name.  This is why it looks like some caching problem to me.

I haven't yet bisected, but something in the last 6 months or so as I had previous "4.3.0+" versions working properly.

Colin Macdonald <cbm>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #39451:  me.m added by cbm (53B - application/vnd.wolfram.mathematica.package)
file #39444:  display.m added by cbm (64B - application/vnd.wolfram.mathematica.package)

 

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 cbm
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by cbm
  • -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 group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-01-12 jwe StatusNone Fixed
        Open/ClosedOpen Closed
    2017-01-12 cbm Carbon-Copy- Added jwe
    2017-01-12 cbm Attached File- Added me.m, #39451
    2017-01-12 cbm Carbon-Copy- Added rik
    2017-01-12 cbm Attached File- Added display.m, #39444

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code