Newest at the top
| 2025-10-16 21:00:04 +0200 | caconym7478798 | (~caconym@user/caconym) (Quit: bye) |
| 2025-10-16 20:59:07 +0200 | trickard_ | (~trickard@cpe-57-98-47-163.wireline.com.au) |
| 2025-10-16 20:58:53 +0200 | trickard_ | (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-16 20:58:41 +0200 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-10-16 20:57:30 +0200 | feetwind | (~mike@user/feetwind) feetwind |
| 2025-10-16 20:55:47 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-10-16 20:51:22 +0200 | wbrawner | (~wbrawner@static.56.224.132.142.clients.your-server.de) wbrawner |
| 2025-10-16 20:49:25 +0200 | wbrawner | (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 246 seconds) |
| 2025-10-16 20:48:34 +0200 | MelodyOwO | (~MelodyOwO@user/MelodyOwO) (Quit: Leaving.) |
| 2025-10-16 20:47:42 +0200 | <haskellbridge> | <dxtr> I've made a thing! A font renderer in pure Haskell. That's pretty neat |
| 2025-10-16 20:47:02 +0200 | gustrb | (~gustrb@191.243.134.87) |
| 2025-10-16 20:46:27 +0200 | craunts795335385 | (~craunts@136.158.7.194) (Ping timeout: 244 seconds) |
| 2025-10-16 20:45:00 +0200 | cawfee | (root@2401:c080:3800:3460::babe) (Ping timeout: 244 seconds) |
| 2025-10-16 20:44:28 +0200 | haltsolver | (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-10-16 20:44:18 +0200 | feetwind | (~mike@user/feetwind) (Ping timeout: 260 seconds) |
| 2025-10-16 20:43:37 +0200 | <endokqr> | (And by "Nix builds" I mean "my Nix flake specifies but I'm in over my head so it's going to take some time to tease out why that happens".) |
| 2025-10-16 20:43:33 +0200 | <int-e> | Which I know nothing about... I imagine there's some hoop you have to jump through to make packages that you installed with nix acutally visible to ghc. Generically, I'd look for verbosity flags to print the actual ghc commands being executed. |
| 2025-10-16 20:43:01 +0200 | <endokqr> | Ah, that's true. So maybe Nix builds one or more of my dependencies with -dynamic, and then GHC, in order to link against that, also tries to build shared libs? |
| 2025-10-16 20:41:07 +0200 | <int-e> | oh, or nix too I suppose |
| 2025-10-16 20:40:46 +0200 | troydm | (~troydm@user/troydm) (Ping timeout: 244 seconds) |
| 2025-10-16 20:40:46 +0200 | gustrb | (~gustrb@191.243.134.87) (Ping timeout: 244 seconds) |
| 2025-10-16 20:39:20 +0200 | <endokqr> | Hm. So something in there must be requesting -dynamic? Or is there some other way GHC might think I want to build shared libs? |
| 2025-10-16 20:39:17 +0200 | Inline | (~inline@2a02:8071:57a1:dc0:6828:ce27:6f9b:5100) (Quit: Leaving) |
| 2025-10-16 20:38:55 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-10-16 20:38:34 +0200 | <int-e> | GHC should only do that if you are building shared, and shared, profiling libs. |
| 2025-10-16 20:37:30 +0200 | wbrawner | (~wbrawner@static.56.224.132.142.clients.your-server.de) wbrawner |
| 2025-10-16 20:37:16 +0200 | <endokqr> | int-e, and if I'm fairly sure none of us use -dynamic, why would it be looking for .p_dyn_hi or .dyn_hi files for dependencies? |
| 2025-10-16 20:33:51 +0200 | <int-e> | endokqr: it'll link statically unless you (or stack or cabal) use -dynamic |
| 2025-10-16 20:33:32 +0200 | Guest3264 | (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Ping timeout: 244 seconds) |
| 2025-10-16 20:33:27 +0200 | <dolio> | And pseq is for if that sort of typical, local reordering is also not correct. |
| 2025-10-16 20:33:18 +0200 | <monochrom> | Yeah, if it reorders, it's because a heuristic says it's for the better. |
| 2025-10-16 20:33:07 +0200 | divlamir_ | divlamir |
| 2025-10-16 20:32:58 +0200 | wbrawner | (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 246 seconds) |
| 2025-10-16 20:32:42 +0200 | <ski> | right |
| 2025-10-16 20:32:33 +0200 | ski | . o O ( Undefined Behaviour ) |
| 2025-10-16 20:32:29 +0200 | <dolio> | The ambiguity of seq allows for local reordering of things like you'd expect in a compiler. But it's not going to do extra work to do something weird with it. |
| 2025-10-16 20:31:17 +0200 | <monochrom> | Yeah GHC doesn't troll you by legal loopholes :) |
| 2025-10-16 20:31:07 +0200 | <endokqr> | int-e, Ah, I see. How do I figure out if GHC will choose static or dynamic linking for my code? |
| 2025-10-16 20:30:45 +0200 | <dolio> | The reality is that it's usually more difficult to arrange for some technically correct but still leaking version of the semantics of seq. |
| 2025-10-16 20:30:20 +0200 | <monochrom> | But also empirically, suppose you say "seq (error "A") (error "B")", I have seen the B error happening sometimes. |
| 2025-10-16 20:29:55 +0200 | Inline_ | Inline |
| 2025-10-16 20:29:55 +0200 | Inline | Guest3264 |
| 2025-10-16 20:29:49 +0200 | Inline_ | (~inline@2a02:8071:57a1:dc0:6828:ce27:6f9b:5100) Inline |
| 2025-10-16 20:29:46 +0200 | <ski> | (also taking into account various arbitrary choices to pin down the ordering) |
| 2025-10-16 20:29:26 +0200 | <monochrom> | Or rather, s/the desired order/a desirable order/ |
| 2025-10-16 20:29:19 +0200 | <ski> | presumably, it would only change from the obvious straight-forward / naïve ordering, if it sees a reason to do so |
| 2025-10-16 20:28:17 +0200 | <int-e> | endokqr: the ghc executable that is. which is independent from how it compiles things |
| 2025-10-16 20:28:08 +0200 | <monochrom> | Although, again, empirically, I have always seen the desired order (that saves space). |
| 2025-10-16 20:27:38 +0200 | <monochrom> | In Core, first GHC performs strictness analysis and chooses what it thinks is a wise order. Then by the time you see actual Core code, it reflects the choice made for your particular example, not necessarily generalizable. |
| 2025-10-16 20:27:30 +0200 | <int-e> | that means ghc itself is using dynamic linking (mostly relevant for ghci) |