[bug #45833] support load/save of classdef objects

--===============6711402595229124277==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

UGxlYXNlIHVzZSB0aGUgYnVnIHRyYWNrZXIgdG8gcG9zdCB1cGRhdGVzIHRvIGEgYnVnIHJlcG9y
dC4gIFRoZSBtYWlsaW5nIGxpc3QgaXMgaW50ZW5kZWQgYXMgYSByZWFkLW9ubHkgbm90aWZpY2F0
aW9uIHN0cmVhbS4gIEluZm8gcG9zdGVkIHRvIHRoaXMgbWFpbGluZyBsaXN0IGFkZHJlc3Mgd29u
J3QgYXBwZWFyIGluIHRoZSB0cmFja2VyIGRhdGFiYXNlIHdoZXJlIGl0IGlzIG1vc3QgdXNlZnVs
LgoK

--===============6711402595229124277==
Content-Type: MULTIPART/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; BOUNDARY="8323329-861021530-1783656697=:2891249"
Content-Disposition: inline

--8323329-861021530-1783656697=:2891249
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

Follow-up Comment #104, bug #45833 (group octave):=0A=0AProposal: implement=
 reading of Matlab v7.3 (HDF5) MAT-files, reusing the=0Abug #45833 MCOS sub=
system code=0A=0AThis started with a LinkedIn post. William Garrow publishe=
d a small Python=0Alibrary, mat73-reader (https://github.com/WilliamGarrow/=
mat73-reader), that=0Apulls Matlab table objects out of v7.3 files, and the=
 discussion turned to=0Awhether Octave could read these files natively. I w=
ent to see what that=0Awould take, and it turns out most of the hard part i=
s already in the dev=0Atree: the MCOS subsystem handler from bug #45833.=0A=
=0AI would like to implement the v7.3 read path (load only; save can come=
=0Alater) as a new ls-mat73.cc in liboctinterp/load-save, and I want to mak=
e=0Asure I am not colliding with work in flight -- comments #89 and #93 her=
e=0Aname v7.3 as a next step.=0A=0AWhat I have verified so far against Matl=
ab-generated files (the twin -v7 /=0A-v7.3 test fixtures from the matio pro=
ject), using a from-source build of=0Athe default branch:=0A=0A* The FileWr=
apper__ metadata blob behind #subsystem#/MCOS ref 0 in a v7.3=0A  file has =
the same layout read_filewrapper() already parses for v5:=0A  version 4, th=
e name table, and the eight region offsets all parse=0A  cleanly.=0A=0A* Th=
e (1,6) uint32 object header is the same [0xDD000000, ndims, dims...,=0A  o=
bject id, class id] array that load_mcos_object() takes. The same=0A  varia=
ble saved as -v7 and as -v7.3 carries identical six words.=0A=0A* Object da=
tasets are marked with MATLAB_class and MATLAB_object_decode=3D3=0A  attrib=
utes, so detection needs no magic-number sniffing.=0A=0A* Current behavior =
of plain load() on a v7.3 file on default: it falls=0A  through to the Octa=
ve-HDF5 reader and returns the internal reference=0A  pool as junk variable=
s (a mangled "__refs_" plus one-letter names),=0A  warns "unknown datatype"=
 for every cell, and returns tables as=0A  unexplained uint32 arrays. Only =
the explicit -v7.3 option produces the=0A  "not yet implemented" error. So =
today these files load silently wrong=0A  rather than failing.=0A=0APropose=
d scope for a first patch:=0A=0A* format detection: a v7.3 MAT-file has the=
 128-byte text header=0A  ("MATLAB 7.3 MAT-file", version 0x0200) plus the =
HDF5 signature at=0A  offset 512, which cleanly separates it from Octave's =
own HDF5 format=0A  and from foreign HDF5 files;=0A=0A* an attribute-driven=
 reader for the standard classes: numeric including=0A  the compound real/i=
mag complex encoding, logical, char=0A  (MATLAB_int_decode), cell (object r=
eferences), struct (groups,=0A  MATLAB_fields ordering), sparse (data/ir/jc=
 groups with MATLAB_sparse),=0A  and empties (MATLAB_empty);=0A=0A* subsyst=
em wiring: dereference #subsystem#/MCOS into a Cell and hand it=0A  to the =
existing subsystem_handler unchanged, so classdef objects behave=0A  exactl=
y as they do for v5 -- reconstructed when the class exists in=0A  Octave, w=
arning plus metadata otherwise;=0A=0A* tests from small Matlab-generated fi=
xtures, cross-checked against their=0A  -v7 twins so both readers must agre=
e.=0A=0AQuestions before I start:=0A=0A1. Nithin: is any of this already un=
derway on your side? Happy to align=0A   with your design, split the work, =
or stay out of the way.=0A=0A2. Does a plain Matlab-compatible reader confl=
ict with the longer-term=0A   idea of consolidating on an HDF5-based supers=
et format? I read it as a=0A   prerequisite rather than a conflict, but wou=
ld rather check before=0A   writing code.=0A=0A3. Any preference between a =
new ls-mat73.cc and extending ls-hdf5.cc?=0A=0AEnvironment: default branch =
built from source on Ubuntu 24.04, HDF5=0A1.10.10.=0A=0A=0A    ____________=
___________________________________________=0A=0AReply to this item at:=0A=
=0A  <https://savannah.gnu.org/bugs/?45833>=0A=0A__________________________=
_____________________=0AMessage sent via Savannah=0Ahttps://savannah.gnu.or=
g/=0A
--8323329-861021530-1783656697=:2891249
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCalBw+QAKCRCqLAuaBUf3
Tq5iAQCHt2cSgTFnN+O7vl6peSeZJPKqrlMoSfcRj5OoSYEVzwEAkjEO61sc/C1O
msAhUiriURycGMLPsrscBWV56+klKgM=
=YrAj
-----END PGP SIGNATURE-----

--8323329-861021530-1783656697=:2891249--



--===============6711402595229124277==--