Zipped octave file formats and octave core and default file formats

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Zipped octave file formats and octave core and default file formats

David Bateman-3
Dear All,

At the request of John, I am moving a discussion we were having to the
maintainers list... I recently implemented gzipped file formats that
allows all octave file formats, including matlab file but excluding hdf5
files, to be saved gzipped using zlib. The files can easily be unzipped
with "gzip -d". This is controlled by the "-z" flag to the save command.
At the same type I added support for the Matlab v7 miCOMPRESSED format,
so the majority of matlab v7 files (ie. those not using miUTF16 or
miUTF32 formats) can be loaded and even saved.

However, this implementation raises a question of how to treat the issue
of defining the octave core and default file formats. At the moment
these are defined by the variables octave_core_file_format and
default_save_format. The Matlab v7 format can be defined here as this is
a real new file format, but the other compressed formats are just the
old file formats run through zlib and are use like "save -binary -z
...". Whereas the variables octave_core_file_format and
default_save_format are defined as a single string without the "-".

There are three basic ways we could add the capability to define a
compressed file format for the core and default save formats, these being

1) Add a new variable for core and default formats to store the options
to use

2) Add new file formats like "zipped-binary"

3) Change the meaning and probably the name of octave_core_file_format
and default_save_format so that they are the options to use to save
rather than a file format. That is "binary" becomes "-binary" and zipped
files might be defined like "-binary -z" in the core and default file
options variable (whatever they are called)

The first two options have the advantage of being backward compatible,
but both involve rather crufty changes to load-save.cc to allow them to
work. The third option is NOT backward compatible but allows a cleaner
implementation, and so I propose the third solution as the best one to
pursue. However, I'd like comments on this beforehand, especially from
those that actually use these options...

Regards
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary


Reply | Threaded
Open this post in threaded view
|

Re: Zipped octave file formats and octave core and default file formats

Dmitri A. Sergatskov
David Bateman wrote:
...
> 3) Change the meaning and probably the name of octave_core_file_format
> and default_save_format so that they are the options to use to save
> rather than a file format. That is "binary" becomes "-binary" and zipped
> files might be defined like "-binary -z" in the core and default file
> options variable (whatever they are called)
>

Yes.

Since those variables normally used in things like startup files,
I would expect the incompatibility impact would be minimal.


> Regards
> David
>

Dmitri.
--


Reply | Threaded
Open this post in threaded view
|

Re: Zipped octave file formats and octave core and default file formats

Quentin Spencer
Dmitri A. Sergatskov wrote:

> David Bateman wrote:
> ...
>
>> 3) Change the meaning and probably the name of
>> octave_core_file_format and default_save_format so that they are the
>> options to use to save rather than a file format. That is "binary"
>> becomes "-binary" and zipped files might be defined like "-binary -z"
>> in the core and default file options variable (whatever they are called)
>>
>
> Yes.
>
> Since those variables normally used in things like startup files,
> I would expect the incompatibility impact would be minimal.

I agree with this as well. I suspect that any user who knows enough to
have set these variables to something (likely in .octaverc as Dmitri
suggests) won't be too inconvenienced by making minor updates, and the
changes will be more or less transparent to every one else.