bugGNU Octave - Bugs: bug #60130, Loading ranges stored in...

 
 

bug #60130: Loading ranges stored in "-binary" format fails

Submitter:  Rik <rik5>
Submitted:  Fri 26 Feb 2021 11:21:30 PM 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:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 01 Mar 2021 04:41:15 AM UTC, comment #5: 

Thanks Markus for fixing this.  I'm surprised that it was so fundamental.  Confirming this is now fixed and closing report.

Rik <rik5>
Group administrator
Sat 27 Feb 2021 03:19:16 PM UTC, comment #4: 

The arguments for the range constructor are in a different order than the one used in the binary file format. Maybe that let to a mistake.
Should be fixed in this changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/f91ff3f7f5dc

Markus Mützel <mmuetzel>
Group administrator
Sat 27 Feb 2021 12:26:52 PM UTC, comment #3: 

Simpler steps to reproduce this bug with Octave 7.0.0:

t = 1:5;
save("t.mat", "-binary", "t")
clear t
load("t.mat")


After the last step only the first element is recovered (t=1).

Different result if the range doesn't start at 1:

>> t = 2:5;
>> save("t.mat", "-binary", "t")
>> clear t
>> load("t.mat")
>> size(t)
ans =

   0   0


Re-titling report to describe the root of the original issue.

Markus Mützel <mmuetzel>
Group administrator
Sat 27 Feb 2021 12:01:49 PM UTC, comment #2: 

I did the same with a build from the stable branch and the file loads differently:

>> hg = load("tst6.2.ofig");

>> hg.s_oct40.children(1).properties.xtick
ans =

     1    15    29    43    57    71    85    99   113   127   141   155   169   183   197   211   225   239   253   267   281   295


So, I retract my previous idea.
There seems to be a regression on the default branch when loading files in "-binary" format.

Markus Mützel <mmuetzel>
Group administrator
Sat 27 Feb 2021 11:52:39 AM UTC, comment #1: 

Inspecting the content of the the .ofig file, I see the following:

>> hg = load("tst6.2.ofig");
>> hg.s_oct40.children(1).properties.xtick
ans =     1


So, according to the file content, there should be only one tick along the x-axis. IIUC, Octave dev is loading that file correctly.
But there are also hints that there should be a lot more ticks:

>> size(hg.s_oct40.children(1).properties.xticklabel)
ans =

   24    5


If there is an issue, it probably occurred when the file was saved.
I thought that the "xticklabel" property has to be a cell array of strings. But a string array seems to be ok, too. Maybe it has something to do with that?

Which commands were used to create the original figure and save the .ofig file?

Markus Mützel <mmuetzel>
Group administrator
Fri 26 Feb 2021 11:21:30 PM UTC, original submission:  

To reproduce:


hgload tst6.2.ofig


There should be a series of labels along the x-axis, but there is only the first one.

Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50931:  tst6.2.ofig added by rik5 (125KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5 (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-03-01 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2021-02-27 mmuetzel StatusNone Ready For Test
        Operating SystemGNU/Linux Any
    2021-02-27 mmuetzel CategoryPlotting Interpreter
        Summaryhgload on dev does not reproduce a figure correctly saved with 6.2 Loading ranges stored in "-binary" format fails
    2021-02-26 rik5 Attached File- Added tst6.2.ofig, #50931

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code