edfcore 0.5.17 → 0.5.19
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 +44 -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.5.
|
|
112
|
+
export declare const VERSION = "0.5.19";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,50 @@ 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.5.19
|
|
10
|
+
|
|
11
|
+
- **Added** the table on `diagnostics.md` that says which calls take `strict`. Eleven functions in
|
|
12
|
+
two columns, and nothing read it. `strict-decision.test.ts` covers what `strict` does — the info
|
|
13
|
+
exemption, the four always-fatal conditions — and `strict-reaches.test.ts` how far into a file it
|
|
14
|
+
reaches. Which entry points accept it at all was prose.
|
|
15
|
+
- It is the kind of table that goes stale silently, in both directions. A function that grows a
|
|
16
|
+
`ParseOptions` parameter joins the left column without anyone editing the page, and a caller
|
|
17
|
+
reading the right column concludes it cannot be made strict. A function whose options type is
|
|
18
|
+
narrowed leaves the left column the same way, and a caller passing `strict` to it gets one that is
|
|
19
|
+
quietly ignored — an option that type-checks, runs, and does nothing.
|
|
20
|
+
- The two columns are checked by different means, because they are different claims. The six on the
|
|
21
|
+
left are **driven**: each is given a file with a real non-`info` defect — a non-standard reserved
|
|
22
|
+
field for the header three, a malformed TAL for the annotation three — and each must throw
|
|
23
|
+
`EdfFormatError` carrying that code under `strict: true` and collect the same diagnostic without
|
|
24
|
+
it. That is the only way to catch a `strict` that is accepted and dropped.
|
|
25
|
+
- The five on the right are checked **structurally**, out of `src/`: each function's options
|
|
26
|
+
parameter is resolved to its declared type, the `extends` and `&` chain is followed, and `strict`
|
|
27
|
+
must not be reachable through it. A behavioural check cannot prove that negative — passing an
|
|
28
|
+
option a signature does not declare is a compile error, not a runtime one. The same resolver is
|
|
29
|
+
then pointed at the left column, which is what keeps the two halves honest.
|
|
30
|
+
|
|
31
|
+
## 0.5.18
|
|
32
|
+
|
|
33
|
+
- **Added** the unscalable signal `diagnostics.md` walks through, run from the throw to the read.
|
|
34
|
+
That page uses one file for three separate arguments and prints values for all three — the
|
|
35
|
+
`strict` transcript, the callout headed "`errors > 0` does not mean the file failed to read", and
|
|
36
|
+
the `EdfScalingError` block at the bottom. They are the same signal seen from three angles, and
|
|
37
|
+
none of the three was run.
|
|
38
|
+
- The `strict` transcript is four fields off a thrown error and a fifth off the diagnostic inside
|
|
39
|
+
it: `DEGENERATE_DIGITAL_RANGE digitalMinimum 504 1`, then `EDF+ additional specification 5`. The
|
|
40
|
+
`504` is the sharpest of them — the byte at which signal 1's `digitalMinimum` field starts in a
|
|
41
|
+
two-signal file, `256 + 2 x 120 + 8`, and the number a reader would take to a hex editor. It is
|
|
42
|
+
now asserted against that arithmetic as well as against the page. `error-fields.test.ts` checks
|
|
43
|
+
the fields exist and `spec-references.test.ts` that every diagnostic cites something; neither was
|
|
44
|
+
pointed at this file.
|
|
45
|
+
- "The error carries the whole `diagnostic` it would otherwise have recorded, so nothing is lost by
|
|
46
|
+
throwing" is checked by comparing what the strict throw carries against what the non-strict parse
|
|
47
|
+
of the same bytes collected.
|
|
48
|
+
- The callout is the part worth having pinned. It says `errors > 0` **and** `report.ok === false`
|
|
49
|
+
are both true of a file that reads perfectly, and tells the reader to gate on the thrown
|
|
50
|
+
`EdfError` instead — three values agreeing on one file, asserted in prose. All three are now read
|
|
51
|
+
off that file, alongside the other signal converting to eight finite microvolt values.
|
|
52
|
+
|
|
9
53
|
## 0.5.17
|
|
10
54
|
|
|
11
55
|
- **Added** the record onsets that quietly stop being true when a read is narrowed to a secondary
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED