edfcore 0.4.510 → 0.4.512
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 +39 -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.512";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,45 @@ 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.512
|
|
10
|
+
|
|
11
|
+
- **Added** a read behind each of the four header-recovery diagnostics. When the header's numbers
|
|
12
|
+
disagree with the file, `parseHeader` recovers rather than refuses, and each recovery ends by
|
|
13
|
+
saying what a read will now do: which byte record 0 comes from, which records exist, which bytes
|
|
14
|
+
are never decoded. Every one of those is a claim about `decodeDigital` output, made in a module
|
|
15
|
+
that never calls it, and the existing tests stopped at the header fields the sentence mentions.
|
|
16
|
+
- The gap is not hypothetical for `HEADER_SIZE_MISMATCH`. A three-signal file declaring a 512-byte
|
|
17
|
+
header has the same `recordCount` under either size, because the arithmetic that produced it used
|
|
18
|
+
whichever size the reader used; what separates the two readings is which 1024 bytes come back as
|
|
19
|
+
record 0. The declared offset lands in the middle of the per-signal block and decodes to numbers
|
|
20
|
+
rather than to an error, so the test asserts the ramp the writer wrote — and asserts alongside it
|
|
21
|
+
that the declared offset would have given something else, or the first assertion proves nothing.
|
|
22
|
+
- `TRAILING_BYTES` and `PARTIAL_FINAL_RECORD` claim their bytes are never decoded and never padded
|
|
23
|
+
into existence. Both fixtures now write those bytes as `0x7F`, which decodes to 32639, a value
|
|
24
|
+
the sample ramp never produces — so "never decoded" is checked by looking for it in the output
|
|
25
|
+
rather than by trusting an offset. Reaching either by record number is refused, not returned.
|
|
26
|
+
- `TRUNCATED_FILE` says the missing records are not readable and will not be fabricated. The
|
|
27
|
+
surviving records read exactly as they do in the intact file, and the pair the header claimed is
|
|
28
|
+
an `EdfRangeError` rather than zeros.
|
|
29
|
+
|
|
30
|
+
## 0.4.511
|
|
31
|
+
|
|
32
|
+
- **Fixed** `physical-values.md` documenting the limitation 0.4.509 removed. Its note said a fifth
|
|
33
|
+
refusal condition exists, that the header calls it `DEGENERATE_PHYSICAL_RANGE`, and that
|
|
34
|
+
`toPhysical` "can't re-derive this one" so it throws `SCALE_UNAVAILABLE`. The last clause stopped
|
|
35
|
+
being true one release ago.
|
|
36
|
+
- The page's table now lists five conditions rather than four, so the fifth is documented where a
|
|
37
|
+
reader looks for it rather than in an aside below. Five rows, four distinct codes: two conditions
|
|
38
|
+
reach `DEGENERATE_PHYSICAL_RANGE`, which is why the table is of conditions.
|
|
39
|
+
- The table is not prose. `scaling-page-arithmetic.test.ts` parses these rows out of the page and,
|
|
40
|
+
for each, builds the signal and asserts `toPhysical` refuses it with the code in that row — so
|
|
41
|
+
the new row is checked by the same mechanism as the other four, and the page cannot describe a
|
|
42
|
+
refusal the library does not make. The order it claims is checked too: a channel that is both
|
|
43
|
+
log-transformed and unusably scaled is refused as the log-transformed one, which is the answer
|
|
44
|
+
that says something about the data rather than about the map.
|
|
45
|
+
- The note is kept, rewritten as history: what the two sides used to report, and why looking up
|
|
46
|
+
`SCALE_UNAVAILABLE` in `header.diagnostics` used to find nothing.
|
|
47
|
+
|
|
9
48
|
## 0.4.510
|
|
10
49
|
|
|
11
50
|
- **Added** the one claim every diagnostic makes at once, as a property test: `raw` quotes the
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED