Logs: liberachat/#haskell
| 2025-10-30 20:11:38 | <segfaultfizzbuzz> | i would say like, ignore LLM generated code unless it (1) comes through claude code (2) has some kidn of decent type system which rejects really bad programs and (3) is reasonably well-prompted |
| 2025-10-30 20:12:00 | <EvanR> | and how do you know any of this from the code itself |
| 2025-10-30 20:13:32 | <segfaultfizzbuzz> | EvanR: i don't know, i'm probably not a good enough programmer to tell 75% of the time. there do tend to be high level inconsistencies in how the project concepts work, failures to compose, ... failure to do the right thing,... but yeah i'm not good enough to tell |
| 2025-10-30 20:14:14 | <segfaultfizzbuzz> | that's why i was asking about social norms rather than the code itself :-) |
| 2025-10-30 20:14:36 | <haskellbridge> | <sm> I have experimented a little with claude code; it's super useful including in haskell projects, and definitely not just a markov chain |
| 2025-10-30 20:14:57 | × | annamalai quits (~annamalai@2409:4042:2595:bd4d::195e:70b1) (Ping timeout: 260 seconds) |
| 2025-10-30 20:15:32 | <haskellbridge> | <sm> also probably super bad for the planet until we fix the economic model |
| 2025-10-30 20:15:33 | → | Guest25 joins (~Guest24@2803:9800:94c0:9a3b:d823:7586:d4c3:43b8) |
| 2025-10-30 20:15:43 | <haskellbridge> | <sm> (AI generally, not claude code) |
| 2025-10-30 20:15:51 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-10-30 20:16:19 | <EvanR> | certain usage for haskell really makes sense. In haskell you tend to accept and support code that is really big and dumb, like translation functions between simple things. They're annoying to type yourself but easy for the LLM. And then it's haskell so such "repeating yourself" code is not bad |
| 2025-10-30 20:17:14 | <EvanR> | a local macro system or something could also do it without requiring said planetary killing engines |
| 2025-10-30 20:17:16 | <segfaultfizzbuzz> | i encountered terrence tao doing vibe proving in lean and that kind of encouraged me to use LLMs more in coding without being quite so shy |
| 2025-10-30 20:17:23 | → | target_i joins (~target_i@user/target-i/x-6023099) |
| 2025-10-30 20:17:30 | <omentic> | hi. cabal build has apparently triggered hardware protections for cpu overheating that i didn't even know my computer had. how can i make cabal throttle its builds? |
| 2025-10-30 20:17:45 | <segfaultfizzbuzz> | omentic: out of curiousity are you on AMD? |
| 2025-10-30 20:17:59 | <omentic> | no, intel laptop from 2020 |
| 2025-10-30 20:18:01 | <EvanR> | if your CPU can't run at 100% then that's another problem |
| 2025-10-30 20:18:18 | <EvanR> | ventilate the room |
| 2025-10-30 20:18:39 | <omentic> | i've never seen this before in my life. it's very strange... no other build system has done this, not nix, not cargo, not clang |
| 2025-10-30 20:18:43 | <segfaultfizzbuzz> | omentic: i don't know,... thermal paste, maybe BIOS or operating system settings for power efficient mode? |
| 2025-10-30 20:18:50 | <omentic> | and i've compiled chromium on this thing lmao |
| 2025-10-30 20:19:00 | <segfaultfizzbuzz> | i saved a buddy's thinkpad once by re-pasting it after about five years |
| 2025-10-30 20:19:02 | <EvanR> | cabal can't make your CPU more hot than running 100% |
| 2025-10-30 20:19:14 | <segfaultfizzbuzz> | omentic: is this a thinkpad? |
| 2025-10-30 20:19:17 | <omentic> | yeah |
| 2025-10-30 20:19:17 | <EvanR> | though maybe you don't often use all your cores |
| 2025-10-30 20:19:29 | → | haltingsolver joins (~cmo@2604:3d09:207f:8000::d1dc) |
| 2025-10-30 20:19:31 | <segfaultfizzbuzz> | yeah, repaste it, get a good thermal paste |
| 2025-10-30 20:19:35 | <omentic> | hmm |
| 2025-10-30 20:19:40 | <omentic> | i think i will not do that lmao |
| 2025-10-30 20:19:50 | <segfaultfizzbuzz> | my buddy's thinkpad would shut down after about an hour's worth of ordinary moderate use like playing videos and stuff |
| 2025-10-30 20:20:00 | Guest25 | is now known as hedgehog99 |
| 2025-10-30 20:20:02 | <segfaultfizzbuzz> | omentic: a good thermal paste is like $10 |
| 2025-10-30 20:20:27 | <segfaultfizzbuzz> | DM me and i'll tell you how to do it, you also need some isopropyl alcohol and a roll of paper towels,... total cost might be $15 or $20 |
| 2025-10-30 20:20:56 | <omentic> | i do not think i want to re-thermal paste my ultrabook to cabal to build |
| 2025-10-30 20:20:59 | <yushyin> | use ptm7950 instead of a paste |
| 2025-10-30 20:21:35 | <segfaultfizzbuzz> | yushyin: yeah thermal pads are cool too but i don't have experience with them |
| 2025-10-30 20:21:50 | → | Guest24 joins (~Guest24@2803:9800:94c0:9a3b:d823:7586:d4c3:43b8) |
| 2025-10-30 20:22:00 | <segfaultfizzbuzz> | omentic: the paste will continue to degrade and your problems will get worse |
| 2025-10-30 20:22:04 | × | chiselfuse quits (~chiselfus@user/chiselfuse) (Ping timeout: 272 seconds) |
| 2025-10-30 20:22:28 | → | CiaoSen joins (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) |
| 2025-10-30 20:22:47 | → | chiselfuse joins (~chiselfus@user/chiselfuse) |
| 2025-10-30 20:23:14 | <segfaultfizzbuzz> | omentic: or do what i did and get a desktop :-) i've concluded that the laptop form factor is only useful for SSH |
| 2025-10-30 20:23:16 | × | ttybitnik quits (~ttybitnik@user/wolper) (Ping timeout: 256 seconds) |
| 2025-10-30 20:23:26 | × | Guest24 quits (~Guest24@2803:9800:94c0:9a3b:d823:7586:d4c3:43b8) (Client Quit) |
| 2025-10-30 20:23:53 | <omentic> | segfault: i really **do not** want to re-thermal paste my laptop to fix a cabal build issue that is only present with cabal and no other build system, lol |
| 2025-10-30 20:24:05 | <EvanR> | it's not cabal's fault |
| 2025-10-30 20:24:35 | <EvanR> | just make sure you get proper air flow to the laptop |
| 2025-10-30 20:24:39 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-10-30 20:24:48 | <omentic> | hmm |
| 2025-10-30 20:25:27 | × | hedgehog99 quits (~Guest24@2803:9800:94c0:9a3b:d823:7586:d4c3:43b8) (Ping timeout: 250 seconds) |
| 2025-10-30 20:25:32 | <haskellbridge> | <loonycyborg> I doubt that exact buildsystem matters |
| 2025-10-30 20:26:00 | <haskellbridge> | <loonycyborg> they all eat lot less cpu cycles than actual compile commands |
| 2025-10-30 20:26:00 | <haskellbridge> | <sm> cabal efficiently maximising your processors, eh ? Point a fan at the laptop or build at night ? |
| 2025-10-30 20:26:33 | <segfaultfizzbuzz> | omentic: how much $ do you have for a desktop |
| 2025-10-30 20:26:45 | <haskellbridge> | <sm> blast it with compressed air, maybe you can dislodge some dust :) |
| 2025-10-30 20:27:08 | × | simplystuart quits (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) (Remote host closed the connection) |
| 2025-10-30 20:27:24 | <haskellbridge> | <sm> or, limit how many processors cabal uses at once with -j |
| 2025-10-30 20:27:28 | <omentic> | dude i am not buying a new computer it is beyond reasonable for me to want to compile a project with three dependencies on my laptop |
| 2025-10-30 20:27:30 | → | simplystuart joins (~simplystu@c-75-75-152-164.hsd1.pa.comcast.net) |
| 2025-10-30 20:28:06 | → | Lycurgus joins (~juan@user/Lycurgus) |
| 2025-10-30 20:28:06 | <omentic> | sm: i'm thinking that's my problem, yeah. i suspect cargo/clang etc don't use all cores and i've accidentally passed a flag to GHC that's telling it to do so |
| 2025-10-30 20:28:11 | <omentic> | time to read the manual on -threaded |
| 2025-10-30 20:28:28 | <haskellbridge> | <sm> it'll build packages in parallel by default, add -j1 to stop that |
| 2025-10-30 20:29:00 | → | ljdarj1 joins (~Thunderbi@user/ljdarj) |
| 2025-10-30 20:30:21 | <haskellbridge> | <sm> I think -threaded is something different, affecting how the program you're building runs |
| 2025-10-30 20:30:22 | <monochrom> | cabal by default looks at your number of cores (even hyperthreads) and potentially builds that many packages in parallel. That can push your CPU. (For me, RAM is my bottleneck, I get thrashing.) So yeah use an explicit -j to limit it. (I use -j2.) |
| 2025-10-30 20:30:33 | <haskellbridge> | <sm> while -j affects cabal build itself |
| 2025-10-30 20:31:07 | <monochrom> | NB. "builds that many packages in parallel" = runs that many instances of GHC in parallel. (You know how much memory that takes, right? :) ) |
| 2025-10-30 20:31:09 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-10-30 20:31:36 | <haskellbridge> | <sm> also, if it's just three dependencies it's going to be finished relatively soon. Then it's just rebuilding some of your own modules when needed. |
| 2025-10-30 20:31:48 | × | ljdarj quits (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2025-10-30 20:31:48 | ljdarj1 | is now known as ljdarj |
| 2025-10-30 20:33:09 | <haskellbridge> | <sm> for a more general solution, there must be some kind of linux quota system you could use (rlimit ?) |
| 2025-10-30 20:33:37 | <monochrom> | (Hell, I don't add -j2 by hand, I put in ~/.cabal/config "jobs: 2".) |
| 2025-10-30 20:34:49 | <monochrom> | rlimit causes killing processes. as opposed to informing processes to behave. |
| 2025-10-30 20:34:59 | <haskellbridge> | <sm> ack |
| 2025-10-30 20:35:18 | <haskellbridge> | <sm> and I suppose nice doesn't prevent it using 100% |
| 2025-10-30 20:35:48 | <monochrom> | nice prevents it using 100% iff something else of higher priority uses 100%. >:) |
| 2025-10-30 20:36:50 | <monochrom> | You can always run it in VirtualBox. VirtualBox can lie about # of CPUs and speed. |
| 2025-10-30 20:37:03 | <haskellbridge> | <sm> by the way I'll guess those other build systems also use multiple processors, but probably they finish sooner |
| 2025-10-30 20:37:08 | <omentic> | monochrom: re: memory, gulp |
| 2025-10-30 20:37:25 | × | peterbecich quits (~Thunderbi@172.222.148.214) (Ping timeout: 256 seconds) |
| 2025-10-30 20:38:43 | <haskellbridge> | <sm> also does swapping contribute to cpu activity / heat ? building haskell is probably using more memory |
| 2025-10-30 20:38:56 | <haskellbridge> | <sm> avoid swapping |
| 2025-10-30 20:39:34 | <omentic> | what is the -N argument to RTS opts? this page references it, but doesn't define it: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/runtime_control.html |
| 2025-10-30 20:40:10 | <omentic> | i do kind of wonder if fucked-up swap is contributing to only seeing this with cabal |
| 2025-10-30 20:40:28 | <omentic> | if it is using up a bunch of memory and swapping a lot... |
| 2025-10-30 20:40:28 | <haskellbridge> | <sm> you should definitely check, with [h]top |
| 2025-10-30 20:40:40 | → | Googulator98 joins (~Googulato@2a01-036d-0106-03fa-9dbb-a0af-2124-a319.pool6.digikabel.hu) |
| 2025-10-30 20:40:45 | × | Googulator55 quits (~Googulato@2a01-036d-0106-03fa-9dbb-a0af-2124-a319.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-30 20:41:11 | <haskellbridge> | <sm> +RTS -N is essentially a suggestion of how many cores the program should use, IIRC. But for cabal commands, -j is easier |
| 2025-10-30 20:42:25 | <monochrom> | Telling cabal -N does not limit its -j |
| 2025-10-30 20:42:42 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-10-30 20:45:41 | × | Googulator98 quits (~Googulato@2a01-036d-0106-03fa-9dbb-a0af-2124-a319.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-30 20:45:54 | → | Googulator98 joins (~Googulato@2a01-036d-0106-03fa-9dbb-a0af-2124-a319.pool6.digikabel.hu) |
| 2025-10-30 20:46:30 | × | L29Ah quits (~L29Ah@wikipedia/L29Ah) (Ping timeout: 256 seconds) |
| 2025-10-30 20:47:37 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-10-30 20:48:06 | → | myme1 joins (~myme@2a01:799:d5e:5f00:ffab:db87:b0e2:97dd) |
All times are in UTC.