2025/03/29

Newest at the top

2025-03-29 19:19:18 +0100tromp(~textual@2001:1c00:3487:1b00:9865:6ec1:d353:2dc8)
2025-03-29 19:10:37 +0100Smiles(uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2025-03-29 19:10:30 +0100jacopovalanzano(~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) (Ping timeout: 240 seconds)
2025-03-29 19:06:13 +0100Garbanzo(~Garbanzo@2602:304:6eac:dc10::2e)
2025-03-29 19:04:49 +0100ash3en(~Thunderbi@89.56.182.235) ash3en
2025-03-29 19:04:15 +0100ColinRobinson(~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org))
2025-03-29 19:02:16 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-03-29 19:01:16 +0100JuanDaughertyColinRobinson
2025-03-29 18:56:45 +0100tromp(~textual@2001:1c00:3487:1b00:9865:6ec1:d353:2dc8) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-03-29 18:52:30 +0100 <srk> works like a charm, impressive
2025-03-29 18:51:50 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-03-29 18:46:28 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-03-29 18:45:10 +0100digitteknohippieDigit
2025-03-29 18:44:53 +0100Digitdigitteknohippie
2025-03-29 18:44:10 +0100 <srk> type safe electricity consumption analysis ^^
2025-03-29 18:42:47 +0100 <srk> anyway, it works now \o/ hope it keeps working when I connect it to the modbus meter
2025-03-29 18:42:04 +0100peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich
2025-03-29 18:40:53 +0100 <srk> interesting, now I'm tempted to try on armv7 and aarch64 with more cores as well
2025-03-29 18:39:41 +0100 <int-e> so GHC did indeed not link against the threaded RTS
2025-03-29 18:39:03 +0100 <srk> no, it doesn't
2025-03-29 18:37:07 +0100 <int-e> you could check the output of <executable> +RTS --info and see if the "RTS way" contains "thr" or not.
2025-03-29 18:36:19 +0100zmt01(~zmt00@user/zmt00) (Ping timeout: 260 seconds)
2025-03-29 18:36:17 +0100 <monochrom> Actually IIRC I disagreed how they framed it as vulnerabilities but meh who am I.
2025-03-29 18:35:34 +0100 <srk> indeed
2025-03-29 18:35:25 +0100 <int-e> And GHC really ought to complain about -threaded in that case.
2025-03-29 18:35:24 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds)
2025-03-29 18:35:07 +0100 <int-e> But maybe there is no threaded runtime for armv6l? Well that sounds... weird.
2025-03-29 18:34:41 +0100 <monochrom> Pretty sure I can demand -N1000 even if I only have 4.
2025-03-29 18:34:39 +0100 <srk> yeah, that helped. fun!
2025-03-29 18:34:27 +0100 <srk> got this error trying to run the thing, trying to drop the -N now
2025-03-29 18:34:25 +0100 <int-e> I don't think the number of cores matters
2025-03-29 18:34:09 +0100 <srk> but this is armv6l (pi1) with only one core
2025-03-29 18:34:08 +0100 <monochrom> Hrm then I don't know!
2025-03-29 18:34:05 +0100zmt00(~zmt00@user/zmt00) zmt00
2025-03-29 18:33:53 +0100 <srk> ye, I have -threaded -rtsopts -with-rtsopts=-N
2025-03-29 18:33:52 +0100 <monochrom> It is non-default because some RTS options become vulnerabilities.
2025-03-29 18:33:42 +0100 <int-e> you need -threaded to enabled -N
2025-03-29 18:33:38 +0100Digit(~user@user/digit) Digit
2025-03-29 18:33:26 +0100 <monochrom> You need to enable RTS options at all at compile time (more precisely link time), e.g., ghc -rtsopts
2025-03-29 18:32:43 +0100 <srk> unknown RTS option: -N :)) is that because the system has only a single core or llvm?
2025-03-29 18:32:31 +0100 <monochrom> I would write "case thing of Just x -> ... Nothing -> ..." explicitly.
2025-03-29 18:31:03 +0100acidjnk(~acidjnk@p200300d6e71c4f5684d81f92e812b9d0.dip0.t-ipconnect.de) acidjnk
2025-03-29 18:29:25 +0100 <JuanDaugherty> *lang
2025-03-29 18:28:57 +0100 <JuanDaugherty> i am just getting that optics make visible/accessible stuff which in a conventional imperative land u'd just put someplace
2025-03-29 18:26:24 +0100 <int-e> (Or maybe `Just x <- pure thing`)
2025-03-29 18:26:02 +0100 <int-e> I mean if you just need `fail`, shouldn't `Just x <- thing` actually work? The resulting error message will be horrible though.
2025-03-29 18:24:18 +0100 <enikar> readP and megaparsec have pfail, which is sometimes useful.
2025-03-29 18:24:06 +0100 <int-e> Hmm I'm trying to understand in what the "wrong monad" is in this context.
2025-03-29 18:23:17 +0100 <enikar> hum… I wonder it can be use in this case. Often I rewrote the parser in another way.
2025-03-29 18:22:12 +0100 <int-e> but there's no "abort the parse if this happens, even if there are more alternatives to try"