edfcore 0.4.350 → 0.4.352
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 +32 -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.352";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,38 @@ 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.352
|
|
10
|
+
|
|
11
|
+
- **Added** `tests/property/window-cost.test.ts`, which states in general what four checks in this
|
|
12
|
+
batch pinned one file at a time. Each of those is a specific recording with a number beside it,
|
|
13
|
+
and each would keep passing if the rule behind it broke for every file except the one in the
|
|
14
|
+
example.
|
|
15
|
+
- The rule: for any well-formed continuous recording and any window that overlaps it, `readWindow`
|
|
16
|
+
issues exactly one read, and that read is a whole number of records. `byteLength` is asserted as
|
|
17
|
+
an identity rather than a bound — exactly the records the chunk reports, whatever fraction of
|
|
18
|
+
them the caller wanted — because that is what makes the number in the result worth publishing,
|
|
19
|
+
and it is what a per-signal narrowing would quietly break while still returning the right
|
|
20
|
+
samples.
|
|
21
|
+
- The third property is the general form of the table on `reading-signals.md`: asking for one
|
|
22
|
+
channel costs the same reads and the same bytes as asking for all of them, on arbitrary
|
|
23
|
+
geometries rather than on the three-signal file the page measures.
|
|
24
|
+
|
|
25
|
+
## 0.4.351
|
|
26
|
+
|
|
27
|
+
- **Added** checks for two read counts on `api-reading.md`, a page that opens by inviting them:
|
|
28
|
+
"They are exact and testable: wrap your source in a recorder and count."
|
|
29
|
+
- Both are about paths a well-formed file never takes, which is why neither had a test.
|
|
30
|
+
`readHeader` is exactly two reads, and one when the signal-count field is unreadable — because
|
|
31
|
+
the second read's size is computed from that field, and a speculative read of an unknown size is
|
|
32
|
+
the thing being avoided. The saved read is not the point: the caller gets `SIGNAL_COUNT_INVALID`
|
|
33
|
+
rather than a complaint about a byte range, and that is what is asserted.
|
|
34
|
+
- The same distinction on the next line. A file too short for the header it declares is a file
|
|
35
|
+
defect, `SOURCE_TOO_SMALL`, not an `EdfSourceError` about a range past the end — getting it
|
|
36
|
+
backwards is not a crash but a truncated recording reported as an I/O error, which sends the
|
|
37
|
+
reader to their network stack instead of to their file. Also pinned: the probe costs nothing
|
|
38
|
+
without an annotations signal, and both probed onsets are memoised into the index while a record
|
|
39
|
+
between them is not.
|
|
40
|
+
|
|
9
41
|
## 0.4.350
|
|
10
42
|
|
|
11
43
|
- **Added** an execution of the truth table on `validation.md` — four rows over two independent
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED