Remove lodash dependency from @mcap/core #597
Conversation
jhurliman
requested review from
defunctzombie and
jtbandes
and removed request for
defunctzombie
| a.messageEncoding === b.messageEncoding && | ||
| a.schemaId === b.schemaId && | ||
| a.topic === b.topic && | ||
| a.metadata.size === b.metadata.size |
There was a problem hiding this comment.
Is there anything we can do to protect against adding fields but forgetting to define them here for equality comparison?
Random thought: might it be better to store a crc of the original record bytes and compare that?
| @@ -191,3 +189,14 @@ export function parseRecord( | |||
| throw new Error("Not yet implemented"); | |||
| } | |||
| } | |||
|
|
|||
| function isChannelInfoEqual(a: ChannelInfo, b: ChannelInfo): boolean { | |||
There was a problem hiding this comment.
Similar thoughts to the channel info comparison below - maybe a crc on the bytes would be effective and work if we ever add a new field.
defunctzombie
dismissed
their stale review
Meant to add as a comment rather than approve so Jacob could still review
| }); | ||
|
|
||
| it("handles negation", () => { | ||
| const array: [bigint, bigint][] = [ |
There was a problem hiding this comment.
This test seems invalid? The input array is not sorted by (x)=>-x.
| const computedValue = iteratee(value); | ||
|
|
||
| while (low < high) { | ||
| const mid = (low + high) >>> 1; |
There was a problem hiding this comment.
The other math adjustment I was referring to was low + (high - low) >>>1, to avoid overflow during addition
**Public-Facing Changes** Upgrades @mcap/core to get the fix from foxglove/mcap#597
Public-Facing Changes
@mcap/corecan be used without manually installinglodashDescription
lodash was used in a few places but there was no dependency on it in package.json. This replaces the few uses of lodash generic methods with more optimized functions tuned for the @mcap/core library. In particular, it avoids heap allocation of new string objects during binary searches.
Fixes #588