Newest at the top
| 2025-01-23 22:29:15 +0100 | Sgeo_ | (~Sgeo@user/sgeo) Sgeo |
| 2025-01-23 22:29:13 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2025-01-23 22:27:28 +0100 | merijn | (~merijn@62.45.137.128) merijn |
| 2025-01-23 22:26:03 +0100 | son0p | (~ff@2800:e6:4001:6cc3:2e2c:4b4e:bc2a:6f17) son0p |
| 2025-01-23 22:24:02 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) |
| 2025-01-23 22:23:52 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
| 2025-01-23 22:23:44 +0100 | euleritian | (~euleritia@dynamic-176-006-148-054.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2025-01-23 22:22:57 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-23 22:21:46 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-23 22:16:38 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) chiselfuse |
| 2025-01-23 22:15:46 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2025-01-23 22:14:16 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-23 22:08:48 +0100 | acidjnk | (~acidjnk@p200300d6e7283f96b914b0b581af9338.dip0.t-ipconnect.de) acidjnk |
| 2025-01-23 22:08:40 +0100 | acidjnk | (~acidjnk@p200300d6e7283f96b914b0b581af9338.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2025-01-23 22:08:40 +0100 | apache | (apache2@anubis.0x90.dk) (Remote host closed the connection) |
| 2025-01-23 22:08:33 +0100 | apache2 | (apache2@anubis.0x90.dk) apache2 |
| 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 |