edfcore 0.5.43 → 0.5.45
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 +48 -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.45";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,54 @@ 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.45
|
|
10
|
+
|
|
11
|
+
- **Added** the relationship between `inspectEdf` and the call it is triage for. `diagnostics.md`
|
|
12
|
+
calls it "the first call" for an unfamiliar file: at most 128 KiB, never throws about content,
|
|
13
|
+
returns `ok`, `variant`, `header`, `bytesRead` and a diagnostics list. Every one of those is
|
|
14
|
+
tested — `inspect-safety.test.ts` over bytes nobody chose, `inspect-validate.test.ts` on the
|
|
15
|
+
ceiling — and the relationship to `openEdf` was not.
|
|
16
|
+
- That relationship is the whole point. Running `inspectEdf` over a directory decides which files
|
|
17
|
+
are worth opening, and the decision is worthless if the header it shows you is not the header you
|
|
18
|
+
will get. Over the eight `AWKWARD` shapes, wherever it returns a header it is now compared field
|
|
19
|
+
for field against `openEdf`'s — diagnostics and variant included.
|
|
20
|
+
- `ok` is checked as the rule the page states rather than as a value: "true only when the header
|
|
21
|
+
parsed **and** carried no error-severity diagnostic", verified against `summarizeDiagnostics` over
|
|
22
|
+
the same header, with both branches reached in the matrix. A signal with no usable scale gives
|
|
23
|
+
`ok: false` on a header that is perfectly readable and a file that opens — the distinction the
|
|
24
|
+
callout on the same page draws.
|
|
25
|
+
- `variant` is checked as the "separate best effort" the page says it is. The version block and the
|
|
26
|
+
reserved field are the first 8 and 44 bytes and "stay readable long after everything else has
|
|
27
|
+
stopped making sense": a file whose signal count is garbage has no header at all and is still
|
|
28
|
+
reported as `BDF+C`, or `EDF+D`, rather than as nothing. That is the sentence the section ends
|
|
29
|
+
with, and nothing had run it.
|
|
30
|
+
- The cost is bounded from both sides: never above the 128 KiB ceiling, and never above what opening
|
|
31
|
+
the same file costs, in bytes and in reads — because it skips the record probes.
|
|
32
|
+
|
|
33
|
+
## 0.5.44
|
|
34
|
+
|
|
35
|
+
- **Added** reading one recording from several places at once. Everything in the suite reads
|
|
36
|
+
sequentially, and nothing in the API documents an ordering requirement — a recording is a plain
|
|
37
|
+
struct, `readWindow` takes it and returns a value, and the obvious thing to write in a viewer is
|
|
38
|
+
`Promise.all` over the channels or the visible range. That was untested territory: the reads share
|
|
39
|
+
a source, an index whose `onsetTicks` memoises, and a timeline every rebasing path consults.
|
|
40
|
+
- Correctness holds. Five overlapping windows resolved together give what the same five give one at
|
|
41
|
+
a time, and so does the whole API at once — a window, a record range, the annotations, an index
|
|
42
|
+
build and a full validation sweep, launched together and compared against the same five in order.
|
|
43
|
+
It also holds over a source that resolves reads in **reverse order of arrival**, which is the case
|
|
44
|
+
worth having: a network returns what it returns when it returns it, and a reader that assumed its
|
|
45
|
+
own issue order would come apart exactly there.
|
|
46
|
+
- Then the one place concurrency costs something, which is worth naming because it is invisible.
|
|
47
|
+
`record-index.ts` says `onsetTicks(r)` "reads that ONE record and memoises the answer", and
|
|
48
|
+
`locate-cost.test.ts` checks that a second call is free. It memoises on **resolution** rather than
|
|
49
|
+
on request, so ten calls for the same record launched together issue ten reads. The eleventh,
|
|
50
|
+
after they settle, issues none.
|
|
51
|
+
- That is a cost rather than a defect, and the package already documents the remedy: `cachedSource`
|
|
52
|
+
exists so that "concurrent reads wanting the same block issue ONE underlying read". Wrapped in it,
|
|
53
|
+
the same ten calls issue none at all — the block was already resident from the open, which is the
|
|
54
|
+
observation `large-files.md` makes about the reads that come with opening a file not being wasted.
|
|
55
|
+
The answer is identical either way.
|
|
56
|
+
|
|
9
57
|
## 0.5.43
|
|
10
58
|
|
|
11
59
|
- **Added** the two halves of what a sample width decides, written side by side. EDF stores each
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED