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

 
 

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

Submitted by:  Colin Macdonald <cbm>
Submitted on:  Thu 12 Jan 2017 12:09:18 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project Administrator
Thu 12 Jan 2017 06:41:13 PM UTC, comment #6:

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

Before this commit, we have:

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:

(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

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

Rik <rik5>
Project 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":

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

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 File(s):
   
   
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
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by cbm
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by cbm
  • -unavailable- added by cbm (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 12 Jan 2017 08:40:52 PM UTCjweStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Thu 12 Jan 2017 06:41:34 PM UTCcbmCarbon-Copy-=>Added jwe
    Thu 12 Jan 2017 05:57:53 PM UTCcbmAttached File-=>Added me.m, #39451
    Thu 12 Jan 2017 12:21:23 AM UTCcbmCarbon-Copy-=>Added rik
    Thu 12 Jan 2017 12:09:18 AM UTCcbmAttached File-=>Added display.m, #39444

    Back to the top


    Powered by Savane 3.1-cleanup1