Skip to content

MATLAB reopens S2's merged saves (M9), with the truth committed - #149

Merged
ww-mw merged 1 commit into
mainfrom
m9-merged-saves-read-back
Oct 18, 2026
Merged

ww-mw merged 1 commit into
mainfrom
m9-merged-saves-read-back

Conversation

@ww-mw

@ww-mw ww-mw commented Oct 18, 2026

Copy link
Copy Markdown
Member

M9 is the last MATLAB read-back of the 2026-10-13 save-fidelity plan. The question: since S2 (#143), an edited entry of a binary dictionary is saved as its original bytes, with only the parts the edit changed written from the model. Does MATLAB R2027a (27.1.0.3409468 Prerelease) open those saves and read every entry as it should?

What was asked

test/parity/matlab/m9_merged_saves.mjs makes the saves through core's public API, as a host does: it makes the node active, calls session.editProperty, and saves with session.serializeSource, one file per edit. The saves cover every compressed-binary .sldd under test/fixtures and test/parity/artifacts (31 files), plus a copy of 11 of them as an earlier core save left them. In those copies, 1x1 cells are spelled Dimension="1*1", which MATLAB reads as the same value, so the merge writes something different from writing the entry whole. In each file it takes one entry of each kind (the class, plus complex, sparse, empty or N-D for plain values), preferring one whose merge differs from a whole write, and makes these edits:

  • a rename;
  • a Description edit, where the class has one;
  • a nested edit, where it is cheap: a bus element's Description, or a struct field.

probe_m9_merged_reopen.m opens only files in $M9_OUT: the saves and copies of the fixtures. Nothing is saved; every dictionary is closed with discardChanges and closeAll('-discard'). Each save is checked three ways:

  1. Every unedited entry must read as it does in the original: same class, isequaln, and the same fullsig (wbcompare.m's leaf-by-leaf signature).
  2. The edited entry must read as the original with the same edit made in MATLAB (getValue, set, setValue, getValue). A rename is compared with the original value under the old name.
  3. The save must open and read with no error or warning.

What MATLAB read

There are 266 cases. Core refuses one edit itself (the Description of pTall, an encoded value it can show but not write), so MATLAB was asked about 265 saves covering 220 entries.

  • 255 of 255 saves whose original MATLAB can open read exactly as the original. 212 of them open with no warning. The other 43 give only the warnings their original gives too:
    • params.sldd references a common.sldd that is not in the tree;
    • the Fleet and Vehicle classes of object_props_binary.sldd are not in the tree.
  • In 41 of those saves the merged entry differs from what writing it whole would give, so the kept bytes and the newly written parts were both read by MATLAB.
  • MATLAB cannot open arch_binary.sldd, compressed.sldd or object_array_binary.sldd, which make-fixtures.mjs writes by hand, so their 10 saves are not checked against anything. Their saves do not open in MATLAB either.
  • Not a merge issue: MATLAB's own rename (entry.Name = new) also writes the new name into the value's Name property, for a Simulink.VariantBank and for the fixtures' MyGadget (5 cases). Core's rename leaves the value unchanged. M9 compares a rename with the original value, and every save matches it; the difference is recorded as sameAsMatlabEdit.
  • One entry, hexobj_binary.sldd's anonAlias, holds an anonymous function handle, which is never equal to another (not even when the same file is read twice). It is checked on class and fullsig only, and the truth says so.

No case was read wrongly, and there is no source change.

The test

test/parity/m9MergedSaves.truth.test.ts remakes every save from source and checks that each is still the one MATLAB was asked about: the SHA-256 of the chunk (with the edited entry's LastMod masked) and of the other parts. It also checks that MATLAB's answers are as above. It fails when a binary fixture appears that the truth does not name. A fixture the truth names that is missing from the tree is skipped, and the skip is reported. To refresh the truth, re-run the two halves as the probe's header says. A README row has been added.

rm -rf dist && npm run build leaves dist unchanged. npm run verify is green: 295 test files passed, 1 skipped; 10175 tests passed, 27 skipped.

…t read

M9, the last MATLAB read-back of the 2026-10-13 save-fidelity plan: does
MATLAB R2027a open the saves S2 makes of an edited binary dictionary entry,
the entry's bytes with only the edited parts written from the model, and read
every entry as it should?

m9_merged_saves.mjs makes the saves through core's API. In every
compressed-binary .sldd under test/fixtures and test/parity/artifacts, and in
a copy of each as an earlier core save left it (1x1 cells spelled
Dimension="1*1", so that the merge differs from writing the entry whole), one
entry of each kind is renamed, has its Description set, and where it is
cheap has a bus element's Description or a struct field edited. Each edit
goes through session.editProperty and is saved by serializeSource into a file
of its own. probe_m9_merged_reopen.m had MATLAB open each save and a copy of
its original. Every unedited entry must read as in the original (class,
isequaln, fullsig), and the edited one as the original with the same edit
made in MATLAB, with no error or warning.

Of 265 saves (31 fixtures and 11 earlier-save copies, 220 entries), every
save whose original MATLAB can open reads as that original does: 212 with no
warning, and 43 with only the warnings the original gives too (params.sldd
names a common.sldd that is not in the tree, and two of
object_props_binary.sldd's classes are missing). In 41 of them the merge
differs from writing the entry whole. MATLAB cannot open the three fixtures
make-fixtures.mjs writes by hand, so their 10 saves are not held to anything.
MATLAB's own rename also writes the new name into a VariantBank's or
MyGadget's Name property. Core's rename does not; M9 holds a rename to the
original value.

m9MergedSaves.truth.test.ts makes the same saves from source and asks that
each is still the one MATLAB was asked about, and that MATLAB's answers are
as above.
@ww-mw
ww-mw merged commit 38c20de into main Oct 18, 2026
4 checks passed
@ww-mw
ww-mw deleted the m9-merged-saves-read-back branch October 18, 2026 21:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant