paths-in-cube
bytestring
paths-in-cube | bytestring | |
---|---|---|
3 | 15 | |
0 | 285 | |
- | 1.1% | |
4.5 | 7.5 | |
over 2 years ago | 13 days ago | |
Haskell | Haskell | |
- | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
paths-in-cube
-
How can Haskell programmers tolerate Space Leaks?
I have been trying to answer it for myself practically on a toy program that needs a ton of memorization. What I found is that optimizing space behaviour is hell. A value resides in memory while it is in scope, but when and for how long exactly is it in scope? Depends on inlining and specialization. And these things are fragile. Once a computation is evaluated to a big value, there is no way to forcibly «forget» it so that it turns back into a small computation, which makes some seemingly simple things practically impossible. This stuff is not explained anywhere either.
-
How can I pass a local ordering function to a standard set or map?
If you are curious, the code may be seen and toyed with at the repository — it does not have this specific feature yet (or I would not be asking), but shows the need for it.
-
Why does adding `trace ""` give a tenfold speed up?
Code is here: https://github.com/kindaro/paths-in-cube/commit/d79cd4a77f168ab5f5e841c30ade05e51db969f5
bytestring
-
RunWithScissors() (2009)
The documentation is itself fairly funny, for those who don’t care to click ahead:
> This "function" has a superficial similarity to ‘unsafePerformIO’ but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet.
> Witness the trail of destruction:
https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7
-
Monthly Hask Anything (July 2022)
If you bring in efficient strings from bytestring, densely packed arrays from vector, and an in-place sort from vector-algorithms, you can bring it down to 275ms (uses 19MB of mem).
- Some light investigation regarding ByteString's IsString instance, and its conclusions
-
Haskell - Important Libraries
bytestring
-
[ANNOUNCE] GHC 9.2.2 is now available!
Note that this release is broken for Windows.
-
Beginner level tutorial - bytestring
I've opened https://github.com/haskell/bytestring/issues/455 so the situation can be improved. You're very welcome to chime in on the discussion or to contribute some of the missing documentation yourself! :)
-
bytestring-0.11.2.0
Highlights from the changelog:
- [Haskell]
-
Dragging Haskell Kicking and Screaming into the Century of the Fruitbat :: Reasonably Polymorphic
Well, ByteString in particular should not have an IsString instance in a new report. That's pretty clear by https://github.com/haskell/bytestring/issues/140 : the concensus is that there is no good solution right now, but it should not have gotten an IsString instance in the first place. If a theoretical new Haskell Report 202x includes OverloadedStrings (as it should) to handle string literals analogously to numeric literals, I'd expect it to not give ByteString (which is really just a collection of octets) an IsString instance, with all it's issues and rattail due to the encoding question being implicitized.
-
How can Haskell programmers tolerate Space Leaks?
Standard streaming libraries. They are being written by people that make the effort to understand performance and I have a hope that they make sure their streams run in linear space under any optimizations. It is curious and unsettling that we have standard lazy text and byte streams at the same time — and the default lazy lists, of course. I have been doing some work on byte streams and what I found out is that there is no way to check that your folds are actually space constant even if the value in question is a primitive, like say a byte — thunks may explode and then collapse over the run time of a single computation, defying any effort at inspection.
What are some alternatives?
gotta-go-fast - Abandoned: https://github.com/haskellfoundation/tech-proposals/pull/9
bytestring-read - fast ByteString to number converting library
bytestring-typenats - Haskell ByteStrings annotated with type-level naturals for lengths
bytestring-builder - The new bytestring builder, packaged outside of GHC
bytestring-tree-builder - A very efficient ByteString builder implementation based on the binary tree
bytestring-delta - Simple binary diff/patch library for C and Haskell
bytestring-plain - Plain byte strings (`ForeignPtr`-less `ByteString`s)
streamly-bytestring
bsparse - bytestring parser
bytestring-arbitrary - Arbitrary instances for ByteString
pathological-bytestrings - Facilities for testing with ByteStrings
elm-format - elm-format formats Elm source code according to a standard set of rules based on the official Elm Style Guide