Parseable output from Octave

[John W. Eaton]

On  4-Feb-2004, Oyvind Kristiansen <address@hidden> wrote:

| Some programs use Octave for calculations. An example of such programs, is
| SciCraft (former Zherlock, www.scicraft.org). SciCraft currently passes
| commands to Octave at stdin, and analyses output from stdout.
| 
| Currently, output from Octave is hard to parse, and to correct this, I
| have a proposition for a simpler variable formatting.
| 
| Problems for parsers are for instance:
| -"unnecessary" whitespace
| -information that occur at "random" places (like "Columns x to y ...")
| -there is no way of determining where the printing of variables end (so
| far, they've searched for "octave:")
| -in string arrays, one has no way of determining the difference between
| lineshifts and new row.
| 
| My patch tries to fix this.
| 
| Note: a new internal variable, machine_readable=true|false (defaults to
| false), will turn the feature.

How much different is this from "format none"?

I'm not sure that I'm really intersted in a patch like this, because
it means that there is yet another format state that will need to be
handled for new data types.

Also, from the point of view of external applications that want to
exchange data with Octave, it seems that it would be more efficient
and reliable to do that in some binary format so that you eliminate
the overhead of converting to and from ASCII and parsing.

If a binary format is not what you want, then I think it might be
better to consider using some standard form of markup instead, and
rather than overloading the pr-output functions, I would probably want
to provide the markup output as part of the load/save functionality.

But even then, I think we need to know that there will only be a need
for *one* such markup language, since we already have more than enough
I/O file formats to deal with for the load/save functions.

jwe