edfcore 0.6.36 → 0.6.37

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.
@@ -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.6.36";
112
+ export declare const VERSION = "0.6.37";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.6.36';
82
+ export const VERSION = '0.6.37';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,26 @@ 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.6.37
10
+
11
+ - **Fixed** an incomplete sentence on `api-reading.md`. It said the index traversal "is chunked so
12
+ memory stays bounded whatever the file size: each chunk holds
13
+ `min(4 MiB, maxMaterializeBytes) / recordByteLength` records, and never fewer than one" — which
14
+ is true and reads as though a small budget only makes the scan slower. Below one record's worth
15
+ it does not: one record cannot be read within the budget and there is no smaller count to ask
16
+ for, so the scan is refused. The page says that now, and says the refusal names the record's size.
17
+ - **Added** `the-page-says-always.test.ts`, which executes the five claims on that page that say
18
+ "always", "never" or "every" against all seventeen shapes. Each was written when the matrix held
19
+ eight, and a universal claim is only as checked as the widest file anyone pointed it at — 0.6.36
20
+ is what happens when one meets a shape it had not: four sweeps turned out to be asserting
21
+ something narrower than they said. The claims are read off the page, so a rewording fails here.
22
+ - Two are worth naming. `readAnnotations` answers on a file with NO annotations channel, returning
23
+ one onset per record from the nominal grid — "always" includes the file with nowhere to store an
24
+ annotation. And on that same file a budget of one byte does not refuse, because the page's next
25
+ sentence says such a file "is not scanned at all, because its record onsets are arithmetic": the
26
+ two claims agree, and the test checks that they do rather than exempting one.
27
+ - No library change.
28
+
9
29
  ## 0.6.36
10
30
 
11
31
  - **Added** a seventeenth shape to the `AWKWARD` matrix: records that overlap in time, where a
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.6.36",
3
+ "version": "0.6.37",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.6.36';
96
+ export const VERSION = '0.6.37';