| 6 Oct 2024 |
 maralorn | The difference is, that basically all bumps to Haskell packages are part of a mass batch update. We can probably be a bit less strict about forcing small fixes to got o haskell-updates, but honestly I already am. I have a relatively quick merge finger and do a judgement call on every of those PRs. | 12:42:21 |
 emily | right | 12:43:03 |
| emily | I thought we track Stackage LTS? isn't that more a once every month or two thing? | 12:43:27 |
| maralorn | In reply to @emilazy:matrix.org
I thought we track Stackage LTS? isn't that more a once every month or two thing? Well.
a) Stackage LTS minor releases are about once per week
b) half of our building packages are not pinned in stackage, they are just fetched from hackage and that has updates all around the clock.
| 12:45:54 |
| maralorn | i.e. Stackage only covers a small part of the whole ecosystem. | 12:46:38 |
| maralorn | * i.e. Stackage only covers a small part of the whole ecosystem, roughly 1/6th | 12:47:00 |
| emily | oh right, minor releases | 12:47:34 |
| maralorn | Stackage major releases otoh are more of a once to twice a year thing. | 12:48:19 |
| emily | I'm going to have to deal with this problem at some point soon when I get around to trying to do the Rust crates as separate packages thing, since obviously there all the updates are uncoordinated | 12:48:14 |
| emily | and bumps often require bumps to other crates | 12:48:28 |
| emily | I'd like to avoid a batch process/branch and just send things to master/staging, but we'll see what actually works out… | 12:48:40 |
| maralorn | I feel like I am very often in the "no it can’t be better because XY" position in these discussions. But I am actually very exited for any actual improvement if we can achieve it. | 12:50:12 |
| emily | it's tough :) | 12:52:09 |
| emily | from the inside you know all the reasons why people's preconceptions about the process and what will work are wrong. from the outside, sometimes you can see that the people on the inside are stuck in their own assumptions | 12:52:45 |
| maralorn | In reply to @emilazy:matrix.org
from the inside you know all the reasons why people's preconceptions about the process and what will work are wrong. from the outside, sometimes you can see that the people on the inside are stuck in their own assumptions Exactly | 12:53:06 |
| emily | many a time I have been on the inside saying "nope, you can't do better than that", only to be blindsided when some person I've never heard of before comes along and does better in ways I would have said would never work 😅 | 12:53:32 |
|  @sofo:matrix.org left the room. | 15:27:39 |
| 7 Oct 2024 |
 cdepillabout | In reply to @emilazy:matrix.org
many a time I have been on the inside saying "nope, you can't do better than that", only to be blindsided when some person I've never heard of before comes along and does better in ways I would have said would never work 😅 I totally get this. Just the other day I replied to someone on one of my repos saying it wouldn't be technically possible to fix one of the issues they had opened. Only to realize a few minutes later they had already sent a PR fixing the issue I thought couldn't be fixed 🤕 | 06:00:33 |
| emily | this PR clearly does not exist closes | 06:01:35 |
| 8 Oct 2024 |
 eldritchcookie | how do i unmark broken something https://github.com/typedbyte/apecs-effectful/issues/1 | 14:33:29 |
 MangoIV | Something that just came to mind due to other things: Does anybody who use Nixpkgs + Haskell at work do something crazy like compile the entire dependency tree with certain modifications like specific platform specific instructions or the LLVM backend? | 14:41:22 |
| eldritchcookie | what would be the benefits? i guess if performance is critical you could use SIMD via LLVM but unless you have a custom modification to GHC itself that seems like too much effort | 14:43:24 |
| MangoIV | In reply to @eldritchcookie:matrix.org
what would be the benefits? i guess if performance is critical you could use SIMD via LLVM but unless you have a custom modification to GHC itself that seems like too much effort I mean if you have a service that does a lot of arithmetic and the LLVM backend actually gives you considerable speed up then it might be very well worth a consideration. | 14:45:10 |
| MangoIV | Also mind that all the c libraries you’re binding are compiled without vector instructions. | 14:46:08 |
| MangoIV | That can sometimes give you a nx speed up | 14:46:50 |
| MangoIV | I just realised since I’m using a dep that implements an embarassingly parallelizable algorithm and the library actually wants to compile to AVX2 instructions but of course it doesn’t | 14:50:41 |
 alexfmpe | In reply to @mangoiv.:matrix.org
Something that just came to mind due to other things: Does anybody who use Nixpkgs + Haskell at work do something crazy like compile the entire dependency tree with certain modifications like specific platform specific instructions or the LLVM backend? Sort of? Using reflex-platform's package set means you get -fexpose-all-unfoldings everywhere plus a custom Text on JS plus a (not yet upstreamed) patch for GHC's garbage collection | 14:54:11 |
| alexfmpe | I think miso also has a fancy String but not sure whether they replace Text with it | 14:54:35 |
| alexfmpe | * I think miso also has a fancy string on JS but not sure whether they replace Text with it | 14:54:46 |
| MangoIV | Interesting. Though probably not as far reaching as I’d imagine. Also instane wrt exposing all unfoldings, what kinda machine are these package sets built on?! 😂 | 14:55:42 |
