edfcore 0.5.21 → 0.5.23
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 +47 -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.23";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,53 @@ 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.23
|
|
10
|
+
|
|
11
|
+
- **Added** the conformance report `validation.md` prints, printed. That page ends with a whole
|
|
12
|
+
program and the output it produces on one file: a header line, a summary line, two diagnostic
|
|
13
|
+
blocks, and two per-signal stat lines. `validate-page.test.ts` covers the code table higher up and
|
|
14
|
+
`validation-report.test.ts` the `report.ok` rule; the transcript — the thing a reader compares
|
|
15
|
+
their own terminal against — was prose.
|
|
16
|
+
- The stat lines are the reason it is worth running. They are not printed by edfcore at all: the
|
|
17
|
+
page composes them from `report.signalStats`, `getSignal` and arithmetic of its own, and the
|
|
18
|
+
paragraph under them is an argument built on the result. "The first channel uses half a percent of
|
|
19
|
+
the range its header declares, which is legal and lossy." "81,806 of its 153,600 samples fall
|
|
20
|
+
outside the range the header declares, so that declaration is wrong." A change to
|
|
21
|
+
`observedDigitalMin`, `outOfDigitalRangeCount` or `sampleCount` would leave the page arguing from
|
|
22
|
+
figures the library no longer produces.
|
|
23
|
+
- The snippet is now run rather than restated: the stat lines are built by the same expression the
|
|
24
|
+
page shows and compared against the page's own text character for character, along with the
|
|
25
|
+
summary line's `no errors, 4 diagnostics, 600 records and 650400 bytes read`.
|
|
26
|
+
- The fixture is built to the page's description and its geometry falls out of the transcript —
|
|
27
|
+
600 one-second records at 650,400 bytes is 1,084 a record, which is two 256-sample channels and a
|
|
28
|
+
30-sample annotation region, and 153,600 samples is 600 x 256. The one number that cannot be
|
|
29
|
+
derived is how many fall outside; that is read off the page and built into the sample generator,
|
|
30
|
+
which is what makes the count an assertion about the counter rather than about the waveform.
|
|
31
|
+
- The last sentence of the paragraph is checked too. "Any consumer that clamps to it returns
|
|
32
|
+
different numbers for this file than edfcore does" — a read returns the bytes as written, at
|
|
33
|
+
-150..150 outside the declared -100..100, and `clampToDigitalRange` returns something else.
|
|
34
|
+
|
|
35
|
+
## 0.5.22
|
|
36
|
+
|
|
37
|
+
- **Added** the scrolling table on `large-files.md`, measured. `large-files-cost.test.ts` runs the
|
|
38
|
+
two tables above it — what opening costs, and what one ten-second window costs. This is the third,
|
|
39
|
+
and the one that carries an argument rather than a figure: thirty consecutive ten-second windows
|
|
40
|
+
over an 8-channel EDF+C cost 30 reads and 1,246,800 bytes from a bare source, and 1 read of
|
|
41
|
+
1,048,576 bytes through `cachedSource`.
|
|
42
|
+
- The sentence under it is why the table is there. "Removing `cachedSource` changes the number of
|
|
43
|
+
reads and nothing else" is a debugging instruction — if a bug appears with the cache in place,
|
|
44
|
+
delete the wrapper; if it survives, the cache was not involved — and it is only as good as the
|
|
45
|
+
"nothing else". The two runs are now compared sample for sample, all 153,600 of them, with the
|
|
46
|
+
count of non-zero values asserted too: a fixture decoding to zeros throughout would make an exact
|
|
47
|
+
match mean nothing.
|
|
48
|
+
- The page also says which block the single read is — "the second 1 MiB block. The first was already
|
|
49
|
+
resident because the header read at open pulled it in, so the reads that come with opening a file
|
|
50
|
+
are not wasted." That is checked as an offset, because it is what a reader plans an HTTP range
|
|
51
|
+
budget around, and because a cache issuing one read of the right size at the wrong place would
|
|
52
|
+
satisfy every other assertion here.
|
|
53
|
+
- The neighbouring claim goes with it: thirty ten-second windows cost thirty reads, and one
|
|
54
|
+
300-second window over the same records costs one, for the same 1,246,800 bytes.
|
|
55
|
+
|
|
9
56
|
## 0.5.21
|
|
10
57
|
|
|
11
58
|
- **Added** the census `reading-signals.md` takes of the derived sample rate. `samplesPerRecord` is
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED