2.4.0 #16
Draft
2.4.0 #16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…x/cryptonite Since the security of cryptonite nor shecretbox aren't guaranteed, we default to depending on libsodium which has been audited numerous times by many institutions. We add a conditional compilation flag and some CPP macros so that users can choose to switch to the other implementation if they accept the risks associated, and cannot link to libsodium for any reason.
…ce into 2.4.0-dev
This fixes a bug in the CI where the Ubuntu 18.04 runner tries to load the cache for Ubuntu 20.04 (since runner.os is "Linux" for both of them) and results in an error for `scientific` since the GLIBC version that it builds against is different in the two runners.
No particular reason here other than future-proofness. Ubuntu 18.04 is having a brownout today in GitHub runners and was removed in a previous commit. Having just Ubuntu 20.04 felt a little sad so I'm adding in 22.04. 8.10.7 was chosen to be aligned to the Mac and Windows variants. It's the main supported version for this library for now.
Previously we always wrapped `unconsumedBytes` with the Maybe constructor, before performing prepending to `mbChunk`. This was unnecessary computation if `unconsumedBytes` was `BS.empty` and `mbChunk` was Nothing. The change adds an early if-conditional for that. It also removes the Maybe wrapping, and instead uses `fromMaybe` to unwrap the chunk from the conduit, which reduces computation.
In the inner loop for oggPageExtractC, we prepend the unconsumed bytes with the new chunk. Using strict bytestrings incurs a O(m+n) memcpy cost when performing the appending, whereas if we switch to lazy bytestrings, we get two benefits: 1. We avoid BL.toStrict when recursing, since the `binary` package unconditionally uses Lazy bytestrings anyway. 2. We get a faster append, since lazy bytestring append is O(m) in the length of the spine in the first bytestring. There are no places within the code that are affected negatively by this change. Ref: https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/src/Data.ByteString.Lazy.Internal.html#append https://hackage.haskell.org/package/bytestring-0.11.3.1/docs/src/Data.ByteString.Internal.html#append
The unterminated segment data parameter to the inner loop of splitOggPackets was made lazy, since it undergoes on average at least one or two append operations, and the less time it takes the better. There is a justification provided as a comment.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
playand audio resources behave: adding effects like reverb, getting metadata of playing track, etc will be easiertyped-processfor safer subprocess handling with guaranteesGeneral Changes