edfcore 0.4.454 → 0.4.456
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 +35 -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.456";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,41 @@ 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.456
|
|
10
|
+
|
|
11
|
+
- **Added** a test for the line that divides the two kinds of failure inside `inspectEdf`: the
|
|
12
|
+
`if (!isEdfError(error)) throw error` at the top of its `catch`.
|
|
13
|
+
- A defect in the file is reported, never thrown — that is what triage is for, and it is well
|
|
14
|
+
covered. A mistake in the ARGUMENTS has to stay a throw, and nothing in the suite had ever
|
|
15
|
+
thrown a non-`EdfError` out of `parseHeader`, so the rethrow never ran. Replacing it with a
|
|
16
|
+
`return` failed nothing.
|
|
17
|
+
- The cost of losing it is specific. `EdfInspection` carries no field meaning "the arguments were
|
|
18
|
+
wrong", so a swallowed `RangeError` comes back as `ok: false` with a diagnostic list blaming
|
|
19
|
+
the file for a number the caller supplied.
|
|
20
|
+
- The reachable caller bug is a `ByteSource` reporting a `byteLength` past 2^53 — a hand-written
|
|
21
|
+
adapter over a paged API, or a `Content-Range` nobody checked. `assertByteSource` accepts it
|
|
22
|
+
because it is a number, and `parseHeader` refuses it because it cannot be a byte count. The
|
|
23
|
+
test asserts `isEdfError` is false on what comes back, since that is the predicate the
|
|
24
|
+
documented `catch` recipe branches on.
|
|
25
|
+
|
|
26
|
+
## 0.4.455
|
|
27
|
+
|
|
28
|
+
- **Fixed** a test that refused what it was named after by accident. `timeline.test.ts` listed
|
|
29
|
+
"the probes are out of order" among the arrays `buildTimelineFromProbes` must refuse, and its
|
|
30
|
+
probes were records 0, 3, 1 — whose LAST entry is record 1 rather than record 3 on a four-record
|
|
31
|
+
file. `assertProbeShape` checks the two ends before it checks the order, so that array was
|
|
32
|
+
refused with "received probes for records 0..1, but the start offset comes from record 0 and the
|
|
33
|
+
span ends at record 3", and the ordering loop underneath had never run once in the suite.
|
|
34
|
+
- The case now runs 0, 2, 1, 3: both ends correct, so nothing before the loop has anything to say
|
|
35
|
+
about it, and rising onsets throughout, so the monotonicity check that runs next cannot claim it
|
|
36
|
+
either. Deleting the loop outright now fails one test instead of none.
|
|
37
|
+
- Every case in that table now asserts the sentence its guard produces, not just `RangeError`.
|
|
38
|
+
Three different refusals share the class, so asserting the class alone proves only that SOME
|
|
39
|
+
guard fired — which is exactly how the case above drifted without anyone noticing.
|
|
40
|
+
- Added the case the loop must NOT refuse: four probes in order, one of them intermediate.
|
|
41
|
+
`assertProbeShape` documents intermediate probes as optional rather than unwelcome, and a loop
|
|
42
|
+
that refused every array of three or more would have passed the disorder case just as well.
|
|
43
|
+
|
|
9
44
|
## 0.4.454
|
|
10
45
|
|
|
11
46
|
- **Added** a test for `validateHeader`'s own `DATE_FIELDS_DISAGREE` check on the ordinary case:
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED