edfcore 0.4.509 → 0.4.510
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +21 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
|
|
|
109
109
|
readonly reserved: 224;
|
|
110
110
|
};
|
|
111
111
|
/** Published package version. Kept in sync with package.json by a test. */
|
|
112
|
-
export declare const VERSION = "0.4.
|
|
112
|
+
export declare const VERSION = "0.4.510";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,27 @@ alone does not tell you whether you were affected.
|
|
|
6
6
|
edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
|
|
7
7
|
defect; those are called out below.
|
|
8
8
|
|
|
9
|
+
## 0.4.510
|
|
10
|
+
|
|
11
|
+
- **Added** the one claim every diagnostic makes at once, as a property test: `raw` quotes the
|
|
12
|
+
bytes `byteOffset` names. `EdfDiagnostic.raw` is documented as "those bytes as text, exactly as
|
|
13
|
+
written including padding" — the bytes AT the offset the same diagnostic reports — and it is the
|
|
14
|
+
only evidence a reader has that a diagnosis is about the field in front of them.
|
|
15
|
+
- It had gone wrong three times, three different ways, each found by eye rather than by a test:
|
|
16
|
+
0.3.26, where `NON_ASCII_HEADER_FIELD` quoted bytes contradicting its own claim; 0.3.68, where a
|
|
17
|
+
TAL diagnostic put the escaped message preview in `raw` and returned a 13-character string for
|
|
18
|
+
four bytes; and 0.3.73, where `PARTIAL_FINAL_RECORD` pointed into the data section while carrying
|
|
19
|
+
the record-count field's eight bytes. Nothing checked the pair, which is how one defect appeared
|
|
20
|
+
in three places.
|
|
21
|
+
- Both sides are damaged at random and checked, because they derive the offset differently: a
|
|
22
|
+
header field's comes from a fixed table, a TAL's is recomputed as
|
|
23
|
+
`headerByteLength + recordIndex * recordByteLength + signal.recordByteOffset` while the bytes are
|
|
24
|
+
sliced from a record buffer that starts at neither. Dropping the last term of that sum, or adding
|
|
25
|
+
one to a header field's offset, each fail the run.
|
|
26
|
+
- Roughly 15,000 diagnostics across 24 codes satisfy it today, and the run asserts the counts as
|
|
27
|
+
well as the property: a change that stopped producing diagnostics under damage would otherwise
|
|
28
|
+
pass by having nothing to check.
|
|
29
|
+
|
|
9
30
|
## 0.4.509
|
|
10
31
|
|
|
11
32
|
- **Fixed** `toPhysical` naming a different cause than the header for one class of unscalable
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED