octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: restructuring load-save


From: John W. Eaton
Subject: Re: restructuring load-save
Date: Thu, 20 Nov 2003 11:02:53 -0600

On 20-Nov-2003, David Bateman <address@hidden> wrote:

| Ok, I saw this as a second step in the progression. The reason, I suggested
| it the way I did was so that there was as little disturbance to the existing
| code as possible at the outset and when the code was validated, then the
| existing load/save functionality could also be moved to the new scheme.

OK.  I think the first step would be to split the functions up.  But
we could start by moving the code with the if-elseif blocks to
ov-base, then split it up if that seems like a simpler or more
reliable process.

| I'd assumed that the type was already loaded. For ascii files the 
| "# name:" field of the file would could the name of the type. A lookup
| on the name in oct->type_name() would then find the corresponding type and
| thus the appropriate load function. If the type isn't loaded an error would
| occur. 

I also assumed that we already had the type installed in the
interpreter.  My point was that you can't just write

  do_octave_binary_load (ostream& os, ...)
  {
    octave_value v;
    v.octave_binary_load (os);
  }

because you'll end up in the octave_base_value code.  You have to
start out by reading enough of the file to know what type you are
about to read next, create an object of that type, then use it for
dispatching.

| For the octave binary format the problem is different. At the moment there
| is a char in the file that defines the type of the next variable
| 
| 1 -> scalar
| 2 -> real matrix
| 3 -> complex scalar
| 4 -> coplex matrix
| 5 -> <nothing>
| 6 -> range
| 7 -> string
| 
| So to maintain compatiability what I'd propose is that 1-4,6,7 keep there
| current definitions and type 5 becomes any type that uses the new scheme
| to load data (user or existing methods). In this case the following data
| is
| 
| int N;
| char type_name[N];
| 
| We can then use the same scheme as for the ascii files to get the appropriate
| load function.

OK, I think this would be possible, but I think I would rather change
the format so that all types are handled the same.  The format has a
version number in the header, so I think it is OK to change the format.

I'd prefer to have the current version of Octave only reading the
current file formats plus provide a conversion utility.  This keeps
the internals of Octave a bit cleaner while still offering the ability
to handle old formats.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]