Logs: liberachat/#haskell
| 2025-10-16 17:59:28 | → | vanishingideal joins (~vanishing@user/vanishingideal) |
| 2025-10-16 17:59:29 | × | synchromesh quits (~john@2406:5a00:2412:2c00:20d4:65ae:d853:d670) (Read error: Connection reset by peer) |
| 2025-10-16 17:59:36 | → | Inline_ joins (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) |
| 2025-10-16 18:00:22 | → | synchromesh joins (~john@2406:5a00:2412:2c00:20d4:65ae:d853:d670) |
| 2025-10-16 18:00:34 | × | Inline_ quits (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Max SendQ exceeded) |
| 2025-10-16 18:01:12 | → | Inline_ joins (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) |
| 2025-10-16 18:02:02 | Inline | is now known as Guest6419 |
| 2025-10-16 18:02:02 | × | Guest6419 quits (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Killed (calcium.libera.chat (Nickname regained by services))) |
| 2025-10-16 18:02:02 | Inline_ | is now known as Inline |
| 2025-10-16 18:02:25 | × | gustrb quits (~gustrb@191.243.134.87) (Ping timeout: 256 seconds) |
| 2025-10-16 18:03:28 | <endokqr> | tomsmeding, one of the broken dependencies is base... but I have a vague feeling GHC is not supposed to look for these .p_dyn_hi files when it builds with profiling, but instead choose not to dynamically link but there's something in that process going wrong. not at all sure though. |
| 2025-10-16 18:05:03 | <monochrom> | By default, GHC chooses static linking. Unless Arch's build of GHC, which chooses dynamic linking. |
| 2025-10-16 18:06:21 | × | Inline quits (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Remote host closed the connection) |
| 2025-10-16 18:06:39 | <tomsmeding> | endokqr: right, I was asking because of the arch stuff: is your ghc from ghcup or from the system package manager? If the latter, and certainly if it's arch, get rid of that and use ghcup instead |
| 2025-10-16 18:06:41 | → | Inline joins (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) |
| 2025-10-16 18:07:46 | × | GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 246 seconds) |
| 2025-10-16 18:10:07 | × | jmcantrell quits (~weechat@user/jmcantrell) (Ping timeout: 260 seconds) |
| 2025-10-16 18:12:15 | → | GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano) |
| 2025-10-16 18:15:50 | × | trickard quits (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-16 18:16:03 | → | trickard_ joins (~trickard@cpe-57-98-47-163.wireline.com.au) |
| 2025-10-16 18:16:44 | → | gustrb joins (~gustrb@191.243.134.87) |
| 2025-10-16 18:18:03 | <mreh> | ski: was he reading from the spec, because empirically I've never seen that behaviour |
| 2025-10-16 18:20:06 | <ski> | yes, this is reasoning from the denotational meaning of `seq', not about what a particular implementation does |
| 2025-10-16 18:20:12 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 272 seconds) |
| 2025-10-16 18:21:48 | <mreh> | in core, seq a b is translated to something like case a of... isn't it? |
| 2025-10-16 18:22:01 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 2025-10-16 18:22:09 | → | jmcantrell joins (~weechat@user/jmcantrell) |
| 2025-10-16 18:22:32 | × | Vajb quits (~Vajb@n7o35ytoa19a9fdq6h6-1.v6.elisa-mobile.fi) (Ping timeout: 256 seconds) |
| 2025-10-16 18:22:33 | <ski> | for function values ? |
| 2025-10-16 18:24:54 | <endokqr> | monochrom, tomsmeding: Ah, I see. This is the default GHC from nixpkgs – I think! |
| 2025-10-16 18:24:59 | × | wbrawner quits (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 265 seconds) |
| 2025-10-16 18:25:08 | → | wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de) |
| 2025-10-16 18:27:07 | <endokqr> | But ghc --info says "GHC Dynamic" "YES" which I thought meant dynamic linking. |
| 2025-10-16 18:27:30 | <int-e> | that means ghc itself is using dynamic linking (mostly relevant for ghci) |
| 2025-10-16 18:27:38 | <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 18:28:08 | <monochrom> | Although, again, empirically, I have always seen the desired order (that saves space). |
| 2025-10-16 18:28:17 | <int-e> | endokqr: the ghc executable that is. which is independent from how it compiles things |
| 2025-10-16 18:29:19 | <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 18:29:26 | <monochrom> | Or rather, s/the desired order/a desirable order/ |
| 2025-10-16 18:29:46 | <ski> | (also taking into account various arbitrary choices to pin down the ordering) |
| 2025-10-16 18:29:49 | → | Inline_ joins (~inline@2a02:8071:57a1:dc0:6828:ce27:6f9b:5100) |
| 2025-10-16 18:29:55 | Inline | is now known as Guest3264 |
| 2025-10-16 18:29:55 | Inline_ | is now known as Inline |
| 2025-10-16 18:30:20 | <monochrom> | But also empirically, suppose you say "seq (error "A") (error "B")", I have seen the B error happening sometimes. |
| 2025-10-16 18:30:45 | <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 18:31:07 | <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 18:31:17 | <monochrom> | Yeah GHC doesn't troll you by legal loopholes :) |
| 2025-10-16 18:32:29 | <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 18:32:33 | ski | . o O ( Undefined Behaviour ) |
| 2025-10-16 18:32:42 | <ski> | right |
| 2025-10-16 18:32:58 | × | wbrawner quits (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 246 seconds) |
| 2025-10-16 18:33:07 | divlamir_ | is now known as divlamir |
| 2025-10-16 18:33:18 | <monochrom> | Yeah, if it reorders, it's because a heuristic says it's for the better. |
| 2025-10-16 18:33:27 | <dolio> | And pseq is for if that sort of typical, local reordering is also not correct. |
| 2025-10-16 18:33:32 | × | Guest3264 quits (~inline@2a02:8071:57a1:1260:d5a4:2b6e:3aa7:d03a) (Ping timeout: 244 seconds) |
| 2025-10-16 18:33:51 | <int-e> | endokqr: it'll link statically unless you (or stack or cabal) use -dynamic |
| 2025-10-16 18:37:16 | <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 18:37:30 | → | wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de) |
| 2025-10-16 18:38:34 | <int-e> | GHC should only do that if you are building shared, and shared, profiling libs. |
| 2025-10-16 18:38:55 | → | ljdarj joins (~Thunderbi@user/ljdarj) |
| 2025-10-16 18:39:17 | × | Inline quits (~inline@2a02:8071:57a1:dc0:6828:ce27:6f9b:5100) (Quit: Leaving) |
| 2025-10-16 18:39:20 | <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 18:40:46 | × | gustrb quits (~gustrb@191.243.134.87) (Ping timeout: 244 seconds) |
| 2025-10-16 18:40:46 | × | troydm quits (~troydm@user/troydm) (Ping timeout: 244 seconds) |
| 2025-10-16 18:41:07 | <int-e> | oh, or nix too I suppose |
| 2025-10-16 18:43:01 | <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 18:43:33 | <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 18:43:37 | <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 18:44:18 | × | feetwind quits (~mike@user/feetwind) (Ping timeout: 260 seconds) |
| 2025-10-16 18:44:28 | → | haltsolver joins (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-10-16 18:45:00 | × | cawfee quits (root@2401:c080:3800:3460::babe) (Ping timeout: 244 seconds) |
| 2025-10-16 18:46:27 | × | craunts795335385 quits (~craunts@136.158.7.194) (Ping timeout: 244 seconds) |
| 2025-10-16 18:47:02 | → | gustrb joins (~gustrb@191.243.134.87) |
| 2025-10-16 18:47:42 | <haskellbridge> | <dxtr> I've made a thing! A font renderer in pure Haskell. That's pretty neat |
| 2025-10-16 18:48:34 | × | MelodyOwO quits (~MelodyOwO@user/MelodyOwO) (Quit: Leaving.) |
| 2025-10-16 18:49:25 | × | wbrawner quits (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 246 seconds) |
| 2025-10-16 18:51:22 | → | wbrawner joins (~wbrawner@static.56.224.132.142.clients.your-server.de) |
| 2025-10-16 18:55:47 | → | tzh joins (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-10-16 18:57:30 | → | feetwind joins (~mike@user/feetwind) |
| 2025-10-16 18:58:41 | → | peterbecich joins (~Thunderbi@172.222.148.214) |
| 2025-10-16 18:58:53 | × | trickard_ quits (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-16 18:59:07 | → | trickard_ joins (~trickard@cpe-57-98-47-163.wireline.com.au) |
| 2025-10-16 19:00:04 | × | caconym7478798 quits (~caconym@user/caconym) (Quit: bye) |
| 2025-10-16 19:00:46 | → | caconym7478798 joins (~caconym@user/caconym) |
| 2025-10-16 19:04:35 | → | cawfee joins (root@2401:c080:3800:3460::babe) |
| 2025-10-16 19:06:27 | × | GdeVolpiano quits (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 256 seconds) |
| 2025-10-16 19:08:47 | → | GdeVolpiano joins (~GdeVolpia@user/GdeVolpiano) |
| 2025-10-16 19:10:25 | × | jmcantrell quits (~weechat@user/jmcantrell) (Ping timeout: 256 seconds) |
| 2025-10-16 19:10:53 | trickard_ | is now known as trickard |
| 2025-10-16 19:11:00 | → | ubert joins (~Thunderbi@77.119.165.5.wireless.dyn.drei.com) |
| 2025-10-16 19:23:21 | × | ubert quits (~Thunderbi@77.119.165.5.wireless.dyn.drei.com) (Read error: Connection reset by peer) |
| 2025-10-16 19:23:41 | → | ubert joins (~Thunderbi@77.119.165.5.wireless.dyn.drei.com) |
| 2025-10-16 19:30:45 | → | sam113102 joins (~sam@modemcable200.189-202-24.mc.videotron.ca) |
| 2025-10-16 19:32:00 | → | shr\ke_ joins (~shrike@user/paxhumana) |
| 2025-10-16 19:32:19 | → | dutchie_ joins (~dutchie@user/dutchie) |
| 2025-10-16 19:32:22 | → | ruvam_ joins (~ruvam@user/ruvam) |
| 2025-10-16 19:32:37 | → | dsal_ joins (sid13060@id-13060.lymington.irccloud.com) |
| 2025-10-16 19:32:38 | → | tomsmeding_ joins (~tomsmedin@user/tomsmeding) |
| 2025-10-16 19:32:39 | → | swistak joins (~swistak@185.21.216.141) |
| 2025-10-16 19:32:41 | → | distopico_ joins (~cerdolibr@2001:4b98:dc2:41:216:3eff:fe6c:52a1) |
All times are in UTC.