Repository navigation
Writers keep what was read or refuse it: no [object Object], MATLAB's 1x1 cell, and host empties that keep their class - #147
Merged
Conversation
…it in a binary dictionary
A text dictionary whose value, at an entry, a struct field or a cell element, is a JSON
object MATLAB never writes ({"foo": 1}, {}, or a class marker with no class such as
{"_array_class": null, ...} or {"_object_class": null, ...}) opened as a double scalar
holding the object. Its row showed String() of it, "[object Object]", with an editor and no
warning, and every XML writer wrote it into a double's spelling,
<P Name="Value" Class="double">[object Object]</P>. MatWriter wrote it as 0 in a cell
stream: the hex of a cell that also holds a sparse array, and the text save of an edited
N-D cell. This was MatlabVariableNode's own String() writer tail, the counterpart of the
two that C-205 removed from DataNode.
MATLAB R2027a opens such a file and reads no value from it. It reads a 1x0 double at an
entry, the struct without the field, and a 0x0 char in a cell (measured on dictionaries
generated from typed_text.sldd).
Under the 2026-10-18 rulings (group 1: refuse what the writers cannot spell; theme 1: warn
and show what was read):
- MatlabVariableNode._unshapedObject() marks an untouched scalar that holds the object it
was read as (parseScalar's last arm).
- Its row shows the JSON it holds, cut at 60 characters, as a summary with no editor:
<{"foo":1}>. This includes the row of an object's property and of a Simulink.Parameter's
Value.
- One part-unreadable warning per entry names the first such object and its path, and how
many there are (new unshapedValue.ts, taken by SlddNode.parse as it takes the other
per-entry records).
- serializeXml refuses it with DataNode._unspellable's MatWriteError, naming the entry and
the path, as the property writer already refused the same object.
- _buildVarObject marks its variable as one MatWriter refuses, so the cell stream is
refused, or falls back to the XML, which refuses the object there.
- A text save and a copy still write it back as read.
Tests: new test/unshapedObjectValue.test.ts (25). Before the change, 18 failed for the
expected reasons: the rows showed [object Object] and had editors, there were no warnings,
and the XML was written instead of refused. The 7 that passed are controls: the untouched
text save is byte-identical; copies, a sibling edit and a paste into a text dictionary keep
the object as read; the property and Value refusals are unchanged; and a spellable entry
is still written. No existing test changed.
…does
MATLAB writes no Dimension on a 1x1 cell in a binary dictionary, at any place: an entry's
Value, a cell element, a struct field, an object's property, and a string's saveobj cell.
This holds for every cell tag in the MATLAB-written binary dictionaries this project reads
(the fixtures, the parity artifacts and the corpus). Every other cell, 1xN, Nx1 or empty,
has one. In a text dictionary it writes "_dimensions": [1, 1], which core already does.
MatlabVariableNode._serializeCellXml wrote Dimension="1*1" on every 1x1 cell it wrote: an
entry's Value, each cell element under it, and a struct field of an entry. That covered a
save that rebuilt an entry, a removal that left one element, {7} typed in, and a paste or
copy into a binary dictionary. DataNode._cellXml, the property writer, already left it out.
MATLAB reads both spellings as the same 1x1 cell, so nothing read back wrong; the cost was a
rewritten tag nobody edited. The writer now applies _cellXml's rule: no Dimension when the
dims are [1, 1] and there is one element. The binary reader takes the absence as 1x1 at an
entry and as 1xN in a cell or a struct.
New MATLAB fixture (R2027a): test/fixtures/make_cell1x1.m writes cell1x1_binary.sldd and
cell1x1_text.sldd, a 1x1 cell at every place a cell goes, with 1x2, 2x1 and 0x0 controls.
cell1x1.truth.json is MATLAB's reading of four files: its own file, the text twin, a copy
with Dimension="1*1" added to its 17 such cells (the old spelling), and core's regeneration
of the file (make_cell1x1_core.mjs). All 15 entries read back isequal in all four. It also
records the cell tags of each file.
Tests: new test/cellOneByOneDimension.test.ts (27). Before the change, 17 failed, each
because the writer spelled Dimension="1*1" where MATLAB's file has none: 11 entries
regenerated, the whole chunk, a removal to one element, {7} typed in, a paste from the text
twin, a copy, and the tags in MATLAB's reading of core's file. The 10 that passed are the
fixture's own rule in both formats, four control entries (0x0, 1x2, 2x1, the Widget's
properties), an edit inside a 1x1 cell (the merge keeps the file's tag), core's read-back of
the new spelling, the text writers' [1, 1], and MATLAB's read-back of all four files.
Existing tests changed, each only where it pinned Dimension="1*1" on a 1x1 cell:
- dimsWriters (7 lines) and emptyClassedValues (3 lines): the writer's expected output, and
hand-built inputs that are written back "as read", now spell MATLAB's tag.
- binaryEditKeepsUntouched (9 tests) and binarySaveKeepsUnedited (2): each used the
writers' respelling of cellarr_binary.sldd (11 of its 14 entries) or of cases.sldd's
cellNest as its proof that a part was written from the model. After the change, 7 of them
failed on that proof. The other 4 still passed, but no longer failed when every edited
entry is written whole (a mutant with no merge). They now read those fixtures as an
earlier save left them: every such cell is given Dimension="1*1", which MATLAB reads as
the same value. Their claims and expected bytes are otherwise unchanged. The no-merge
mutant now fails the same 45 tests as before the change. #143's three cell mutants still
fail the cellNest case: positional pairing, no cell origins in _buildCellChildren, and no
recordReadElements in cellValue. The no-origin test also takes the three cell fixtures as
an earlier save left them, beside the others, so that its "merged > 30" floor still holds.
It is 36 now; without them it would be 21, and it was 73 before the change.
The save-fidelity census counts differing leaves, and a cell's open tag is never a leaf, so
its totals do not move here; entries changed by a regeneration go from 402 to 365 over the
fixtures, the parity artifacts and the corpus, and every file's reading and every text save
are unchanged. Its one remaining Dimension leaf is not a cell: a 1x0 char at an entry,
written as a 0x0 char. That is another writer and is not changed here.
…ctionary, and refuse what has no spelling there
A text dictionary was given a lossy spelling for three kinds of empty:
- a host's string or function-handle {_type, _emptyDims} was written [] at an entry and at
an object's property, which reopens as a double 0x0, and as handed in at a struct field and
in a cell, which MATLAB reads back as a char 0x0 in a cell, a double 1x1 at a property and,
at a field, as a struct without the field. Its copy out of a binary dictionary was [];
- a binary dictionary's N-D empty was written [] or '' at a property or a field and as its
bare Matrix(...) header in a cell (MATLAB drops the third extent); an N-D char '' at every
place, an entry too; an N-D enumeration '', [] or a dims-only bag;
- past an int32, all of these were written so too. Only a numeric or logical entry was
refused.
MatWriter.textEmptySpelling now spells or refuses each, at every place, as MATLAB R2027a
reads them back:
- an empty string: the String bag MATLAB writes for strings(0,3), which it reads back as the
string it is at an entry, a cell, a field and an object's property;
- an N-D numeric, logical or char empty: its MAT stream, which MATLAB reads back with its
class and size at every place (its own writer writes the 0x0 of the class). Past an int32
the stream cannot state the extent, and the save is refused, as at an entry;
- an empty function handle, at any rank: refused. MATLAB refuses a function handle at an
entry, a cell, a field and a Parameter's Value, and reads its own spelling at an object's
property back as a 1x1 handle. So is an N-D empty enumeration: MATLAB reads every spelling
back without its size, and the bag it writes for a non-empty one crashed R2027a on open
for all six empty variants tried. An N-D string's too, which MATLAB refuses in a cell or a
field.
The refusal is a MatBudgetError with the new reason 'no-spelling', named by the node as
'past-int32' is: "Cannot write "h": h.f is an empty function handle (1x0), and a text
dictionary has no spelling of it that MATLAB reads back as it is. Nothing was written." The
paste goes through; its save and its copy refuse.
MatWriter.emptyDimsHeldForm now hands a host's string or function-handle empty to that
spelling, so a copy carries its class and size. A text dictionary's own such value
(heldByTextDictionary now records every {_type, _emptyDims}) is written as read, so a save
that edits nothing writes the same file; before, one at an entry or an object's property
was rewritten [].
MATLAB truth (R2027a 27.1.0.3409468, 2026-10-18): probe_lossy_empties_readback.m asks about
17 values at 5 places, MATLAB's own text and binary spellings and 17 candidate spellings
(the core half, lossy_empties_readback.mjs, writes them from core's output). The answers are
in lossy_empties_readback.truth.json, and MATLAB's binary dictionary of the values is
test/fixtures/lossy_empties_readback_binary.sldd. The probe opens only files it writes.
Tests: new test/lossyEmptiesReadback.test.ts (6) pastes every value of MATLAB's binary
dictionary, and a host's forms, at each place, into a text dictionary through core's API,
and grades each save against the truth: written in a spelling MATLAB read back with the
value's class and size, and reopened so here, or refused where MATLAB read back none. Before
the change, 5 failed: 38 binary rows (N-D empties lossy, past-int32 ones unrefused), 22
host rows (written [] or as handed in), 10 copies (written [] or as another value), the
function handle written where it is refused, and the unedited file rewritten. Each of the
eight arms of the change, removed alone, fails it.
Existing tests changed, each where it pinned the output this removes:
- emptyClassedValues: "a host's string or function handle ... is written there as before"
becomes the String bag at each place, the refusal of a function handle's, and the unedited
file at all four places; the N-D char Ch3 (0x0x2) is its stream, reopened as char 0x0x2,
where it was '' (char 0x0), and it shows <0x0x2 char> when pasted.
- textEmptyReadback: it grades every spelling against MATLAB's answers; it now reads the new
truth file too, and grades N-D empties for class and size instead of skipping them.
Left as they are: an object array's N-D empty (with the rank-2 object-empty call the
maintainer holds), a String bag past an int32 (unmeasured), and the binary writer's spelling
of a host string empty.
Brings in 1.41.0 and #146. The only conflicts were two dist source maps for MatlabVariableNode, which were regenerated with rm -rf dist && npm run build.
…rray element of one shows as before Two parts of G1-OBJTAIL were pinned by no test (PR #147's review, round 1): - SlddNode.parse takes the unshaped-value record before each entry is read. A paste records an object of no MATLAB shape as a read does, and nothing takes the record then. Without that take, the next dictionary opened, in any session, warned on its first entry about the pasted entry's path: '"gadget" holds {"foo":1} at e5.f, which is not a value MATLAB writes; it is shown as read.' New test: paste one into a text dictionary, open an untouched one, and expect no warning. - MatlabVariableNode._unshapedObject asks that the scalar holds the very object it was read from (_rawInput). An element of a hand-edited numeric array, [1, {"foo": 1}], holds the object without being read from it, and this item leaves that family out. Without the check, its row arr(2) showed <{"foo":1}> with no editor, where it shows [object Object] with one, as before. New control test: arr(2) and inCell{2}(2) as before, with no warning. Each new test fails with its guard removed, for that reason (the warning above; the row's text and editor), and passes here. No source change; dist rebuilt, unchanged.
The binary writer leaves Dimension out only for a 1x1 cell of one element (MatlabVariableNode._serializeCellXml: rank 2, one row, one column, one element). Three of those four parts were pinned by no test (PR #147's review, round 1). With any one of them dropped, the suite passed, but a hand-edited text cell lost its Dimension when written as XML or pasted into a binary dictionary: - a [1, 1] of two elements, which then reopens as a 1x2 in a cell or a struct; - a [1, 1, 1]; - a [2, 1] or a [0, 1] of one element. New control tests hold those four inputs and a true 1x1 of one element, both written from the text dictionary's model (regenerateEntryXml) and pasted into a binary dictionary and saved. Each part removed fails them, naming its input, and they pass here. No source change; dist rebuilt, unchanged.
…onary as MATLAB does PR #147's empties commit (dd51bee) handed a host's empty string, {_type: 'string', _emptyDims}, on from MatWriter.emptyDimsHeldForm as the binary reader's empty. The text writer spells that as the String bag, as intended. But the binary writers build an object's property and a Simulink.Parameter's Value from the same form, so a paste into a binary dictionary changed there too, with no test and no disclosure (review, round 1): - an empty string at either place went from Class="double" Dimension="0*0" to Class="string" Dimension="0*3"/>; - an empty function handle at either place went from a double 0x0 to the refusal FH-PASTE gives at an entry, a cell and a field. MATLAB R2027a was asked. The new probe_host_string_empties_binary.m reads the dictionaries its core half, host_string_empties_binary.mjs, saves through core's API: a host's form, the String bag and the binary reader's empty, at five places, each in a dictionary of its own. The answers are in host_string_empties_binary.truth.json: - the bare Class="string" Dimension="r*c"/> reads back as a double 1x1 at an object's property. At an entry, a cell or a field it cannot be read at all ("Invalid string returned."); - the String bag, which the binary writers spell as MATLAB's own saveobj envelope, reads back as the string it is at an entry, a cell, a field and an object's property; - at a Parameter's Value, every spelling reads back as a double 0x0. MATLAB refuses an empty string there. So emptyDimsHeldForm now hands a host's empty string on as the String bag: - a text dictionary is given the same bytes as before, the String bag; - at an object's property, a binary dictionary is given the envelope, which MATLAB reads back as the string. dd51bee wrote the bare tag (a double 1x1), and main wrote a double 0x0; - at a Parameter's Value, MATLAB reads the envelope back as the double 0x0 it read of main's spelling, and core reopens it as the string, as in a text dictionary; - a copy carries the bag, so a copy pasted into a binary dictionary as an entry is the envelope too, which MATLAB reads back as the string. It was the bare tag, which MATLAB cannot read, and [] on main. The function handle's refusal at a property and at a Value stays (group 1). Tests: new test/hostStringEmptiesBinary.test.ts (6) grades each save against the truth. Without the new arm, 3 fail: the property's spelling (MATLAB reads a double 1x1), the Value's spelling (the bare tag) and the copy's (MATLAB cannot read it). With dd51bee's source reverted as well, the function handle's test fails too: it is written, and reads back as a double 0x0. A truth check and a control pass in both states; the control pins the node writer's spelling at an entry, a cell and a field, which this does not reach. A read-only walk of 477 corpus and repo files (544,777 entries) finds rows, copies, text forms, warnings and untouched saves identical to the PR's head, and its XML differs only where two runs of the head differ. Left as it is, since before PR #147, and a follow-up: the node writer (MatlabVariableNode.serializeXml) still writes a host's empty string pasted as an entry, a cell element or a struct field with the bare string tag, which MATLAB cannot read. So do the binary writers, at every place, for the binary reader's empty string, the form core reads that tag back as.
…ne is refused Two parts of 27dd229's string arm in MatWriter.emptyDimsHeldForm were pinned by no test, and either could change without a test failing (PR #147's review, round 2): - The String bag's `_dimensions` is the host's dims without trailing 1s (effectiveDims), as every other class is written. Written with them, a host's `{_type: 'string', _emptyDims: [0, 3, 1]}` was `"_dimensions": [0, 3, 1]` in a text dictionary and `Dimension="0*3*1"` in the binary envelope, spellings MATLAB was never asked about, and it reopened as a 0x3x1. New tests, in a text dictionary at an entry, a cell, a field, an object's property and a Parameter's Value, and in a binary dictionary at a property, a Value and in a copy, take 0x3x1, 1x0x1 and 0x0x1x1. Each is graded as the string MATLAB reads back without the 1, or, at a text Value, where MATLAB reads every spelling back as a double 0x0, compared with the one without it. With `dims` in place of `d`, all 15 text cases fail, and the binary property fails on its first case. - The arm comes after the rank-2 return, so an N-D string is not handed on as a bag. A host's 0x0x2 and 0x3x2 string in a text dictionary is refused at all five places, a Parameter's Value too (lossyEmptiesReadback's host list had no N-D string, and its places leave out the Value). The refusal names it "a 0x0x2 string". With the arm hoisted above the return, the Value is written as the N-D bag, which MATLAB reads back in no text spelling, and the other four refusals call it "a 0x0x2 char": all 10 fail. The header of probe_host_string_empties_binary.m still described the first head of PR #147, which handed the string on as the binary reader's empty at a property and a Value. It now says the String bag goes there, spelled as MATLAB's saveobj envelope. No source changes, and dist is unchanged.
This was referenced Oct 18, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three writer follow-ups from group F's reviews (agenda follow-ups 1, 3 and 4), one commit each, plus a merge of main. The DECIDED 2026-10-18 (group G) block says "items 1–4 are built under the rulings they already fall under". For these three items those rulings are:
1. An object of no MATLAB shape is shown as its JSON, and refused in a binary dictionary (0b03151)
Ruling. Follow-up 1: "
[object Object]at an entry or a field (#136).{_array_class: null},{_object_class: null}or{foo: 1}at an entry or a struct field opens as an opaque value showing[object Object]. It is writtenClass="double">[object Object]."What was wrong. A hand-edited text dictionary can hold an object of no MATLAB shape:
{foo:1},{},{_array_class:null|0,...},{_object_class:null,...},{_type:'double'}with no_value, or{_array_type:'Bogus'}. At an entry, a struct field, a cell element or an Architectural Data Constant, such a value:[object Object], with an editor and no warning;Class="double">[object Object];As a property or a Parameter's Value, the XML was already refused (C-205), but the row still showed
[object Object].Root cause (line numbers at 71378b5).
MatlabVariableNode.parseScalar(MatlabVariableNode.ts:4054), last arm: any non-null object becomes a double scalar holding the object.NodeClassMap.parseValue(NodeClassMap.ts:178) sends it there when no marker matches, and a falsy_array_classor_object_classmatches none._formatScalar(:796) andserializeXml(:2904) →_serializeScalarXml(:3082) →formatFloatXmlboth end informatMatlabNum, which isString(). The struct and cell writers call the child'sserializeXml, so all places share this tail.Fix.
unshapedValue.ts.unshapedTextgives the JSON the file holds, cut at 60 characters and shown in angle brackets (<{"foo":1}>). As for every summary, the angle brackets mean the row has no editor. A value JSON cannot spell falls back to its keys, so it never throws. The module also keeps a first-and-count record and builds the warning from it.[object Object].SlddNode.parsegives onepart-unreadablewarning per entry:"x" holds {"foo":1} at x.f, which is not a value MATLAB writes; it is shown as read.serializeXmlrefuses it with C-205'sDataNode._unspellable, aMatWriteError:Cannot write "x": x.f is ..., which a binary dictionary has no spelling for. Nothing was written._buildVarObjectmarks it unwritable, so the MAT stream is refused too.MATLAB truth (R2027a, on dictionaries generated under /tmp from a repo fixture). MATLAB opens every file with no error. It reads
[ ](1x0 double) at an entry and''(0x0 char) for a cell element, and it drops the field from a struct. So MATLAB reads no value from such an object, and the row shows what the file holds.Tests. New
test/unshapedObjectValue.test.ts, 25 tests. Each one appends its cases to a real text fixture, ingests it, writes the XML throughserializeEntryToXml, then copies into a binary fixture and saves withsession.serializeSource.[object Object]and have an editor;warningsis undefined;expected undefined to be 'MatWriteError'because the XML was written; the N-D cell's text save returned no error.Left out.
[1,{foo:1}],[1,null],[1,'a']) is still written through the numeric array writer's element tail. That is a family of its own, and MATLAB needs measuring for each spelling first.doubleand 1x1. That matches the class MATLAB reports at an entry, and changing them would reach the Constant gate and the MAT paths.{_type:'double',_value:5}as a property is still written5.0by the property writer (pre-existing).MatWriter.textForm(pre-existing).vscode: only the pin bump. The row arrives as a summary with no editor, the warning uses the existing
part-unreadablechannel, and the refusal reachesBinarySlddEditorProvider's catch as a namedMatWriteError, as C-205's do.2. A 1x1 cell is written with no Dimension in a binary dictionary, as MATLAB does (f2a7d40)
Ruling. Follow-up 3: "A 1x1 cell is written
Dimension="1*1", which MATLAB omits (#135). It is the last Dimension difference in the save-fidelity census: 414 differences before W1 and W2, 1 after."What was wrong. When a binary dictionary's 1x1 cell was written from the model, the writer gave it
Dimension="1*1". That covers an entry's Value, a nested cell element and a struct field. MATLAB writes no Dimension on any of them.Root cause.
MatlabVariableNode._serializeCellXml(MatlabVariableNode.ts:3213at 71378b5) writesDimensionon every non-empty cell.DataNode._cellXmlhandles properties and raw cells, and it already omits the Dimension of a 1x1 cell.Fix.
_serializeCellXmlnow follows_cellXml's rule: no Dimension when the dims are[1,1]and there is exactly one element. The readers already read a cell with one element and no Dimension as 1x1. The text writers are unchanged, because MATLAB writes_dimensions [1, 1]there too.MATLAB truth.
Dimension="1*1"is in an entry that core wrote.test/fixtures/make_cell1x1.m(R2027a) writescell1x1_binary.slddandcell1x1_text.sldd. Together they hold a 1x1 cell at every place, plus controls.Dimension="1*1"added, and core's regeneration. All 15 entries areisequalin all four (cell1x1.truth.json). So the new spelling reads as the same value, and so do older saves.Tests. New
test/cellOneByOneDimension.test.ts, 27 tests.Dimension="1*1"where MATLAB has none. The failing cases:{7}typed in;Existing tests changed. Each one pinned
Dimension="1*1", the output this removes:test/dimsWriters.test.ts, lines 811, 844, 848, 955, 957, 992 and 1043. These are expected writer output, or hand-built "binary dictionary's own" inputs that the test says are written back as read.test/emptyClassedValues.test.ts, "a binary dictionary's 0x0 logical in a cell": its input and its two expectations.test/binaryEditKeepsUntouched.test.ts(8 tests, plus the no-origin test, which now also opens the three cell fixtures as older saves) andtest/binarySaveKeepsUnedited.test.ts(2 rename tests). These 11 used the writers' 1x1 respelling as their proof that a part had been written from the model. A new helper,openOlderSave, now opens the fixture as an earlier core save left it, withDimension="1*1"added. MATLAB reads that file as the same value, so the proof still holds. Of the 11, 7 failed after the change. The other 4 still passed but had lost their proof: the no-merge mutant no longer killed them. With the helper they are killed again.Left out. A 1x0 char at an entry is still regenerated without its Dimension, so it reads back as 0x0. MATLAB writes it
<P Name="Value" Class="char" Dimension="1*0"/>. This is the census's actual lastDimensiondifference; the agenda credited that difference to the 1x1 cell, which the census cannot see at all. It is a candidate follow-up.vscode: only the pin bump. vscode writes no XML, and no vscode file pins
Class="cell" Dimension="1*1". S2's kept-parts gate will see fewer respelled parts.3. Empty strings and N-D empties keep their class and size in a text dictionary, and what has no spelling there is refused (dd51bee)
Ruling. Follow-up 4: "Lossy host empties (#133). A host's string or function-handle
{_type,_emptyDims}at an entry or an object property is written[], which reopens as double 0x0 (as before group F). An N-D empty past int32 at a property, field or cell is still written lossy; only the entry place is refused."What was wrong.
{_type,_emptyDims}):[], which reopens as double 0x0;[].[]or''at a property or field, and as the bareMatrix(0,2,2)header in a cell, which MATLAB reads back as 0x2;''at every place;'',[]or as a bag holding only its dims;[]on save.Root cause (line numbers at 71378b5).
MatWriter.emptyDimsHeldForm(MatWriter.ts:1620) returned null for string and function_handle. SoMatlabVariableNode.serializeValuewrote them from their dims ([]), andtextFormleft them as handed in.textEmptySpelling(:1558) returned undefined for those classes and for rank 3 and above.heldTextSpelling(:1500) then fell through to the older tails.Fix, in
MatWriter.ts.textEmptySpellingnow spells or refuses each kind:strings(0,3);MatBudgetErrorreason'no-spelling'. The node names it as it names'past-int32':... and a text dictionary has no spelling of it that MATLAB reads back as it is.emptyDimsHeldFormnow passes string and function-handle empties on in the header form, so a copy keeps their class and size.heldByTextDictionarynow records every{_type,_emptyDims}as the text dictionary's own, so a save with no edits writes the same file.index.ts: the comment onreasonnames the new value.MATLAB truth (R2027a 27.1.0.3409468; the probe opens only files it writes). The probe is committed as
test/parity/matlab/probe_lossy_empties_readback.m, with its core halflossy_empties_readback.mjs, its answerslossy_empties_readback.truth.json(85 self rows, 85 candidate rows), and MATLAB's binary dictionarytest/fixtures/lossy_empties_readback_binary.sldd._enum_valuebag around an empty stream crashed R2027a on open in 6 of 6 variants.Tests. New
test/lossyEmptiesReadback.test.ts, 6 tests. It pastes MATLAB's binary values and the host forms at each place, then grades each save against the truth: the value is either written in a spelling MATLAB read back with its class and size and that core reopens the same way, or refused where MATLAB read back no spelling.Existing tests changed. Each pinned the output this removes:
test/emptyClassedValues.test.ts:{_type, _emptyDims}is written there as before, at each place" now expects the String bag, the refusal of a function handle, and the unedited file at all four places;''(char 0x0) until now, is its stream, reopens as char 0x0x2, and shows<0x0x2 char>when pasted.test/textEmptyReadback.test.tsalso reads the new truth file. It now grades N-D empties for class and size, where it used to skip them ("an N-D one is as it was").Left out.
Class="string" Dimension="0*3"/>for a host string empty is not changed: that is a binary write, not this item.vscode: only the pin bump. vscode already shows a core refusal from a save, a copy or a drag by its message, and no vscode code switches on
reason. After the bump:[];Merge of main (93b8427)
The branch started at 71378b5. Since then, main has gained the 1.41.0 bump (#144) and #146, which also edits
MatlabVariableNode.ts. The source merged cleanly. The only conflicts were two dist source maps forMatlabVariableNode, and those were regenerated withrm -rf dist && npm run build.Gates
At each item commit, dist was regenerated and committed, and
npm run verifywas green:At head 93b8427:
rm -rf dist && npm run buildleaves the tree clean.npm run verifyis green. Test files: 293 passed, 1 skipped. Tests: 10,043 passed, 27 skipped. That is main's 9,782, plus 78 here, plus A complex value with a -0 imaginary part shows +0i, and cell literals take signs and imaginary-first members as MATLAB does #146's 183. The smoke, pack, leak and browser checks are all OK.DEX_READBACKS_CORPUS=<parity corpus> npx vitest run test/parity/readbacks.truth.test.ts: 6 of 6 passed (also 6 of 6 at each item commit).Live MATLAB tests (
DEX_MATLAB_CMD="mw -using Bmain matlab", R2027a, each file run alone):None of these tests builds an unshaped object, writes a cell or holds an empty string, function handle or N-D empty. For each item, the MATLAB read-back is that item's committed truth file.
Review rounds (842b58e, 72a7f1e, 27dd229, d44bb11)
Round 1.
_rawInputcheck for a hand-edited array element;Class="double" Dimension="0*0"to a bareClass="string" Dimension="0*3"/>. An empty function handle there became refused.probe_host_string_empties_binary.mandhost_string_empties_binary.truth.jsongrade a host's form, the String bag and the binary reader's empty, at five places, each in a dictionary of its own.emptyDimsHeldFormnow hands a host's empty string on as the String bag:test/hostStringEmptiesBinary.test.ts(6). A read-only walk of 477 corpus and repo files (544,777 entries) is identical to the earlier head, apart from run-to-run XML noise.Round 2. The correctness review found two parts of the new string arm unpinned.
_dimensionsdrops trailing 1s, as every other class does. Writingdimsfordfails all 15 new text cases, plus the binary property;Left as it is (since before this PR), a follow-up: the node writer (
MatlabVariableNode.serializeXml) still writes a host's empty string pasted as an entry, a cell element or a struct field with the bare string tag, which MATLAB cannot read. So do the binary writers, at every place, for the binary reader's empty string.Gates at the head (d44bb11)
cde901a(An object whose text dictionary holds its properties beside its class is saved as read, in every class #145 and A complex value with a -0 imaginary part shows +0i, and cell literals take signs and imaginary-first members as MATLAB does #146):rm -rf dist && npm run buildleaves the tree clean;npm run verifyis green: 294 test files passed and 1 skipped; 10,136 tests passed and 27 skipped;DEX_READBACKS_CORPUSset: 6 of 6;dimsfordfails 2 tests in the three empty-spelling files, and hoisting the arm fails 1. Unmutated, those files pass 20 of 20.Implements the maintainer's 2026-10-18 rulings (group G).