Woop! My timerfd change is finally out in the wild!
This will make it so that (on systems with timerfd) the runtime will no longer have to wait for the next runtime tick before exiting. This saves on average 5 ms per program run, and up to 10 ms for programs with a very short runtime. Not much for server programs with an expected lifetime of days/weeks, but potentially quite nice for CLI programs like hledger or for programs that invoke many other Haskell programs.
I accidentally discovered this when trying to optimize an Advent of Code problem and couldn't get it below 10 ms no matter what I tried. Eventually I discovered that "hello world" also took 10 ms so I assumed it was just runtime startup costs. Decided to look anyway and found out it was actually runtime shutdown costs, where the runtime would `join` the rts "ticker" thread. The ticker thread would only check for a shutdown flag once every loop, so 10 ms with the default settings. Now it can be shut down immediately, which makes small programs much faster.
Of all the complaints about YAML, I never understood this one, which is actually the correct way to handle it. Of course N.M (without some kind of quotes) is a floating point number and not a string!? The other way around would be _really_ strange.
On a general case, yes. But we are talking about Stack, a system for managing software dependencies. When was the last time you put numbers intended to be real numbers in a dependency declaration file? In different words, when was the last time you added, subtracted, multiplied or divided versions?
Version numbers are always strings with special comparison semantics.
My point is that all the numbers in a dependency configuration file should be automatically converted to strings, because they are really strings. Yaml doesn't do that.
Hiding language features behind opt-in flags seems weird, but after some thought I like it. Consider if C++ had similar flags, people are always saying to choose a subset of C++ to use, and flags would make that explicit and enforceable. Also, when you see a weird bit of syntax you would have an idea what to search for.
One possible reason could be that haskell has specifications (latest version is haskell 2010) and multiple implementations. So GHC cannot change the default language like this.
> We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years.
Is GitHub sponsoring Haskell development? Or is this them providing some free services (e.g. more Runners) because it's a large and importans OSS project?
I am surprised just how much Cardano is responsible for the funding of GHC and what would happen if that stopped - 4 of those supporters are directly related to Cardano and a fifth is somewhere related. I don't know what GitHubs relation is with Haskell and wonder if that's some hosting/CI runners or something?
GHC uses self hosted gitlab for its source hosting and review. The gitlab-runners are largely provided by the mentioned support in the announcement, including anonymous and in-kind contributions. The ZW3RK stake pool provides 7 linux, 2 windows, and 3 mac builders.
I only see two directly related supporters? IOG and the stake pool?
The very nature of coordinated package sets makes it impossible to have LTS package sets for the last version on release day. Stackage's policy is to use nightly for the latest release, and publish LTS versions for older compiler versions.
If you want to be on the cutting edge of releases and ignore packages coordination delays and package maintainers taking some time to respond because they actually have a life, you can move to the nightly. Smaller package sets but closer to GHC releases. If you want someone else to solve dependency hell for you and take the time to upstream that fix, you need to give people some time to do it.
Although, you're right, the nightly was 3005 packages when stackage moved to 9.4 [1]. I guess taking a few months for compiler version bumps in stackage helps that.
This will make it so that (on systems with timerfd) the runtime will no longer have to wait for the next runtime tick before exiting. This saves on average 5 ms per program run, and up to 10 ms for programs with a very short runtime. Not much for server programs with an expected lifetime of days/weeks, but potentially quite nice for CLI programs like hledger or for programs that invoke many other Haskell programs.
I accidentally discovered this when trying to optimize an Advent of Code problem and couldn't get it below 10 ms no matter what I tried. Eventually I discovered that "hello world" also took 10 ms so I assumed it was just runtime startup costs. Decided to look anyway and found out it was actually runtime shutdown costs, where the runtime would `join` the rts "ticker" thread. The ticker thread would only check for a shutdown flag once every loop, so 10 ms with the default settings. Now it can be shut down immediately, which makes small programs much faster.