Newest at the top
| 2025-01-23 22:05:26 +0100 | <homo> | those 14 days and 19 hours will surely turn into years of patching ghc, so this is why I'm wishing good luck and sanity to anyone wanting this |
| 2025-01-23 22:03:35 +0100 | <int-e> | Or rather you'd have... I still expect that to not work. |
| 2025-01-23 22:03:32 +0100 | <homo> | stage2 is only for those who care about reproducible builds |
| 2025-01-23 22:02:54 +0100 | <int-e> | fair enough |
| 2025-01-23 22:02:52 +0100 | <int-e> | so you have a stage -1 of sorts |
| 2025-01-23 22:02:51 +0100 | <homo> | stage2 = fast ghc compile bit-by-bit identical fast ghc |
| 2025-01-23 22:02:41 +0100 | <int-e> | oh |
| 2025-01-23 22:02:36 +0100 | <homo> | stage1 = slow ghc compiles ghc |
| 2025-01-23 22:02:32 +0100 | <int-e> | stage0 = microhs, stage1 = ghc executed in whatever way by microhs, so slow |
| 2025-01-23 22:02:24 +0100 | <homo> | stage0 = microhs compiles ghc, resulting binary is 50 times slower |
| 2025-01-23 22:02:13 +0100 | <int-e> | no. |
| 2025-01-23 22:02:01 +0100 | <int-e> | hmm |
| 2025-01-23 22:01:43 +0100 | <int-e> | stage1 should also be fast, no? |
| 2025-01-23 22:01:20 +0100 | <homo> | stage2 is just to make sure it's bit-to-bit identical to stage1 |
| 2025-01-23 22:01:15 +0100 | <dminuoso> | "Sorry we cant watch that movie next weekend, I'm busy compiling firefox" |
| 2025-01-23 22:01:14 +0100 | <int-e> | I imagine that GHC uses too many of its own extensions for that to have any chance of working. |
| 2025-01-23 22:00:52 +0100 | <dminuoso> | Sounds like good old Gentoo times from the 00s. |
| 2025-01-23 22:00:04 +0100 | <homo> | btw, I just made some optimistic calculation, that if normally compiling ghc with ghc takes 5 hours, and microhs is 20 times slower than ghc and produces 50 times slower binaries than ghc, we get (20 stage0 + 50 stage1 + 1 stage2) * 5 = 355 hours = 14 days 19 hours of computer not doing anything other than compiling ghc, so to anyone willing to try: good luck and stay sane |
| 2025-01-23 21:58:33 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-01-23 21:55:48 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-01-23 21:54:47 +0100 | poscat | (~poscat@user/poscat) poscat |
| 2025-01-23 21:52:37 +0100 | poscat | (~poscat@user/poscat) (Ping timeout: 248 seconds) |
| 2025-01-23 21:51:53 +0100 | <homo> | do you mean like some gnu/linux distros package haskell libraries?? |
| 2025-01-23 21:51:30 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-01-23 21:50:26 +0100 | <dminuoso> | That way updates are easily reflected in git history too. |
| 2025-01-23 21:50:11 +0100 | <dminuoso> | Ideally I would want cabal-install to have a mechanism to quickly vendor all dependencies unpacked locally |
| 2025-01-23 21:49:50 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-23 21:48:40 +0100 | <homo> | you just give example of why bring microhs to plan9 - small dependency footprint of all software combined |
| 2025-01-23 21:46:13 +0100 | <dminuoso> | Why why I belong to the set of people that dislike large dependeny footprints, it makes my job harder. :-P |
| 2025-01-23 21:45:28 +0100 | <dminuoso> | But for now this is a manual process which I rigorously follow. |
| 2025-01-23 21:45:09 +0100 | <dminuoso> | For a while I have been playing around with an idea on how to tie this into cabal-install |
| 2025-01-23 21:44:48 +0100 | <dminuoso> | homo: I do that for our critical software. |
| 2025-01-23 21:44:26 +0100 | <homo> | would be actually an interesting update mechanism for every user: review code before updating |
| 2025-01-23 21:43:49 +0100 | <dminuoso> | Not enough to consider it a pattern, but its a possibility |
| 2025-01-23 21:43:42 +0100 | <dminuoso> | But Ive seen reports from a few maintainers that have to fight floods of PRs of poorly generated code already. |
| 2025-01-23 21:43:32 +0100 | <homo> | also when updates happen rarely, it's easier to make independent review and decide whether or not they are desirable |
| 2025-01-23 21:43:24 +0100 | <dminuoso> | LLMs certainly seem like a promising solution to a lack of open source contributions - whether its for good or worse remains to be seen. |
| 2025-01-23 21:42:54 +0100 | EvanR | (~EvanR@user/evanr) EvanR |
| 2025-01-23 21:42:51 +0100 | <dminuoso> | sm: Especially in projects where there is 1-2 develoeprs, but dozens of issues a day from people that really want things fixed. |
| 2025-01-23 21:42:27 +0100 | <Rembane> | homo: Some ecosystems are so much more chill than others when it comes to updates. |
| 2025-01-23 21:42:15 +0100 | <Rembane> | homo: I think that depends on the ecosystem |
| 2025-01-23 21:42:12 +0100 | <dminuoso> | sm: Well most certainly do not donate 40 hours a week. When I say "little time" I mean it in the sense of "what little time they can donate" while splitting time with family, other hobbies and sleep |
| 2025-01-23 21:41:17 +0100 | <geekosaur> | (or modules in their private `lib` directories) |
| 2025-01-23 21:41:06 +0100 | <geekosaur> | some of us ignore the update culture. xmonad's core barely changes; it's solid and doesn't need to change, and most things can be done via hooks (which mostly come from xmonad-contrib but I've seen a fair amount of personal extensions in people's `xmonad.hs` files) |
| 2025-01-23 21:40:06 +0100 | <homo> | because if you don't push more code, people think your project is dead, irrelevant |
| 2025-01-23 21:40:03 +0100 | <haskellbridge> | <sm> me too. Not all projects can be done; either way, I love the ones that just keep working |
| 2025-01-23 21:39:16 +0100 | <Rembane> | Why? |
| 2025-01-23 21:38:26 +0100 | <homo> | I bet this kind of culture of frequent updates helps exploits like in xz happen |
| 2025-01-23 21:38:08 +0100 | <Rembane> | I love projects that are done. And that just keeps working. |
| 2025-01-23 21:37:09 +0100 | simplystuart | (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Ping timeout: 248 seconds) |