bugGNU Octave - Bugs: bug #60806, Usability enhancement - include...

 
 

bug #60806: Usability enhancement - include usage instructions in files generated by save

Submitter:  Tasos Papastylianou <tpapastylianou>
Submitted:  Mon 21 Jun 2021 10:47:34 AM UTC
   
 
Category:  Interpreter Severity:  1 - Wish
Priority:  1 - Later Item Group:  Feature Request
Status:  Need Info Assigned to:  None
Originator Name:  Tasos Papastylianou Open/Closed:  * Open
Release:  * 6.2.0 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 06 Jun 2024 04:08:47 PM UTC, comment #3: 

Randomly bumped onto this old bug of mine. @Nik, sorry for not having replied previously.

> Is the suggestion here that that particular header detail should be part of the default output?


Yes

> I assume that would make no difference when 'load'ing the data, since it's already ignoring the ## header.


Yes; the suggestion is for 'cosmetic' reasons only.

> I assume the only headaches might be to those that are parsing the data with something other than load


In a way, yes, but I think this misses the mark. Yes, if someone wanted to parse this file using their own bespoke parser, they could probably do it. The main issue here is users (typically newbies, but also non-newbies coming from matlab) will likely see this file and not be able to instantly recognise it's a file that should be loaded.

In UX terms, it lacks the necessary affordances that would hint to a user this is something that can/should be 'loaded' (as opposed to a file with a .mat extension which instantly suggests it's a loadable file).

Therefore, a header here would serve as a visual affordance to the user who opens this file that it's something that should be loaded, rather than 'parsed'.

You might argue that the stackoverflow post posted in the first comment here is an outlier, but, anecdotally, I've seen this happen a few times to people new to octave.

Tasos Papastylianou <tpapastylianou>
Tue 13 Dec 2022 10:24:18 PM UTC, comment #2: 

looking through old 'Need Info' bugs.  Is the suggestion here that that particular header detail should be part of the default output?

I assume that would make no difference when 'load'ing the data, since it's already ignoring the ## header.

I assume the only headaches might be to those that are parsing the data with something other than load, although I note that the current header that lists version and date isn't necessarily a fixed string, as the ver and date can change, but it is a fixed 'structure' that would be easy to parse.

If there's no interest in modifying the default headers, probably worth closing this as a won't fix.

Nicholas Jankowski <nrjank>
Group Member
Tue 22 Jun 2021 09:06:45 PM UTC, comment #1: 

Try 'help save_header_format_string'.  There is already an internal variable that can be set by the user to be the header for text files.

This works for me:


curr_hdr = save_header_format_string ();
new_hdr = strcat (...
"# This data-containing file has been generated via the octave 'save' command.\n",
"# Use the 'load' command to add its contents to a new session.\n",
"#\n",
curr_hdr);
save_header_format_string (new_hdr);
x = pi;
save -text tst.var x


Rik <rik5>
Group administrator
Mon 21 Jun 2021 10:47:34 AM UTC, original submission:  

This feature request is inspired by this question on stackoverflow: https://stackoverflow.com/questions/68056408/how-to-get-specific-data-drom-text-in-octave

Effectively, one of the more subtle differences between octave and matlab, is how the 'save' command works:

 • matlab generally results in the creation of a binary file with the '.mat' extension, unless otherwise specified (which is uncommon).

 • octave does not enforce a particular extension, and defaults to 'text' mode

This creates an odd situation, where a textfile containing octave data, which has been created via the 'save' command in octave, seems like an arbitrary text file to the user, who then tries to write code to parse it, and it's not obvious that it can simply be 'loaded'.

From a usability point of view, it might be worth including in the comment-header of that file a small addition, effectively letting the user know that this is a file generated by the 'save' command and can be loaded in octave using the 'load' command.

In other words, instead of, say:


# Created by Octave 6.2.0, Mon Jun 21 11:35:12 2021 BST <tasos@tasos-lenovo>
# name: a
# type: scalar
1


# name: b
# type: scalar
2


change this to, say:


# This data-containing file has been generated via the octave 'save' command.
# Use the 'load' command to add its contents to a new session.
#
# Created by Octave 6.2.0, Mon Jun 21 11:35:12 2021 BST <tasos@tasos-lenovo>
# name: a
# type: scalar
1


# name: b
# type: scalar
2


Tasos Papastylianou <tpapastylianou>

 

(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 nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by tpapastylianou (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-29 rik5 Priority5 - Normal 1 - Later
        Severity3 - Normal 1 - Wish
    2021-06-22 rik5 StatusNone Need Info

    Back to the top

    Powered by Savane 3.14-f13d.
    Corresponding source code