edfcore 0.4.417 → 0.4.419

package/dist/constants.d.ts

@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
     readonly reserved: 224;
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export declare const VERSION = "0.4.417";
+export declare const VERSION = "0.4.419";
 //# sourceMappingURL=constants.d.ts.map

package/dist/constants.js

@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
     reserved: 224,
 };
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.417';
+export const VERSION = '0.4.419';
 //# sourceMappingURL=constants.js.map

package/docs/CHANGELOG.md

@@ -6,6 +6,37 @@ alone does not tell you whether you were affected.
 edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
 defect; those are called out below.
 
+## 0.4.419
+
+- **Added** tests for the two ways `mergeChunks` can be handed an input whose numbers look right.
+  It concatenates by position — signal `i` of the second chunk continues signal `i` of the first —
+  and the refusal for a different NUMBER of channels was pinned. The same channels in a different
+  ORDER was not.
+- A caller reaches that without doing anything strange: `signalIndices` built from a `Set`, from
+  `Object.keys`, from a checkbox list re-rendered between reads, or from `getSignal` calls made in
+  whatever order the labels came back. Merging those splices one electrode's samples onto another's
+  and returns a chunk that looks entirely normal — right length, right record range, right
+  timestamps — with two channels swapped halfway through. Nothing downstream would catch it,
+  because there is nothing wrong with the numbers, only with which channel they belong to. On a
+  montage that is the difference between a left-temporal seizure and a right-temporal one.
+- The second is the array itself. `mergeChunks` addresses its input by index, so a hole left by a
+  `filter` or a splice would read as `undefined` and be dereferenced; it is refused by name
+  instead, pointing at the array `readWindow` returned.
+
+## 0.4.418
+
+- **Fixed** the rest of what 0.4.417 was about. Memoising the diagnostic sweep cut
+  `spec-references.test.ts` from 13.0 s to 4.4 s and did not settle the timeouts: whichever check
+  ran first still did the whole sweep inside its own five-second budget, and on a machine running a
+  video call and an emulator that alone took 6.5 s. Three release runs failed on it after the
+  memo landed.
+- The sweep is now paid for in a `beforeAll` with a timeout of its own. The work is real rather
+  than a hang, so the honest answer is to say how long it may take — once, in one place, rather
+  than as a number repeated on seven checks. Every check then finds the memo warm and runs at the
+  default timeout, which is the budget that should govern a check.
+- Worth stating plainly: the previous entry claimed more than it delivered. It reduced the risk by
+  more than a factor of five and left the first caller carrying the whole cost.
+
 ## 0.4.417
 
 - **Fixed** the cost of `spec-references.test.ts`, which was the most expensive file in the suite by

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edfcore",
-  "version": "0.4.417",
+  "version": "0.4.419",
   "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
   "keywords": [
     "edf",

package/src/constants.ts

@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
 } as const;
 
 /** Published package version. Kept in sync with package.json by a test. */
-export const VERSION = '0.4.417';
+export const VERSION = '0.4.419';