| 2024-09-21 00:02:32 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 00:04:07 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-21 00:07:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 00:09:19 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-09-21 00:10:22 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 00:10:24 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) |
| 2024-09-21 00:11:03 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-21 00:12:26 +0200 | talismanick | (~user@2601:644:937c:ed10::ae5) |
| 2024-09-21 00:13:51 +0200 | neuroevolutus | (~neuroevol@37.19.200.139) (Ping timeout: 256 seconds) |
| 2024-09-21 00:16:39 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-09-21 00:18:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 00:19:06 +0200 | mikess | (~mikess@user/mikess) |
| 2024-09-21 00:20:31 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-09-21 00:23:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 00:24:56 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) |
| 2024-09-21 00:31:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 00:35:43 +0200 | ell | (~ellie@user/ellie) (Quit: Ping timeout (120 seconds)) |
| 2024-09-21 00:36:05 +0200 | ell | (~ellie@user/ellie) |
| 2024-09-21 00:36:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 00:37:40 +0200 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-09-21 00:39:05 +0200 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) |
| 2024-09-21 00:42:45 +0200 | mikess | (~mikess@user/mikess) (Quit: mikess) |
| 2024-09-21 00:46:25 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 00:47:24 +0200 | mikess | (~mikess@user/mikess) |
| 2024-09-21 00:47:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 00:52:33 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-09-21 00:52:42 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 00:54:16 +0200 | <Inst> | monochrom: |
| 2024-09-21 00:54:23 +0200 | <Inst> | sorry, here's how to show the behavior |
| 2024-09-21 00:54:26 +0200 | <Inst> | import Debug.Trace |
| 2024-09-21 00:55:37 +0200 | <Inst> | x <|>> y = traceWith (\u -> show u <> " was evaluated on the left") x <|> y |
| 2024-09-21 00:55:46 +0200 | <Inst> | Just 3 <|>> Nothing <|>> Nothing |
| 2024-09-21 00:56:30 +0200 | <Inst> | also, I just discovered you can declare operators in function arguments |
| 2024-09-21 00:57:49 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 01:03:06 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2024-09-21 01:03:29 +0200 | <Inst> | > with (****) a b = a **** b |
| 2024-09-21 01:03:31 +0200 | <lambdabot> | <hint>:1:17: error: parse error on input ‘=’ |
| 2024-09-21 01:03:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 01:03:54 +0200 | <Inst> | well, it works in 9.10 ghci :( |
| 2024-09-21 01:08:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 01:08:45 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) |
| 2024-09-21 01:09:00 +0200 | <Inst> | tomsmeding: you CAN stylistically decide to use >>= to make the data flow more obvious, afaik everyone decided to just write functional python with do and <- instead |
| 2024-09-21 01:09:27 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 01:09:52 +0200 | <monochrom> | do-notation still desugars to right-associative uses of >>= |
| 2024-09-21 01:12:47 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) (Remote host closed the connection) |
| 2024-09-21 01:12:55 +0200 | <monochrom> | It is fair to say that infixr is better for >>, <|>, >=> in most use cases, and the standard library made the wrong choice. |
| 2024-09-21 01:13:07 +0200 | <monochrom> | But this is getting blown out of proportion. |
| 2024-09-21 01:13:11 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) |
| 2024-09-21 01:13:57 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-09-21 01:18:07 +0200 | <monochrom> | Not to mention that "foo <|> (bar <|> x)" is not that hard to write if you find the infixl unsatisfactory. |
| 2024-09-21 01:18:38 +0200 | <Inst> | ehhh, just pointing out infelicities, it's not a big deal tbh |
| 2024-09-21 01:18:47 +0200 | <Inst> | it's a good reason not to abuse >>= and =<< for golfing |
| 2024-09-21 01:19:01 +0200 | <monochrom> | "Does >>= leak?" is not making a big fuzz? |
| 2024-09-21 01:19:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 01:19:52 +0200 | <Inst> | i suppose i should apologize for "baby's first exposure to thinking space and spaceleaks with laziness", but it would do no good |
| 2024-09-21 01:20:27 +0200 | <Inst> | that said, just out of curiosity, when do you introduce Debug.Trace, monochrom? |
| 2024-09-21 01:24:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 01:25:18 +0200 | <monochrom> | Being novice in technical matters is not the issue I'm complaining about. |
| 2024-09-21 01:25:57 +0200 | <monochrom> | The dark pattern of always going hyperbole is. |
| 2024-09-21 01:26:35 +0200 | <Inst> | criticism acknowledged |
| 2024-09-21 01:32:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 01:36:14 +0200 | Squared | (~Square@user/square) |
| 2024-09-21 01:37:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 01:43:16 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 01:43:39 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb13044e7157fd3ef949.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-09-21 01:46:32 +0200 | Oxf1ac | (~0xf1ac@62.4.42.168) (Quit: WeeChat 4.4.2) |
| 2024-09-21 01:48:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 01:49:18 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2024-09-21 01:50:07 +0200 | <Inst> | monochrom: I should have been more careful in wording and asked whether >>= leaks in direct use, i'm still pouring over GHC core output to check whether or not it does on O2 or higher optimizations |
| 2024-09-21 01:50:23 +0200 | <Inst> | and yeah i'm aware of the () desugaring of do |
| 2024-09-21 01:52:17 +0200 | <Inst> | the other realistic issue is, that from what i've seen, thinking lazily isn't prioritized in most haskell books i've seen, and there's been commercial users of haskell that've dropped Haskell because they weren't proficient in laziness |
| 2024-09-21 01:53:27 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 01:53:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 01:58:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-21 01:58:10 +0200 | <Inst> | also, another question |
| 2024-09-21 01:58:36 +0200 | <Inst> | actually, forget it, maybe another time |
| 2024-09-21 02:04:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 02:04:40 +0200 | <probie> | You can evaluate that question thunk at a later time |
| 2024-09-21 02:06:35 +0200 | <Inst> | it's more like weirdness with GHCI, possibly not an issue with ghc |
| 2024-09-21 02:07:13 +0200 | <Inst> | if i bang a let declaration in a do block, do traceShowId over a number, it doesn't evaluate, if I traceShowId something else, it evaluates |
| 2024-09-21 02:07:53 +0200 | <Inst> | it looks like it's wonkiness related to default types, because if I affix a type annotation, it evaluates |
| 2024-09-21 02:09:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 02:10:09 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 02:15:52 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-21 02:20:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 02:22:56 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) |
| 2024-09-21 02:25:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-21 02:32:20 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-09-21 02:33:59 +0200 | califax | (~califax@user/califx) |
| 2024-09-21 02:36:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 02:40:52 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 02:51:51 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 02:53:19 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-09-21 02:55:07 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-21 02:56:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 03:04:01 +0200 | <cheater> | what |
| 2024-09-21 03:07:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 03:12:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 03:21:40 +0200 | pavonia | (~user@user/siracusa) |
| 2024-09-21 03:22:55 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-09-21 03:23:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 03:24:54 +0200 | Oxf1ac | (~Oxf1ac@62.4.42.168) |
| 2024-09-21 03:27:36 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-09-21 03:28:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 03:30:16 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
| 2024-09-21 03:35:38 +0200 | Oxf1ac | (~Oxf1ac@62.4.42.168) (WeeChat 4.4.2) |
| 2024-09-21 03:35:54 +0200 | gvg_ | (~dcd@user/gvg) |
| 2024-09-21 03:36:58 +0200 | gvg | (~dcd@user/gvg) (Ping timeout: 252 seconds) |
| 2024-09-21 03:39:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 03:44:19 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 03:44:57 +0200 | Fijxu_ | (~Fijxu@user/fijxu) (Ping timeout: 252 seconds) |
| 2024-09-21 03:48:37 +0200 | <probie> | % do{let {!x=trace "Hello" 42}; putStrLn "World"} |
| 2024-09-21 03:48:37 +0200 | <yahb2> | World |
| 2024-09-21 03:48:45 +0200 | <probie> | % do{let {!x=trace "Hello" (42 :: Int)}; putStrLn "World"} |
| 2024-09-21 03:48:45 +0200 | <yahb2> | Hello ; World |
| 2024-09-21 03:48:59 +0200 | Fijxu | (~Fijxu@user/fijxu) |
| 2024-09-21 03:49:00 +0200 | <probie> | That isn't type defaulting |
| 2024-09-21 03:49:20 +0200 | <probie> | % do{let {x=trace "Hello" (42 :: Int)}; x `seq` putStrLn "World"} |
| 2024-09-21 03:49:20 +0200 | <yahb2> | Hello ; World |
| 2024-09-21 03:49:30 +0200 | <probie> | % do{let {x=trace "Hello" 42}; x `seq` putStrLn "World"} |
| 2024-09-21 03:49:30 +0200 | <yahb2> | Hello ; World |
| 2024-09-21 03:51:12 +0200 | <probie> | It's that `x` has type `Num a => a`, which is "pretty much" a function, and therefore already in WHNF since it's a lambda |
| 2024-09-21 03:54:12 +0200 | Squared | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2024-09-21 03:54:20 +0200 | <Inst> | thanks probie |
| 2024-09-21 03:54:33 +0200 | <Inst> | but if you do this on ghc, it works |
| 2024-09-21 03:55:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 03:55:17 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-09-21 03:55:19 +0200 | <geekosaur> | in a sense that is defaulting |
| 2024-09-21 03:56:27 +0200 | <geekosaur> | ghci has NoMonomorphismRestriction, so it doesn't resolve things like (Num a => a) immediately. ghc doesn't, so it gets defaulted to Int and is no longer a function taking a Num dictionary |
| 2024-09-21 03:56:30 +0200 | Guest19 | (~Guest57@syn-075-131-084-201.res.spectrum.com) |
| 2024-09-21 03:57:14 +0200 | <geekosaur> | if you compile with -XNoMonomorphismRestriction, you should get the same behavior as ghci |
| 2024-09-21 03:58:03 +0200 | <geekosaur> | if you run it in "ghci -XMonomorphismRestriction", you should get the same behavior as ghc |
| 2024-09-21 03:59:57 +0200 | Guest19 | (~Guest57@syn-075-131-084-201.res.spectrum.com) (Client Quit) |
| 2024-09-21 03:59:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-21 04:02:33 +0200 | <Inst> | thanks geekosaur |
| 2024-09-21 04:03:42 +0200 | <geekosaur> | this kind of confusion is more or less why the monomorphism restriction exists and is the default; x there "looks like" a value, but without the MMR it's actually a function |
| 2024-09-21 04:04:15 +0200 | <Inst> | also, curious, can you still get unsafePerformIO to segfault with the example code? |
| 2024-09-21 04:04:38 +0200 | <geekosaur> | I saw you bring that up in #ghc but I haven't lookmed |
| 2024-09-21 04:05:01 +0200 | <Inst> | it's weird, but probably why it's just unsafe, i.e, might be platform specific |
| 2024-09-21 04:05:49 +0200 | <Inst> | thanks anyways |
| 2024-09-21 04:06:00 +0200 | <Inst> | I used to get it to crash, but I guess that's why it's unsafe |
| 2024-09-21 04:06:08 +0200 | <Inst> | undefined behavior depending on platform and kernel version |
| 2024-09-21 04:07:25 +0200 | <geekosaur> | I think the example code was "broken" by ghc's runtime representations changing in 8.10.5+ to support Apple AArch64 |
| 2024-09-21 04:07:40 +0200 | <geekosaur> | but that's just a suspicion |
| 2024-09-21 04:07:46 +0200 | <geekosaur> | (it didn't core here) |
| 2024-09-21 04:07:52 +0200 | <Inst> | i swapped to 8.x via ghcup |
| 2024-09-21 04:08:55 +0200 | <Inst> | still fails to crash, I suspect it's something to do with linux kernel updates |
| 2024-09-21 04:09:25 +0200 | <geekosaur> | keep in mind that I'm on Ubuntu 22.04, so my kernel is practically ancient |
| 2024-09-21 04:11:59 +0200 | <Inst> | iirc it does crash in windows, but i sort of lost my windows drive :( |
| 2024-09-21 04:12:41 +0200 | <geekosaur> | the problem they're talking about can't be fixed as such (it might be made slightly less likely to happen in certain specific cases, but the general problem is not fixable) |
| 2024-09-21 04:13:05 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-21 04:13:35 +0200 | <geekosaur> | as the discussion says, if you have unsafePerformIO, you have unsafeCoerce and what happens if you use it as such will be up to the whim of the RTS |
| 2024-09-21 04:15:27 +0200 | <geekosaur> | the example code may now be too simplistic to demonstrate the problem, but I'm sure it won't need much tweaking to reveal it again |
| 2024-09-21 04:17:03 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 04:19:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-21 04:26:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:31:55 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-21 04:34:30 +0200 | td_ | (~td@i53870926.versanet.de) (Ping timeout: 246 seconds) |
| 2024-09-21 04:36:21 +0200 | td_ | (~td@i5387092D.versanet.de) |
| 2024-09-21 04:40:48 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2024-09-21 04:42:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:43:13 +0200 | <Inst> | this is weird |
| 2024-09-21 04:43:43 +0200 | <Inst> | 234288 unsafeCoerce-ed to System.IO.Handle gets you the crash I'm looking for |
| 2024-09-21 04:43:50 +0200 | <Inst> | but other integers don't produce the same effects |
| 2024-09-21 04:44:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Remote host closed the connection) |
| 2024-09-21 04:44:43 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-21 04:45:08 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 04:45:20 +0200 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-21 04:46:01 +0200 | <Inst> | okay, Integers (mostly) seem to produce the desired crash on unsafeCoerce to System.IO.Handle (using unsafePerformIO) |
| 2024-09-21 04:47:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 04:47:36 +0200 | terrorjack4 | (~terrorjac@static.48.15.202.116.clients.your-server.de) |
| 2024-09-21 04:49:43 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-21 04:53:12 +0200 | <geekosaur> | that's not too surprising, it very likely depends on the internal GMP representation |
| 2024-09-21 04:53:33 +0200 | <geekosaur> | that's more or less what you're inviting with unsafeCoerce in any form |
| 2024-09-21 04:54:05 +0200 | <Inst> | iirc it should be safe to use unsafePerformIO for read-only operations, right? as long as you ensure the write is done beforehand |
| 2024-09-21 04:54:26 +0200 | <Inst> | i'm more trying to figure out when it's safe to use unsafeCoerce |
| 2024-09-21 04:54:54 +0200 | <geekosaur> | even read-only is unsafe if you coerced an unboxed value into a boxed one |
| 2024-09-21 04:55:24 +0200 | <geekosaur> | because reading it will follow what it thinks is a pointer |
| 2024-09-21 04:55:50 +0200 | <geekosaur> | @quote monochrom unsafeCoerce.*Either |
| 2024-09-21 04:55:50 +0200 | <lambdabot> | monochrom says: isTrue = (unsafeCoerce :: Either a b -> Bool) . (unsafeCoerce :: Maybe c -> Either a b) . (unsafeCoerce :: Bool -> Maybe c) |
| 2024-09-21 04:56:50 +0200 | <geekosaur> | if (a) all types are boxed (b) all types have at least as many constructors as the starting type does, you can generally get away with it |
| 2024-09-21 04:56:51 +0200 | <Inst> | i mean without coercion in unsafePerformIO, i.e, a way to avoid passing large parameters around |
| 2024-09-21 04:57:34 +0200 | <geekosaur> | unsafePerformIO only matters insofar as it can give you a polymorphic IORef, which implicitly unsafeCoerces anything taken out of it |
| 2024-09-21 04:57:56 +0200 | <Inst> | iirc i used unsafePerformIO as an optimization pass |
| 2024-09-21 04:58:09 +0200 | <geekosaur> | it's the unsafeCoerce part, however you got it, that is problematic |
| 2024-09-21 04:58:10 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 04:58:44 +0200 | <Inst> | i thought the main reason unsafePerformIO was considered unsafe was because Haskell gives very weak guarantees on evaluation order of pure functions? |
| 2024-09-21 04:58:56 +0200 | <geekosaur> | and re "large parameters", if they are boxed, you're passing a pointer |
| 2024-09-21 04:59:08 +0200 | <geekosaur> | if they're unboxed, you need to rethink your design |
| 2024-09-21 04:59:36 +0200 | <Inst> | weird because it was boxed, and I was using monomorphic IORef and got a performance improvement |
| 2024-09-21 05:00:00 +0200 | <geekosaur> | not really. if you want that level of unsafety, you want accursedUnutterablePerformIO (that is, inlining runRW#) |
| 2024-09-21 05:02:06 +0200 | <geekosaur> | unsafePerformIO will reveal to you when things are evaluated (on demand aka "lazily") but won't in general cause evaluation order issues otherwise |
| 2024-09-21 05:02:32 +0200 | <geekosaur> | at least, not any more than multithreaded access to the same resource will |
| 2024-09-21 05:03:14 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 05:03:47 +0200 | <geekosaur> | con template Debug.Trace, which uses unsafePerformIO under the hood |
| 2024-09-21 05:04:40 +0200 | <Inst> | ehhh, unsafePerformIO sort of breaks the entire haskell programming model, doesn't it? |
| 2024-09-21 05:04:44 +0200 | <Inst> | since you can now run IO anywhere |
| 2024-09-21 05:05:17 +0200 | <geekosaur> | if you get a performance improvement from an IORef, I would first suspect you had thunk buildup that the IORef was causing to be forced |
| 2024-09-21 05:06:11 +0200 | <Inst> | probably, sigh |
| 2024-09-21 05:06:33 +0200 | <Inst> | also, by the way, do I finally get monads now that I'm thinking in terms of monadic typeclasses? |
| 2024-09-21 05:06:51 +0200 | <geekosaur> | actually, no, you can't. that;s not what unsafePerformIO is. unsafePerformIO is "hey compiler, I promise you that this is actually pure ". at which point it is evaluated on demand instead of forcing evaluation |
| 2024-09-21 05:06:56 +0200 | <Inst> | as in, Constraint m => m a type actions |
| 2024-09-21 05:07:14 +0200 | <geekosaur> | not all constraints are monads |
| 2024-09-21 05:07:45 +0200 | <geekosaur> | what if the constraint is Functor? |
| 2024-09-21 05:07:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 05:08:24 +0200 | <Inst> | i know, but what I mean is that using monadic / applicative polymorphism to write actions such that it's the type that forces the actual codepath |
| 2024-09-21 05:09:02 +0200 | <Inst> | hence the old canard about "computation in a context" |
| 2024-09-21 05:09:04 +0200 | <geekosaur> | mmm, I'd say that's more about "free monad"? |
| 2024-09-21 05:09:11 +0200 | <geekosaur> | which is a subset of monads |
| 2024-09-21 05:09:51 +0200 | <geekosaur> | that said, I'm operating on 3h of sleep and it's getting late here so I may be blathering at this point 😞 |
| 2024-09-21 05:12:00 +0200 | <Inst> | i'm blathering at all times, go to bed, geekosaur, it's friday :) |
| 2024-09-21 05:12:33 +0200 | <geekosaur> | gotta wait for my nighttime drugs to kick in (in particular the painkillers, sigh) |
| 2024-09-21 05:13:53 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-09-21 05:13:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 05:14:01 +0200 | <Inst> | i'm sorry to hear :( |
| 2024-09-21 05:14:10 +0200 | <Inst> | and that's sort of a giveaway :( |
| 2024-09-21 05:14:20 +0200 | <Inst> | also I guess I was talking about mtl style |
| 2024-09-21 05:16:16 +0200 | <geekosaur> | effect systems do the same thing, they just get there via a different path |
| 2024-09-21 05:18:24 +0200 | <Inst> | what's the exact name for constraint-based polymorphic effects? |
| 2024-09-21 05:18:36 +0200 | <geekosaur> | beats me 🙂 |
| 2024-09-21 05:18:48 +0200 | <Inst> | iirc it was mentioned it's useful for mocking, but i can't figure out other contexts where the effect polymorphism is useful |
| 2024-09-21 05:19:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 05:19:16 +0200 | <geekosaur> | swapping out effect providers |
| 2024-09-21 05:19:29 +0200 | <Inst> | i realize i had a large chunk of code, and it was problematic because i couldn't redirect stdout trivially |
| 2024-09-21 05:19:34 +0200 | <geekosaur> | for example, switching logging frameworks |
| 2024-09-21 05:20:43 +0200 | <geekosaur> | (this is not the problem I have with effect systems. the problem I have with them is that they will happily let you "algebraically" combine effects that mtl will rightly reject because they're not safe to combine) |
| 2024-09-21 05:20:45 +0200 | <dolio> | unsafeCoercing between boxed values, even if you think they should be represented 'the same' is not something you can generally get away with, in my experience. |
| 2024-09-21 05:21:05 +0200 | <dolio> | Boxed values of different types, that is. |
| 2024-09-21 05:21:12 +0200 | <geekosaur> | I provided a more specific rule earlier |
| 2024-09-21 05:21:24 +0200 | <geekosaur> | even used monochrom's quote to demonstrate 🙂 |
| 2024-09-21 05:26:36 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-21 05:26:55 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-09-21 05:27:20 +0200 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-09-21 05:29:17 +0200 | bilegeek | (~bilegeek@227.sub-174-208-228.myvzw.com) (Quit: Leaving) |
| 2024-09-21 05:29:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 05:34:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 05:35:45 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2024-09-21 05:37:14 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-09-21 05:41:31 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-09-21 05:45:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 05:46:49 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
| 2024-09-21 05:50:23 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-21 05:50:27 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 05:54:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-21 05:58:50 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-21 06:01:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 06:04:05 +0200 | xff0x | (~xff0x@2405:6580:b080:900:64be:ce6a:a0a8:1563) (Ping timeout: 248 seconds) |
| 2024-09-21 06:04:23 +0200 | xff0x | (~xff0x@2405:6580:b080:900:64be:ce6a:a0a8:1563) |
| 2024-09-21 06:06:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 06:06:12 +0200 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) |
| 2024-09-21 06:17:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 06:21:57 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 06:23:46 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 06:28:11 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-09-21 06:28:14 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
| 2024-09-21 06:30:26 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) |
| 2024-09-21 06:34:20 +0200 | benjaminl | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2024-09-21 06:34:36 +0200 | benjaminl | (~benjaminl@user/benjaminl) |
| 2024-09-21 06:48:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 06:53:27 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 06:53:29 +0200 | hammond | (proscan@gateway04.insomnia247.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 06:54:33 +0200 | terrorjack4 | (~terrorjac@static.48.15.202.116.clients.your-server.de) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-21 06:55:31 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) (Remote host closed the connection) |
| 2024-09-21 06:57:21 +0200 | terrorjack4 | (~terrorjac@2a01:4f8:c17:dc9f::) |
| 2024-09-21 07:01:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 07:07:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 07:09:03 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 07:13:51 +0200 | <Inst> | by the way, am i really not understanding arrows? |
| 2024-09-21 07:14:39 +0200 | <Inst> | getLine >>= (<$) <*> putStrLn >>= putStrLn is a shoddy mess |
| 2024-09-21 07:15:06 +0200 | <Inst> | but so's getLine >>= runKleisli (Kleisli putStrLn &&& Kleisli putStrLn) |
| 2024-09-21 07:15:41 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds) |
| 2024-09-21 07:15:45 +0200 | <Inst> | arr is Kleisli . (pure . f) ffs |
| 2024-09-21 07:16:56 +0200 | <Inst> | getLine >>= ((>>) . putStrLn) <*> putStrLn is only slightly better |
| 2024-09-21 07:17:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 07:23:04 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 07:25:05 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) (Ping timeout: 256 seconds) |
| 2024-09-21 07:26:05 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-09-21 07:28:20 +0200 | mikess | (~mikess@user/mikess) (Ping timeout: 252 seconds) |
| 2024-09-21 07:30:25 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-09-21 07:32:00 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-21 07:32:37 +0200 | euphores | (~SASL_euph@user/euphores) (Max SendQ exceeded) |
| 2024-09-21 07:33:14 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-21 07:33:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 07:38:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 07:45:21 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 07:49:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 07:50:07 +0200 | hammond | (proscan@gateway04.insomnia247.nl) |
| 2024-09-21 07:52:31 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2024-09-21 07:54:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 08:02:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 08:06:48 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 08:07:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-21 08:07:32 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-09-21 08:09:29 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-21 08:10:01 +0200 | CrunchyFlakes | (~CrunchyFl@ip1f13e94e.dynamic.kabel-deutschland.de) |
| 2024-09-21 08:12:04 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-09-21 08:15:25 +0200 | <Inst> | for that problem |
| 2024-09-21 08:15:46 +0200 | <Inst> | getLine >>= for_ [putStrLn, putStrLn] . (&) works better |
| 2024-09-21 08:16:41 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-09-21 08:18:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 08:18:05 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) |
| 2024-09-21 08:21:40 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-21 08:22:58 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 08:26:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 08:31:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 264 seconds) |
| 2024-09-21 08:33:23 +0200 | Me-me | (~me-me@kc.randomserver.name) (Read error: Connection reset by peer) |
| 2024-09-21 08:33:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 08:34:45 +0200 | Me-me | (~me-me@kc.randomserver.name) |
| 2024-09-21 08:38:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 08:41:12 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 08:44:48 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 08:49:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 08:49:58 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2024-09-21 08:54:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 08:59:09 +0200 | <geekosaur> | Inst, Arrows are mostly a failed experiment |
| 2024-09-21 08:59:29 +0200 | <geekosaur> | but they gave rise to Profunctor and Applicative |
| 2024-09-21 08:59:45 +0200 | <geekosaur> | however there are some FRP frameworks based on Arrows |
| 2024-09-21 09:00:01 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-09-21 09:00:02 +0200 | <geekosaur> | some of which have proposed modified versions of Arrow |
| 2024-09-21 09:00:18 +0200 | JamesMowery | (~JamesMowe@ip98-167-207-182.ph.ph.cox.net) (Quit: Goodbye) |
| 2024-09-21 09:00:37 +0200 | caconym | (~caconym@user/caconym) |
| 2024-09-21 09:00:45 +0200 | JamesMowery | (~JamesMowe@ip98-167-207-182.ph.ph.cox.net) |
| 2024-09-21 09:02:40 +0200 | <geekosaur> | I think the original idea was abstraction over composition, that is, normal functions and monadic functions (wrapped in Kleisli) can be composed in the same way in an Arrow framework |
| 2024-09-21 09:03:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 09:03:17 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 248 seconds) |
| 2024-09-21 09:03:39 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2024-09-21 09:03:52 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2024-09-21 09:04:26 +0200 | <geekosaur> | but it turned out that there was no real point in unifying (.) and (>=>), and while Arrow has the potential for static analysis, `arr` severely restricts what you can do with it |
| 2024-09-21 09:05:19 +0200 | <geekosaur> | (sorry, `flip (.)`) |
| 2024-09-21 09:06:59 +0200 | <ski> | `arr' should be moved to a subclass |
| 2024-09-21 09:08:03 +0200 | <geekosaur> | I have so far heard 3 proposals for how Arrow should be reworked |
| 2024-09-21 09:08:11 +0200 | <geekosaur> | none of them seems to have much traction |
| 2024-09-21 09:08:18 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 09:08:57 +0200 | <geekosaur> | and I'm not sure any of them is compatible with the few existing users of Arrow (e.g. Yampa) |
| 2024-09-21 09:10:17 +0200 | <ski> | didn't conal have some work on compiling categorical stuff ? |
| 2024-09-21 09:10:34 +0200 | <geekosaur> | "Compiling to Categories"? |
| 2024-09-21 09:11:29 +0200 | <ski> | probably, yeah |
| 2024-09-21 09:12:48 +0200 | <geekosaur> | but he went straight to Control.Category in the paper I dug up |
| 2024-09-21 09:13:53 +0200 | <ski> | maybe we need `proc' notation that uses that |
| 2024-09-21 09:14:30 +0200 | <geekosaur> | (he used a plugin) |
| 2024-09-21 09:17:46 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 09:19:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 09:22:05 +0200 | <Inst> | geekosaur: you're STILl in pain? :( |
| 2024-09-21 09:22:48 +0200 | <Inst> | since i thought you went to sleep |
| 2024-09-21 09:23:09 +0200 | <geekosaur> | my sleep has been severely disturbed for longer than I've had the neck/arm issue |
| 2024-09-21 09:23:24 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-09-21 09:23:26 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:6c44:9933:28ff:d264) (Remote host closed the connection) |
| 2024-09-21 09:23:36 +0200 | <geekosaur> | it's absolutely not unusual that I wake up 02:30-03:00 and am up for an hour or so 😞 |
| 2024-09-21 09:23:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 09:24:06 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:eb82:e687:8bae:8fb3) |
| 2024-09-21 09:24:06 +0200 | <Inst> | by the way, if I want to model an HTML object, is vector or seq a better application data structure for children / attributes? |
| 2024-09-21 09:24:31 +0200 | <tomsmeding> | Inst: will you be appending to that list |
| 2024-09-21 09:24:43 +0200 | <Inst> | yes, which is why i'm thinking seq not vector |
| 2024-09-21 09:24:54 +0200 | <tomsmeding> | i.e. what's the ratio between the number of times you read that list, and the number of times you modify it |
| 2024-09-21 09:24:58 +0200 | <Inst> | i guess i'm doing yet another html / css library |
| 2024-09-21 09:25:20 +0200 | <geekosaur> | cue xkcd 😛 |
| 2024-09-21 09:25:23 +0200 | <Inst> | well, i mean, it'll be converted to lazy bytestring |
| 2024-09-21 09:25:35 +0200 | <tomsmeding> | if you can arrange to always append at the front, and don't need to index into the thing, plain [] may be best |
| 2024-09-21 09:25:48 +0200 | <geekosaur> | that's what I was thinking |
| 2024-09-21 09:25:54 +0200 | <Inst> | wait, can you edit / replace Blaze / Lucid HTML types once they've been generated? |
| 2024-09-21 09:25:59 +0200 | <geekosaur> | but it definitely depends on what uou're doing |
| 2024-09-21 09:26:53 +0200 | <Inst> | iirc blaze and lucid are builders |
| 2024-09-21 09:27:07 +0200 | <tomsmeding> | bonus points if you ensure that client code can only treat the thing as a Monoid, so that you can swap out the implementation later :) |
| 2024-09-21 09:27:09 +0200 | <Inst> | https://hackage.haskell.org/package/type-of-html |
| 2024-09-21 09:29:00 +0200 | <Inst> | well, i have no idea what i'm doing, i think implementing ADTs for HTML / CSS will probably help me learn HTML / CSS better, and when this stuff falls through, I'll just rewrite the library |
| 2024-09-21 09:29:08 +0200 | <Inst> | already have a friend lined up to help me maintain it |
| 2024-09-21 09:29:31 +0200 | geekosaur | is having a "that trick never works!" moment |
| 2024-09-21 09:29:46 +0200 | <tomsmeding> | I feel like coding up representations of html/css will help you very well in learning the syntax of them both |
| 2024-09-21 09:29:50 +0200 | <Inst> | whatever, I'll just use list then then change the datatypes later! |
| 2024-09-21 09:29:55 +0200 | <tomsmeding> | which is like the easiest and least interesting part :) |
| 2024-09-21 09:29:56 +0200 | <Inst> | thanks tomsmeding |
| 2024-09-21 09:30:10 +0200 | <geekosaur> | (well, I nsuppose an ADT doesn't necessarily imply a structure) |
| 2024-09-21 09:30:16 +0200 | <Inst> | yeah, well, finally get out of vaporware, actually build something useful in the Haskell ecosystem instead of being a semi-tolerated troll |
| 2024-09-21 09:30:24 +0200 | <Inst> | and then go rework it once I have some idea of what I'm doing |
| 2024-09-21 09:30:33 +0200 | <tomsmeding> | css gets really complicated in how all the properties interact, e.g. how css Grid interacts with other layout stuff |
| 2024-09-21 09:30:37 +0200 | <tomsmeding> | or how the whole box model works |
| 2024-09-21 09:31:04 +0200 | <tomsmeding> | does a box shadow count as size of the element or not? Does the border? (depends on the border-box property) |
| 2024-09-21 09:31:07 +0200 | <geekosaur> | welp. going to be up a while longer, I guess |
| 2024-09-21 09:31:13 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-09-21 09:31:16 +0200 | <geekosaur> | fire engines just pulled up |
| 2024-09-21 09:31:21 +0200 | <tomsmeding> | O.o |
| 2024-09-21 09:31:38 +0200 | <tomsmeding> | nearby? |
| 2024-09-21 09:31:39 +0200 | <geekosaur> | either the building fire alarm misfired again, or someone's stuck in the elevator again |
| 2024-09-21 09:31:44 +0200 | <tomsmeding> | ah |
| 2024-09-21 09:32:04 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:eb82:e687:8bae:8fb3) (Read error: Connection reset by peer) |
| 2024-09-21 09:32:46 +0200 | <geekosaur> | …and one of the engines just turned around and left. that usually takes longer if it's the building fire alarm |
| 2024-09-21 09:33:06 +0200 | <geekosaur> | so maybe (c) someone called 911 in a panic and they just sent everything |
| 2024-09-21 09:33:09 +0200 | <tomsmeding> | re css, also the whole priority ordering of rules |
| 2024-09-21 09:33:19 +0200 | <geekosaur> | akron's weird that way |
| 2024-09-21 09:33:41 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-09-21 09:34:17 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-21 09:34:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 09:36:25 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 09:40:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-21 09:41:13 +0200 | <tomsmeding> | I would imagine that happens in lots of places, sometimes |
| 2024-09-21 09:48:35 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2024-09-21 09:50:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 09:52:56 +0200 | <Inst> | is it a good or bad thing that Haskell matches so many of my neuroses? |
| 2024-09-21 09:53:12 +0200 | <Inst> | like, I like planning too much, doing too little |
| 2024-09-21 09:53:50 +0200 | <tomsmeding> | it means that you should watch out for overfitting :) |
| 2024-09-21 09:53:53 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb631d346e810a542001.dip0.t-ipconnect.de) |
| 2024-09-21 09:54:01 +0200 | <tomsmeding> | (to a software development style) |
| 2024-09-21 09:55:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 09:56:54 +0200 | <tomsmeding> | Inst: ooof https://hackage.haskell.org/package/type-of-html-1.6.2.0/docs/src/Html.Type.Internal.html#line-1408 |
| 2024-09-21 09:56:59 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-09-21 09:57:52 +0200 | <Inst> | someone should have used template Haskell there |
| 2024-09-21 09:58:11 +0200 | <tomsmeding> | well it's not _too_ bad |
| 2024-09-21 09:58:18 +0200 | <tomsmeding> | and the list doesn't necessarily have to be any longer, maybe |
| 2024-09-21 09:58:26 +0200 | <tomsmeding> | but beautiful it is not :p |
| 2024-09-21 09:58:30 +0200 | <Inst> | I just brought up the library as something close to what I wanted, I'm just doing straight ADT (without fancy type mechanics) until I get the hang of things, but it's annoying how I can't use subtypes etc |
| 2024-09-21 09:59:46 +0200 | <tomsmeding> | type classes can give you kind of the dual of that, "sub-behaviours"? |
| 2024-09-21 10:00:45 +0200 | <tomsmeding> | i.e. if the more general behaviour is a superclass of the more specific one, then any type that implements the specfic behaviour will be implicitly known to also implement the more general behaviour |
| 2024-09-21 10:01:16 +0200 | <tomsmeding> | which is analogous to subtyping in OOP, where a specfic object is also implicitly a more general object |
| 2024-09-21 10:01:47 +0200 | <tomsmeding> | (if you don't need the "implicit" part, you can just use what OOP calls "composition", i.e. just put the parent object in a field of the child object) |
| 2024-09-21 10:02:43 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 10:02:43 +0200 | <tomsmeding> | (which is also how all of the implicit techniques are implemented; the compiler just knows about them and resolves references to the contained structure automagically) |
| 2024-09-21 10:02:44 +0200 | neuroevolutus | (~neuroevol@146.70.211.110) (Quit: Client closed) |
| 2024-09-21 10:04:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 10:07:52 +0200 | youthlic | (~Thunderbi@user/youthlic) (Quit: youthlic) |
| 2024-09-21 10:08:19 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 260 seconds) |
| 2024-09-21 10:09:06 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 10:09:30 +0200 | youthlic | (~Thunderbi@user/youthlic) |
| 2024-09-21 10:12:01 +0200 | gary_borg | (~gary_borg@144.6.194.76) |
| 2024-09-21 10:12:56 +0200 | <gary_borg> | why is haskelbridge my opp |
| 2024-09-21 10:13:04 +0200 | <gary_borg> | im confused with this app im new ot irc |
| 2024-09-21 10:13:09 +0200 | <gary_borg> | why is someone here my opp |
| 2024-09-21 10:13:12 +0200 | <gary_borg> | what did i do wronh |
| 2024-09-21 10:13:27 +0200 | <tomsmeding> | what do you mean with "opp"? |
| 2024-09-21 10:14:20 +0200 | <gary_borg> | opposition |
| 2024-09-21 10:14:36 +0200 | <gary_borg> | Opponent or Opposition |
| 2024-09-21 10:14:37 +0200 | <gary_borg> | Opp (Opponent or Opposition) "Opp" is a slang abbreviation of the word "opponent" or "enemy." It is commonly used to refer to someone who is viewed as an adversary or someone with whom one has a conflict or disagreement. |
| 2024-09-21 10:14:51 +0200 | <tomsmeding> | irc does not have a concept of "opposition", so not sure what you're referring to :) |
| 2024-09-21 10:15:40 +0200 | <Inst> | tomsmeding: tbh you're right, you could use typeclasses and existential types for that |
| 2024-09-21 10:16:06 +0200 | <tomsmeding> | Inst: existential types are almost never the right answer |
| 2024-09-21 10:16:28 +0200 | <tomsmeding> | sometimes they are, sure, but when modelling data, they usually bring more harm than good |
| 2024-09-21 10:17:23 +0200 | <Inst> | after touching julia, why yes, you can have an entire language made out of typeclasses (since implicitly in Julia every function is a typeclass) |
| 2024-09-21 10:17:25 +0200 | <gary_borg> | https://imgur.com/a/7GTqvrr this is what im referring to. |
| 2024-09-21 10:17:31 +0200 | <Inst> | just in Haskell it's a lot more wonky |
| 2024-09-21 10:17:59 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-09-21 10:18:00 +0200 | <tomsmeding> | gary_borg: ah lol |
| 2024-09-21 10:18:15 +0200 | <tomsmeding> | an "op" (not "opp") is an "operator", i.e. a user with admin rights on the channel |
| 2024-09-21 10:18:19 +0200 | <tomsmeding> | that user here is ChanServ |
| 2024-09-21 10:18:26 +0200 | Inst | (~Inst@user/Inst) (Leaving) |
| 2024-09-21 10:18:29 +0200 | Inst | (~Inst@user/Inst) |
| 2024-09-21 10:18:39 +0200 | <tomsmeding> | which is a bot from the irc server that mediates admin rights to the actual people having said access |
| 2024-09-21 10:19:29 +0200 | <ski> | (clearly operators are opposition, adversaries) |
| 2024-09-21 10:19:33 +0200 | <tomsmeding> | :D |
| 2024-09-21 10:19:47 +0200 | <gary_borg> | timtamspelling: oh ok ythank yo for choryfinning |
| 2024-09-21 10:20:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 10:21:22 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 10:24:21 +0200 | gary_borg | (~gary_borg@144.6.194.76) (Quit: Leaving) |
| 2024-09-21 10:24:45 +0200 | gary_borg | (~gary_borg@144.6.194.76) |
| 2024-09-21 10:25:04 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-09-21 10:25:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 10:25:28 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 244 seconds) |
| 2024-09-21 10:26:45 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-09-21 10:27:05 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2024-09-21 10:29:10 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-09-21 10:31:36 +0200 | <Inst> | tomsmeding: why are existential types a bad idea? |
| 2024-09-21 10:35:02 +0200 | <ski> | @where existential-antipattern |
| 2024-09-21 10:35:02 +0200 | <lambdabot> | "Haskell Antipattern: Existential Typeclass" by Luke Palmer at <https://web.archive.org/web/20220121105027/https://lukepalmer.wordpress.com/2010/01/24/haskell-ant…> |
| 2024-09-21 10:35:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 10:36:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 10:38:12 +0200 | gary_borg | (~gary_borg@144.6.194.76) (Killed (ozone (No Spam))) |
| 2024-09-21 10:40:20 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 10:40:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 10:42:13 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
| 2024-09-21 10:45:38 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-09-21 10:50:31 +0200 | <Inst> | oh fine, i'll do it the old fashioned way with a sum type :( |
| 2024-09-21 10:51:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 10:55:33 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-09-21 10:56:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 10:56:55 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 10:59:22 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 11:03:53 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-09-21 11:05:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 11:09:00 +0200 | srazkvt | (~sarah@user/srazkvt) |
| 2024-09-21 11:09:25 +0200 | srazkvt | (~sarah@user/srazkvt) (Client Quit) |
| 2024-09-21 11:10:16 +0200 | <tomsmeding> | Inst: what ski posted, but also just that they tend to make life more annoying while not actually helping much |
| 2024-09-21 11:10:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 11:11:44 +0200 | <tomsmeding> | mind you, exceptions exist, especially if your types have some GADT-like type parameters and you're doing some computations that cannot (or should not) be fully reflected on the type level |
| 2024-09-21 11:12:03 +0200 | <tomsmeding> | but if you're in that world, you tend to know it |
| 2024-09-21 11:20:50 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 255 seconds) |
| 2024-09-21 11:21:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 11:26:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 11:27:15 +0200 | <Inst> | i'm more annoyed that you can't newtype constructors for these types of sumtypes |
| 2024-09-21 11:28:19 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-09-21 11:28:28 +0200 | <tomsmeding> | Inst: what do you mean? |
| 2024-09-21 11:28:46 +0200 | <tomsmeding> | have a type that allows just one of the constructors? |
| 2024-09-21 11:29:04 +0200 | <tomsmeding> | you could make it a GADT and give it a type parameter that is different for each constructor |
| 2024-09-21 11:29:43 +0200 | <tomsmeding> | question is whether that's worth it |
| 2024-09-21 11:30:05 +0200 | <tomsmeding> | at least it still behaves properly with the rest of the language, contrary to existentials :p |
| 2024-09-21 11:36:19 +0200 | random-jellyfish | (~developer@user/random-jellyfish) (Quit: Leaving) |
| 2024-09-21 11:36:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 11:37:21 +0200 | CiaoSen | (~Jura@2a05:5800:22d:f000:ca4b:d6ff:fec1:99da) |
| 2024-09-21 11:40:34 +0200 | <Inst> | i mean that newtype is just transparent, it's effectively a type synonym that's enforced only on the type level |
| 2024-09-21 11:40:59 +0200 | <Inst> | also iirc there's some freaky laziness-related quirkiness there as well, i.e, the constructor doesn't exist and when you evaluate for the constructor you're also evaluating the underlying term, iirc |
| 2024-09-21 11:41:30 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 11:41:36 +0200 | <Inst> | but the two characteristics of newtypes are, no sum types, and only one field allowed |
| 2024-09-21 11:41:38 +0200 | <ski> | Hugs has restrricted type synonyms (like in the MLs) |
| 2024-09-21 11:42:24 +0200 | <Inst> | i'd rather have sum types (i.e, C union types) with the newtype transparency |
| 2024-09-21 11:42:34 +0200 | <tomsmeding> | Inst: do you mean sum types or union types? |
| 2024-09-21 11:42:40 +0200 | <tomsmeding> | union types do not have a tag, sum types do |
| 2024-09-21 11:42:59 +0200 | <Inst> | ah, and that's why Cmm can't do it, and thus haskell can't |
| 2024-09-21 11:43:18 +0200 | <tomsmeding> | the haskell source language has sum types, and no union types; C has union types and no sum types |
| 2024-09-21 11:43:23 +0200 | <tomsmeding> | python also "has" union types |
| 2024-09-21 11:43:27 +0200 | <tomsmeding> | as does typescript |
| 2024-09-21 11:44:19 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-09-21 11:44:45 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-09-21 11:45:09 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-09-21 11:51:06 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) |
| 2024-09-21 11:52:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 11:52:57 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-09-21 11:56:21 +0200 | nnm | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) |
| 2024-09-21 11:57:09 +0200 | morb | (~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 248 seconds) |
| 2024-09-21 11:57:28 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 11:59:39 +0200 | <Inst> | tagged unions, i guess |
| 2024-09-21 11:59:49 +0200 | <tomsmeding> | right |
| 2024-09-21 12:00:09 +0200 | <tomsmeding> | I'd call a tagged union a "sum type" when the language ensures that the tag and the union contents remain in sync |
| 2024-09-21 12:00:29 +0200 | wagle | (~wagle@quassel.wagle.io) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-09-21 12:01:15 +0200 | <tomsmeding> | well -- the language, or the API of the sum type, if it's implemented in user space |
| 2024-09-21 12:01:41 +0200 | <tomsmeding> | e.g. std::variant in C++ builds on the underlying support for union types to create a sum type, because its API doesn't allow letting the tag and the contents get out of sync |
| 2024-09-21 12:01:56 +0200 | <tomsmeding> | (never mind that there are umpteen other problems with std::variant, it's a mess, but it _is_ a sum type) |
| 2024-09-21 12:03:18 +0200 | <ski> | the tag also needs to be distinct from the type of the contents |
| 2024-09-21 12:03:32 +0200 | <ski> | (`A + A' should not equal `A'9 |
| 2024-09-21 12:04:00 +0200 | <tomsmeding> | I would rather formulate that as "every alternative of the union should have a distinct tag" |
| 2024-09-21 12:04:48 +0200 | <tomsmeding> | looking at the types becomes ambiguous if you have e.g. a language with refinement types, where Int and {v : Int | v > 0} are distinct types but have indistinguishable values |
| 2024-09-21 12:04:50 +0200 | <ski> | yep, that's a more constructive way to phrase it |
| 2024-09-21 12:05:39 +0200 | ski | would call those (subset) comprenesion types |
| 2024-09-21 12:06:08 +0200 | <tomsmeding> | isn't "refinement type" a more general term? |
| 2024-09-21 12:06:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 12:06:32 +0200 | <tomsmeding> | at the very least, liquid haskell has these things and calls them "refinement types" :) |
| 2024-09-21 12:07:08 +0200 | <ski> | given `data List a = Nil | Cons a (List a)', i'd say `data EvenList a <: List a = Nil | Cons a (OddList a)' and `data OddList a <: List a = Cons a (EvenList a)' are refinement types |
| 2024-09-21 12:07:25 +0200 | <ski> | you refine a variant/sum type, by removing alternatives, yielding a subtype |
| 2024-09-21 12:07:51 +0200 | <ski> | this was described in papers before LiquidHaskell existed |
| 2024-09-21 12:08:11 +0200 | <tomsmeding> | I see |
| 2024-09-21 12:08:11 +0200 | <Lears> | "Union types" need to be debunked so people will stop expecting them to be a thing. They don't even make sense. |
| 2024-09-21 12:08:15 +0200 | <tomsmeding> | difference in terminology, then |
| 2024-09-21 12:08:36 +0200 | <tomsmeding> | Lears: there are type systems that support them /shrug/ |
| 2024-09-21 12:08:36 +0200 | <ski> | (you can also refine a record/product type, by removing fields, yielding a supertype) |
| 2024-09-21 12:10:15 +0200 | <ski> | "Supertyping Suggestion for Haskell" by jmeacham (of jhc) at <http://repetae.net/recent/out/supertyping.html> is something similar, but for type classes |
| 2024-09-21 12:11:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 12:15:33 +0200 | spenat_ | spenat |
| 2024-09-21 12:16:30 +0200 | CiaoSen | (~Jura@2a05:5800:22d:f000:ca4b:d6ff:fec1:99da) (Ping timeout: 246 seconds) |
| 2024-09-21 12:17:18 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) |
| 2024-09-21 12:21:38 +0200 | connrs | (~connrs@user/connrs) (Ping timeout: 265 seconds) |
| 2024-09-21 12:22:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 12:22:54 +0200 | dolio | (~dolio@130.44.140.168) (Ping timeout: 260 seconds) |
| 2024-09-21 12:22:55 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 264 seconds) |
| 2024-09-21 12:23:21 +0200 | connrs | (~connrs@user/connrs) |
| 2024-09-21 12:24:09 +0200 | dolio | (~dolio@130.44.140.168) |
| 2024-09-21 12:26:57 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 12:34:33 +0200 | driib318 | (~driib@vmi931078.contaboserver.net) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-21 12:35:39 +0200 | driib318 | (~driib@176.57.184.141) |
| 2024-09-21 12:37:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 12:38:53 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) (Quit: Client closed) |
| 2024-09-21 12:42:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 12:43:17 +0200 | gvg_ | gvg |
| 2024-09-21 12:53:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 12:55:18 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) |
| 2024-09-21 12:58:29 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-21 13:00:04 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-09-21 13:01:38 +0200 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
| 2024-09-21 13:01:58 +0200 | YoungFrog | (~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be) |
| 2024-09-21 13:05:08 +0200 | caconym | (~caconym@user/caconym) |
| 2024-09-21 13:09:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 13:10:38 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2024-09-21 13:13:35 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2024-09-21 13:14:15 +0200 | Squared | (~Square@user/square) |
| 2024-09-21 13:16:29 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) |
| 2024-09-21 13:19:59 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds) |
| 2024-09-21 13:20:57 +0200 | Guest4 | (~Guest4@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2024-09-21 13:23:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 13:26:06 +0200 | synchromesh | (~john@2406:5a00:241a:5600:3c25:ae8:512d:c1ef) (Read error: Connection reset by peer) |
| 2024-09-21 13:27:35 +0200 | synchromesh | (~john@2406:5a00:241a:5600:5db8:4c32:8611:a0fa) |
| 2024-09-21 13:28:40 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-09-21 13:32:20 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) |
| 2024-09-21 13:34:01 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 252 seconds) |
| 2024-09-21 13:37:49 +0200 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) |
| 2024-09-21 13:38:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 13:39:55 +0200 | nnm_ | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) |
| 2024-09-21 13:41:12 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2024-09-21 13:43:24 +0200 | nnm | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) (Ping timeout: 260 seconds) |
| 2024-09-21 13:43:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 13:45:55 +0200 | nnm__ | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) |
| 2024-09-21 13:49:06 +0200 | nnm_ | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) (Ping timeout: 248 seconds) |
| 2024-09-21 13:54:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 13:59:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 14:08:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 14:13:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 14:19:29 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Ping timeout: 255 seconds) |
| 2024-09-21 14:19:35 +0200 | ZharMeny` | (~ZharMeny@user/ZharMeny) |
| 2024-09-21 14:21:52 +0200 | ZharMeny` | ZharMeny |
| 2024-09-21 14:22:30 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) (Read error: Connection reset by peer) |
| 2024-09-21 14:22:48 +0200 | ZharMeny | (~ZharMeny@user/ZharMeny) |
| 2024-09-21 14:24:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 14:28:49 +0200 | nnm_ | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) |
| 2024-09-21 14:28:53 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 14:32:35 +0200 | nnm__ | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) (Ping timeout: 260 seconds) |
| 2024-09-21 14:33:27 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) |
| 2024-09-21 14:33:54 +0200 | nnm_ | (~nnm@79-139-162-83.dynamic.spd-mgts.ru) (Ping timeout: 272 seconds) |
| 2024-09-21 14:37:53 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 245 seconds) |
| 2024-09-21 14:39:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 14:44:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 14:52:11 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-09-21 14:55:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 14:56:20 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-21 14:59:18 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-09-21 15:00:26 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 15:02:00 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-09-21 15:02:10 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-21 15:09:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 15:11:52 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) |
| 2024-09-21 15:13:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 15:15:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 15:20:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 15:20:39 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) |
| 2024-09-21 15:24:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 15:28:45 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-09-21 15:31:58 +0200 | weary-traveler | (~user@user/user363627) |
| 2024-09-21 15:34:19 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 264 seconds) |
| 2024-09-21 15:39:28 +0200 | <Inst> | ski: I still remember that you guys are teaching IO first. Have you guys considered teaching parallel and concurrent programming first, as that's the "polite" way to teach IO first? :) |
| 2024-09-21 15:39:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 15:42:03 +0200 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 245 seconds) |
| 2024-09-21 15:45:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 15:52:21 +0200 | mari-estel | (~mari-este@2a02:3032:303:eecf:216:3eff:fe65:4eef) |
| 2024-09-21 15:55:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 16:00:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 16:04:41 +0200 | ZharMeny | identity |
| 2024-09-21 16:10:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 16:11:51 +0200 | ski | (~ski@ext-1-196.eduroam.chalmers.se) (Ping timeout: 252 seconds) |
| 2024-09-21 16:15:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds) |
| 2024-09-21 16:22:17 +0200 | Digit | (~user@user/digit) (Read error: Connection reset by peer) |
| 2024-09-21 16:24:00 +0200 | Digit | (~user@user/digit) |
| 2024-09-21 16:25:45 +0200 | Xe | (~cadey@perl/impostor/xe) (Quit: WeeChat 4.4.0) |
| 2024-09-21 16:26:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 16:26:40 +0200 | Xe | (~cadey@perl/impostor/xe) |
| 2024-09-21 16:31:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 16:32:43 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 16:41:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 16:43:03 +0200 | Iceland_jack | (~Iceland_j@user/Iceland-jack:62112) |
| 2024-09-21 16:46:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 16:49:29 +0200 | mari-estel | (~mari-este@2a02:3032:303:eecf:216:3eff:fe65:4eef) (Ping timeout: 260 seconds) |
| 2024-09-21 16:57:23 +0200 | machinedgod | (~machinedg@d50-99-47-73.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-09-21 16:57:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 16:59:43 +0200 | Iceland_jack58 | (~Iceland_j@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) |
| 2024-09-21 16:59:43 +0200 | Iceland_jack58 | Icelandjack |
| 2024-09-21 17:00:07 +0200 | Icelandjack | (~Iceland_j@cpc122096-bmly10-2-0-cust498.2-3.cable.virginm.net) (Client Quit) |
| 2024-09-21 17:00:25 +0200 | Iceland_jack24 | (~Iceland_j@user/Iceland-jack:62112) |
| 2024-09-21 17:00:49 +0200 | Iceland_jack | (~Iceland_j@user/Iceland-jack:62112) (Ping timeout: 256 seconds) |
| 2024-09-21 17:02:31 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-21 17:05:21 +0200 | Iceland_jack24 | Iceland_jack |
| 2024-09-21 17:10:55 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-21 17:11:00 +0200 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2024-09-21 17:11:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 17:12:11 +0200 | malte | (~malte@mal.tc) |
| 2024-09-21 17:16:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 17:17:57 +0200 | ski | (~ski@remote11.chalmers.se) |
| 2024-09-21 17:19:50 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 272 seconds) |
| 2024-09-21 17:27:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 17:27:17 +0200 | Digitteknohippie | (~user@user/digit) |
| 2024-09-21 17:29:02 +0200 | Digit | (~user@user/digit) (Ping timeout: 265 seconds) |
| 2024-09-21 17:32:25 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 17:32:39 +0200 | billchenchina- | (~billchenc@124.90.85.141) |
| 2024-09-21 17:32:45 +0200 | <Inst> | if i'm building a HTML library, and I'm planning to abuse typeclasses like crazy (i.e, a ton of functions are defined within typeclasses) |
| 2024-09-21 17:34:01 +0200 | <monochrom> | then you can just plagiarize the xhtml package (comes with GHC) >:) |
| 2024-09-21 17:34:06 +0200 | <geekosaur> | don't unless you can be certain they all get resoilved at compile time |
| 2024-09-21 17:34:53 +0200 | <geekosaur> | otherweise they'll be indirect calls (possibly double indirect, if the typeclass dictionary isn't unboxed by optimizations) and be slooooow |
| 2024-09-21 17:34:56 +0200 | <monochrom> | Err, no, xhtml doesn't do that. Something else does. |
| 2024-09-21 17:37:43 +0200 | billchenchina- | (~billchenc@124.90.85.141) (Read error: Connection reset by peer) |
| 2024-09-21 17:37:50 +0200 | Digitteknohippie | Digit |
| 2024-09-21 17:38:30 +0200 | billchenchina- | (~billchenc@103.118.42.229) |
| 2024-09-21 17:39:20 +0200 | <monochrom> | regex-base does that for regex. If you figure out how to use it, then you can hope that your users can figure out how to use yours. |
| 2024-09-21 17:39:29 +0200 | billchenchina- | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-09-21 17:39:59 +0200 | <geekosaur> | it's also kinda infamously "wtf?"-inducing |
| 2024-09-21 17:40:26 +0200 | <geekosaur> | (granting that's because the author was trying to write Perl in Haskell) |
| 2024-09-21 17:40:58 +0200 | billchenchina- | (~billchenc@103.118.42.229) |
| 2024-09-21 17:41:21 +0200 | <monochrom> | Yeah I was going for "someone typeclassified everything, this is what happened" :) |
| 2024-09-21 17:41:47 +0200 | billchenchina- | (~billchenc@103.118.42.229) (Max SendQ exceeded) |
| 2024-09-21 17:41:57 +0200 | <monochrom> | Oh, "someone learned Perl, this is what happened" works too >:) |
| 2024-09-21 17:42:19 +0200 | <monochrom> | "someone learned Perl, this is what happened to their fRMI brain image" |
| 2024-09-21 17:42:44 +0200 | <geekosaur> | remember, back when it was written, there was a shocking amount of overlap between the Perl and Haskell communities, and I don't mean PUGS |
| 2024-09-21 17:42:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 17:42:53 +0200 | billchenchina- | (~billchenc@103.118.42.229) |
| 2024-09-21 17:42:54 +0200 | <geekosaur> | (a few of us are still around 🙂 ) |
| 2024-09-21 17:47:50 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-21 17:49:52 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-21 17:50:21 +0200 | <Franciman> | geekosaur: you mean when raku was written in haskell? |
| 2024-09-21 17:50:25 +0200 | <mauke> | that's not just writing perl in haskell, that's trying to outperl perl by a factor of at least 10 |
| 2024-09-21 17:50:33 +0200 | <Franciman> | lol |
| 2024-09-21 17:51:09 +0200 | <mauke> | the regex interface in perl is much simpler because hey, global variables :-) |
| 2024-09-21 17:53:48 +0200 | <geekosaur> | Franciman: did you not see PUGS there? |
| 2024-09-21 17:54:32 +0200 | <Franciman> | no i asked because i was asking what times you were talking about? |
| 2024-09-21 17:55:39 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-09-21 17:56:26 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-21 17:58:35 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 244 seconds) |
| 2024-09-21 17:58:39 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 17:58:45 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-09-21 17:59:28 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-09-21 18:01:11 +0200 | finsternis | (~X@23.226.237.192) (Remote host closed the connection) |
| 2024-09-21 18:03:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 18:07:11 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-09-21 18:07:35 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-09-21 18:10:07 +0200 | <Franciman> | ah geekosaur lol |
| 2024-09-21 18:10:15 +0200 | <Franciman> | I parsed PUGS as Perl user groups |
| 2024-09-21 18:10:18 +0200 | <Franciman> | not as Pugs |
| 2024-09-21 18:10:23 +0200 | <Franciman> | pardon |
| 2024-09-21 18:10:41 +0200 | <ski> | @where pugs |
| 2024-09-21 18:10:41 +0200 | <lambdabot> | http://www.pugscode.org/ |
| 2024-09-21 18:11:17 +0200 | <Franciman> | lol ski it changed a bit |
| 2024-09-21 18:11:26 +0200 | <Franciman> | it redirects to https://www.musbed.com/ |
| 2024-09-21 18:11:36 +0200 | <ski> | probably expired long ago |
| 2024-09-21 18:12:16 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 18:13:12 +0200 | finsternis | (~X@23.226.237.192) |
| 2024-09-21 18:13:24 +0200 | <ski> | <https://web.archive.org/web/20150214140229/http://www.pugscode.org/> is pre-expiry |
| 2024-09-21 18:17:21 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 18:17:34 +0200 | troojg | (~troojg@user/troojg) (Ping timeout: 260 seconds) |
| 2024-09-21 18:19:22 +0200 | billchenchina- | (~billchenc@103.118.42.229) (Quit: Leaving) |
| 2024-09-21 18:19:46 +0200 | <ggVGc> | What's the current state of stack usage? Some years ago I felt a lot of people were moving back to cabal. I haven't been touching my Haskell stuff much the past 3 years, and am still rolling with stack since that's what the project was started with a long time ago. |
| 2024-09-21 18:20:09 +0200 | <ggVGc> | But, it seems cabal is the main focus of the general community again by now? |
| 2024-09-21 18:20:38 +0200 | <ggVGc> | I guess a more concrete question is, is anyone of you still using stack? |
| 2024-09-21 18:21:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 18:24:53 +0200 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2024-09-21 18:27:14 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 252 seconds) |
| 2024-09-21 18:27:39 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2024-09-21 18:34:51 +0200 | <haskellbridge> | <sm> Of course we are. Search recent discourse and Reddit threads and you’ll find some related discussion ggVGc |
| 2024-09-21 18:35:50 +0200 | <haskellbridge> | <sm> See also stack’s matrix room |
| 2024-09-21 18:38:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 18:43:11 +0200 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2024-09-21 18:43:20 +0200 | driib318 | (~driib@176.57.184.141) (Quit: The Lounge - https://thelounge.chat) |
| 2024-09-21 18:43:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 18:46:15 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-09-21 18:47:34 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-21 18:48:22 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-09-21 18:48:43 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 245 seconds) |
| 2024-09-21 18:48:45 +0200 | driib318 | (~driib@vmi931078.contaboserver.net) |
| 2024-09-21 18:49:21 +0200 | <tomsmeding> | ggVGc: before, cabal was the "official but it's annoying to use" and stack was the "other thing that is nice". These days both are quite nice. For some people that meant dropping stack and going back to cabal; for others that meant using what they've mostly always used |
| 2024-09-21 18:49:32 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-09-21 18:50:05 +0200 | <tomsmeding> | the community is large-ish, so "main focus of the community" is generally hard to say |
| 2024-09-21 18:50:08 +0200 | <tomsmeding> | both have mindshare |
| 2024-09-21 18:50:21 +0200 | <tomsmeding> | but it's not as polarised as it was in the past, and that's a good thing :) |
| 2024-09-21 18:50:42 +0200 | <tomsmeding> | sm: I hope I'm not misrepresenting things |
| 2024-09-21 18:57:18 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-09-21 18:59:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 19:04:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 19:10:24 +0200 | <haskellbridge> | <sm> sounds fair tomsmeding! |
| 2024-09-21 19:10:43 +0200 | danza | (~danza@user/danza) |
| 2024-09-21 19:13:10 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 260 seconds) |
| 2024-09-21 19:13:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 19:14:55 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-09-21 19:16:51 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2024-09-21 19:18:17 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-21 19:19:17 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-09-21 19:20:50 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-09-21 19:21:38 +0200 | <monochrom> | Main focus of the community is coexistence! |
| 2024-09-21 19:24:11 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-09-21 19:26:33 +0200 | danza | (~danza@user/danza) () |
| 2024-09-21 19:29:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 19:29:22 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2024-09-21 19:31:15 +0200 | youthlic | (~Thunderbi@user/youthlic) (Quit: youthlic) |
| 2024-09-21 19:32:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 19:33:30 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-09-21 19:33:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 19:34:44 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-09-21 19:39:06 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-09-21 19:41:10 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-09-21 19:44:25 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 19:44:29 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2024-09-21 19:45:58 +0200 | Digitteknohippie | (~user@user/digit) |
| 2024-09-21 19:46:04 +0200 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
| 2024-09-21 19:46:05 +0200 | <geekosaur> | last time a survey was done, the community was 50-50. I think we're due for another one soon-ish though? |
| 2024-09-21 19:49:09 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-09-21 19:53:35 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2024-09-21 19:54:33 +0200 | Digitteknohippie | Digit |
| 2024-09-21 19:55:33 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 19:56:59 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-09-21 19:59:08 +0200 | tuxpaint | (~a@put.gay) |
| 2024-09-21 20:00:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 20:03:13 +0200 | <dmj`> | what about all the "runhaskell Setup.hs" people? |
| 2024-09-21 20:04:20 +0200 | geekosaur | emphatically doesn't miss that |
| 2024-09-21 20:04:38 +0200 | <tomsmeding> | dmj`: my condolences for your time if you do that and want to use any package from hackage that depends on more than boot libs :p |
| 2024-09-21 20:04:46 +0200 | <geekosaur> | ^ |
| 2024-09-21 20:05:08 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 20:05:10 +0200 | <geekosaur> | that's what tooling is for! |
| 2024-09-21 20:05:37 +0200 | tomsmeding | came into haskell land recently enough to have had cabal from the get go -- albeit with cabal hell |
| 2024-09-21 20:05:49 +0200 | <tomsmeding> | and on arch without knowing about -dynamic, hence nothing worked |
| 2024-09-21 20:05:51 +0200 | <geekosaur> | I was pre-cabal |
| 2024-09-21 20:05:51 +0200 | <tomsmeding> | :D |
| 2024-09-21 20:05:53 +0200 | <tomsmeding> | but boot libs worked |
| 2024-09-21 20:06:00 +0200 | <tomsmeding> | so I used boot libs and was happy |
| 2024-09-21 20:06:04 +0200 | <geekosaur> | even with cabal hell, cabal was a massive improvement over the status quo |
| 2024-09-21 20:06:11 +0200 | <tomsmeding> | I can believe |
| 2024-09-21 20:06:22 +0200 | <tomsmeding> | did hackage exist before cabal? |
| 2024-09-21 20:06:34 +0200 | <tomsmeding> | sounds like a contradiction, almost |
| 2024-09-21 20:06:41 +0200 | dmj` | used to copy around cabal sandboxes and use hsenv |
| 2024-09-21 20:06:56 +0200 | <tomsmeding> | what is hsenv? |
| 2024-09-21 20:07:10 +0200 | <dmj`> | @package hsenv |
| 2024-09-21 20:07:10 +0200 | <lambdabot> | https://hackage.haskell.org/package/hsenv |
| 2024-09-21 20:07:26 +0200 | <tomsmeding> | I see |
| 2024-09-21 20:07:33 +0200 | <geekosaur> | roughly, virtuualenv for haskell |
| 2024-09-21 20:07:46 +0200 | <geekosaur> | I used that a fair bit too BITD |
| 2024-09-21 20:08:20 +0200 | <dmj`> | nix solved cabal hell, works well with Setup.hs |
| 2024-09-21 20:08:24 +0200 | <geekosaur> | (there was a "virthualenv" too IIRC but hsenv was more popular) |
| 2024-09-21 20:08:58 +0200 | <geekosaur> | then came cabal sandboxes and both pretty much disappeared |
| 2024-09-21 20:10:38 +0200 | monochrom | (trebla@216.138.220.146) (Quit: ZNC 1.9.0+deb2build3 - https://znc.in) |
| 2024-09-21 20:11:22 +0200 | <Franciman> | tomsmeding: who needs anything more than boot libs? /s |
| 2024-09-21 20:12:12 +0200 | <tomsmeding> | if you're happy not doing "modern practical" stuff like build a web server, communicate in json, I dunno what, a learner is IMO quite set with just boot libs |
| 2024-09-21 20:12:27 +0200 | <tomsmeding> | plenty of learning and interesting things you can build with just that |
| 2024-09-21 20:12:30 +0200 | <tomsmeding> | "just" that |
| 2024-09-21 20:12:47 +0200 | <Franciman> | i thought you use java for practical stff |
| 2024-09-21 20:13:09 +0200 | <tomsmeding> | if you want ordinary mortals to understand it, maybe |
| 2024-09-21 20:13:24 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-06-76-69-85-220.dsl.bell.ca) |
| 2024-09-21 20:13:33 +0200 | <tomsmeding> | java has a good GC and does good OOP; if you need those together, use java |
| 2024-09-21 20:13:49 +0200 | <haskellbridge> | <magic_rb> We also have a good gc |
| 2024-09-21 20:13:57 +0200 | <haskellbridge> | <magic_rb> So it depends on if you want fp or oop |
| 2024-09-21 20:14:03 +0200 | <tomsmeding> | ghc also has a good GC (but not quite as well-tuned as java's -- a matter of an order of magnitude more engineering hours) |
| 2024-09-21 20:14:07 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-06-76-69-85-220.dsl.bell.ca) (Remote host closed the connection) |
| 2024-09-21 20:14:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 20:14:21 +0200 | <haskellbridge> | <magic_rb> But not much gain for the time put in tbh |
| 2024-09-21 20:14:24 +0200 | <tomsmeding> | and indeed, haskell has good FP |
| 2024-09-21 20:14:33 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-06-76-69-85-220.dsl.bell.ca) |
| 2024-09-21 20:14:48 +0200 | <tomsmeding> | maybe not much, but I recall pretty embarrassing stories about GHC's GC |
| 2024-09-21 20:14:59 +0200 | <tomsmeding> | especially the parallel GC is often quite awkward |
| 2024-09-21 20:15:17 +0200 | <geekosaur> | hasn't that improved of late though? |
| 2024-09-21 20:15:25 +0200 | <haskellbridge> | <magic_rb> Since we have a gc which doesnt stop the world, its not nearly as bad tho |
| 2024-09-21 20:15:30 +0200 | <geekosaur> | I thought 9.2.x had major improvements |
| 2024-09-21 20:15:30 +0200 | <tomsmeding> | now the nonmoving GC exists, of course, but it's not default, and it's a latency-throughput tradeoff with the default GC |
| 2024-09-21 20:15:54 +0200 | <tomsmeding> | the nonmoving GC results in lower overall throughput, but gives you a much shorter GC pause (i.e. lower latency) |
| 2024-09-21 20:16:08 +0200 | <tomsmeding> | geekosaur: could well be! |
| 2024-09-21 20:16:21 +0200 | <tomsmeding> | also to the default parallel GC? |
| 2024-09-21 20:16:33 +0200 | <haskellbridge> | <magic_rb> I think we dont stop the world anymore, not sure |
| 2024-09-21 20:16:42 +0200 | <tomsmeding> | nonmoving GC still has a pause |
| 2024-09-21 20:16:51 +0200 | <tomsmeding> | it's just much shorter, because much of the actual GC work happens concurrently |
| 2024-09-21 20:16:53 +0200 | <tomsmeding> | but not everything |
| 2024-09-21 20:17:06 +0200 | <haskellbridge> | <magic_rb> Moving pauses too? |
| 2024-09-21 20:17:10 +0200 | <tomsmeding> | (I don't know the details) |
| 2024-09-21 20:17:27 +0200 | <geekosaur> | https://downloads.haskell.org/ghc/9.2.1/docs/html/users_guide/9.2.1-notes.html#runtime-system |
| 2024-09-21 20:17:42 +0200 | <geekosaur> | we still stop the world but it's shorter |
| 2024-09-21 20:18:17 +0200 | <tomsmeding> | :o that first paragraph is good |
| 2024-09-21 20:18:20 +0200 | <tomsmeding> | my experience is 8.10 era |
| 2024-09-21 20:18:44 +0200 | <geekosaur> | yes. llook again, a lot of work went into making parallel GC usable |
| 2024-09-21 20:18:49 +0200 | <tomsmeding> | I -qg'd all the things |
| 2024-09-21 20:19:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 20:19:05 +0200 | <tomsmeding> | (I'm not really using that code any more, but it's good to know for future stuff) |
| 2024-09-21 20:20:48 +0200 | <haskellbridge> | <magic_rb> I havent written anything where i would care about performance yet, i should maybe do so before attempting to outperform the vfat driver in linux using haskell and FUSE |
| 2024-09-21 20:20:59 +0200 | <tomsmeding> | lol |
| 2024-09-21 20:21:03 +0200 | <tomsmeding> | that sounds like a lost game |
| 2024-09-21 20:21:13 +0200 | <tomsmeding> | that, or the existing driver is horribly written |
| 2024-09-21 20:21:21 +0200 | <geekosaur> | I don't think I've ever written much where performance mattered beyond "is it faster than I could do it with pen and paper? good." |
| 2024-09-21 20:21:23 +0200 | <tomsmeding> | FUSE alone |
| 2024-09-21 20:21:55 +0200 | <geekosaur> | (outside of commercial contexts of course) |
| 2024-09-21 20:22:47 +0200 | <haskellbridge> | <magic_rb> FUSE should be okay ish with iouring |
| 2024-09-21 20:23:00 +0200 | <haskellbridge> | <magic_rb> But yeah probably not happening |
| 2024-09-21 20:23:14 +0200 | <haskellbridge> | <magic_rb> Still makes for a google title of the thesis lol |
| 2024-09-21 20:23:24 +0200 | <dmj`> | tomsmeding: working on a web server right now with lots of libs, runhaskell Setup.hs configure and build work fine, don't have to dig into dist-newstyle either, dist/build/app/app |
| 2024-09-21 20:23:54 +0200 | <tomsmeding> | dmj`: oh I forget -- Setup.hs pulls in Cabal, right? |
| 2024-09-21 20:24:01 +0200 | <tomsmeding> | I guess that works |
| 2024-09-21 20:24:09 +0200 | <dmj`> | Cabal is wired-in |
| 2024-09-21 20:24:16 +0200 | <tomsmeding> | right |
| 2024-09-21 20:24:30 +0200 | <haskellbridge> | <magic_rb> Weird way if doing things? Why not use cabal itself? |
| 2024-09-21 20:24:46 +0200 | <haskellbridge> | <magic_rb> Or rather cabal-install ig |
| 2024-09-21 20:24:53 +0200 | monochrom | (trebla@216.138.220.146) |
| 2024-09-21 20:25:36 +0200 | <dmj`> | nix pulls in an immutable ghc-pkg list, don't need to install anything, just build, most of the config is in the cabal file itself or nix overrides from haskell.lib |
| 2024-09-21 20:27:03 +0200 | <tomsmeding> | you do you :) |
| 2024-09-21 20:27:16 +0200 | <dmj`> | you can make bash functions inside a shell environment for all the building / documentation / ghcid stuff |
| 2024-09-21 20:27:18 +0200 | <tomsmeding> | I can believe that this works more easily with nix somehow |
| 2024-09-21 20:27:36 +0200 | <tomsmeding> | but then, that's the problem of the people who want to use nix, not my problem :p |
| 2024-09-21 20:27:48 +0200 | <tomsmeding> | (nothing against nix, I just don't use it) |
| 2024-09-21 20:28:43 +0200 | <tuxpaint> | I compiled a binary using `ghc main.hs -o main`. the binary takes ~12ms to execute on my system, after timing it with both hyperfine and zsh/time. This was weird to me (longer than i expected), so i recompiled with `ghc main.hs -prof -fprof-auto -o main` to profile. however, executing this binary, it takes an expected 2-3ms. I'm a bit confused what could be causing this? the code and the ghc environment file is all here https://github.com/elee1766/potatoe/tree/mast |
| 2024-09-21 20:28:43 +0200 | <tuxpaint> | er/contrib/haskell |
| 2024-09-21 20:28:46 +0200 | <tuxpaint> | mann |
| 2024-09-21 20:28:47 +0200 | <tuxpaint> | https://github.com/elee1766/potatoe/tree/master/contrib/haskell |
| 2024-09-21 20:29:16 +0200 | <tomsmeding> | tuxpaint: what is the output of `./main +RTS -s` |
| 2024-09-21 20:30:01 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 20:30:07 +0200 | <tuxpaint> | https://put.gay/files/HZZFrCYV6b.txt |
| 2024-09-21 20:30:26 +0200 | <tomsmeding> | is that the profiling or the non-profiling version? |
| 2024-09-21 20:30:31 +0200 | <tuxpaint> | profiling |
| 2024-09-21 20:30:33 +0200 | <tomsmeding> | and what OS is this? |
| 2024-09-21 20:30:42 +0200 | <tomsmeding> | what about the non-profiling version? |
| 2024-09-21 20:31:12 +0200 | <tomsmeding> | (trying to determine if the difference is whether GC ran or not) |
| 2024-09-21 20:31:28 +0200 | <monochrom> | Perhaps first establish a baseline. Merely "main = pure ()". Measure that first. |
| 2024-09-21 20:31:31 +0200 | <tuxpaint> | linux, debian 12, non-profiling https://put.gay/files/YjjCegtEl7XE.txt |
| 2024-09-21 20:31:40 +0200 | <tomsmeding> | also that ^ |
| 2024-09-21 20:32:03 +0200 | <tomsmeding> | ok that's basically identical |
| 2024-09-21 20:33:23 +0200 | <tomsmeding> | reproduces here, profiling version of `main = pure ()` takes around 6ms, non-profiling takes around 12ms |
| 2024-09-21 20:33:37 +0200 | <tuxpaint> | i get the same behavior on baseline, https://put.gay/files/vllWFpymoiT2.txt |
| 2024-09-21 20:33:54 +0200 | <tuxpaint> | 12s nonprofiling, 2.5ms profiling |
| 2024-09-21 20:34:00 +0200 | <tuxpaint> | ms* |
| 2024-09-21 20:35:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 20:36:27 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) |
| 2024-09-21 20:36:32 +0200 | <tomsmeding> | under strace there's just an additional gap with no syscalls happening in the non-profiling version |
| 2024-09-21 20:40:43 +0200 | <monochrom> | Hypothesis: The profiling RTS simply has different timer/alarm settings from the normal RTS. |
| 2024-09-21 20:41:26 +0200 | <tomsmeding> | monochrom: what timer would it be waiting for? |
| 2024-09-21 20:42:52 +0200 | <monochrom> | If you don't use the threaded RTS, then the non-threaded RTS has to set up its own regular alarm for DIY time slicing, just in case you use forkIO or par. |
| 2024-09-21 20:43:35 +0200 | <monochrom> | OK OK it's a hypothesis, I confess I don't know what I'm talking about :) |
| 2024-09-21 20:44:25 +0200 | <monochrom> | Or rather, I haven't answered the question, and I don't know how to. |
| 2024-09-21 20:45:08 +0200 | foul_owl | (~kerry@185.219.141.160) (Ping timeout: 255 seconds) |
| 2024-09-21 20:45:15 +0200 | <monochrom> | This is interesting. Next time someone find startup time to be too long, we can suggest "turn on profiling" >:) |
| 2024-09-21 20:45:43 +0200 | <monochrom> | Actually someone on haskell-cafe asked about that a while ago. |
| 2024-09-21 20:45:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 20:47:13 +0200 | <monochrom> | This: https://mail.haskell.org/pipermail/haskell-cafe/2024-August/136863.html |
| 2024-09-21 20:47:25 +0200 | <tomsmeding> | for the record, -threaded doesn't make a difference for me, both in the default and in the profiling case :p |
| 2024-09-21 20:47:34 +0200 | <tuxpaint> | yeah i'm basically comparing the startup time of a few different languages. it was odd that haskell is much worse than other compiled counterparts, but i guess somehow -prof changes something |
| 2024-09-21 20:47:42 +0200 | <tuxpaint> | -threaded made no difference for me either, yeah |
| 2024-09-21 20:49:08 +0200 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 245 seconds) |
| 2024-09-21 20:50:01 +0200 | <tomsmeding> | profiling this (with perf) is difficult because there's not much there :p |
| 2024-09-21 20:50:05 +0200 | <monochrom> | This is strange. But you look at "user" and "sys" and you see that the wallclock time just means the process is sleeping most of the time. Yeah what is it waiting for? |
| 2024-09-21 20:51:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 264 seconds) |
| 2024-09-21 20:51:18 +0200 | <tomsmeding> | ~all of the time in perf(1) report output point to the kernel for me |
| 2024-09-21 20:51:27 +0200 | <tomsmeding> | (for the record: ghc -O also doesn't help >:D) |
| 2024-09-21 20:51:35 +0200 | <tomsmeding> | (I hadn't expected it to) |
| 2024-09-21 20:52:55 +0200 | srcd | (~srcd@93-140-131-235.adsl.net.t-com.hr) |
| 2024-09-21 20:53:56 +0200 | srcd | (~srcd@93-140-131-235.adsl.net.t-com.hr) (Client Quit) |
| 2024-09-21 20:54:39 +0200 | <tomsmeding> | okay perf(1) is pointless here, it gets way too few samples |
| 2024-09-21 20:55:21 +0200 | <tomsmeding> | it's like, 70% of your time is in this kernel function. Okay, so where? Well, 100% of the time in this kernel function is in this instruction: push %rbx |
| 2024-09-21 20:55:23 +0200 | <tomsmeding> | yeah right |
| 2024-09-21 20:55:26 +0200 | <tomsmeding> | that's 1 sample |
| 2024-09-21 20:57:32 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) |
| 2024-09-21 20:58:51 +0200 | <tomsmeding> | okay with `perf record -F max` (higher sample frequency), I reliably get that about 23% of the time is spent in a kernel function called clear_page_erms |
| 2024-09-21 20:59:20 +0200 | <tomsmeding> | and that function fills a 4KiB page with zeros |
| 2024-09-21 21:00:02 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-09-21 21:00:41 +0200 | caconym | (~caconym@user/caconym) |
| 2024-09-21 21:01:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 21:02:14 +0200 | <tomsmeding> | (the function is literally 5 instructions long: `endbr64` (control flow protection magic), `%ecx := 4096`, `%eax := 0`, `rep stos` which does essentially memset, `ret`) |
| 2024-09-21 21:03:24 +0200 | <tomsmeding> | but perf doesn't see much difference between the default and the profiling version |
| 2024-09-21 21:03:54 +0200 | <tomsmeding> | ok I dunno, someone with knowledge about the RTS and the ability to print debug info from it (with timestamps) should investigate this, not me |
| 2024-09-21 21:04:32 +0200 | <dolio> | Should they, though? |
| 2024-09-21 21:04:53 +0200 | <tomsmeding> | startup time is a valid thing to optimise for |
| 2024-09-21 21:05:01 +0200 | <tomsmeding> | it's likely not top priority, and it shouldn't be |
| 2024-09-21 21:05:31 +0200 | <tomsmeding> | 12ms is a fairly long time |
| 2024-09-21 21:07:12 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-09-21 21:07:29 +0200 | <geekosaur> | there is ongoing work on optimizing startup time, actually |
| 2024-09-21 21:07:32 +0200 | <tuxpaint> | 12ms puts it at the same speed as the perl/python scripts that do the same thing, which feels a little wrong. |
| 2024-09-21 21:07:44 +0200 | <geekosaur> | they already did a lot of qwork on shutdown time, which was kinda horrendous |
| 2024-09-21 21:07:56 +0200 | <geekosaur> | so now they've moved on to startup |
| 2024-09-21 21:08:01 +0200 | <tuxpaint> | regardless if it's correct to care about startup time, many people do, so maybe that is a good enough reason |
| 2024-09-21 21:08:06 +0200 | <tomsmeding> | tuxpaint: but when a haskell program is going, it's quite a bit faster than python ;) |
| 2024-09-21 21:08:31 +0200 | <geekosaur> | overhead can still eat your lunch though… |
| 2024-09-21 21:14:56 +0200 | <monochrom> | Ugh the joke is on me. I lost an old exe that uses regex-base etc, now I have to recompile it again. |
| 2024-09-21 21:15:10 +0200 | <geekosaur> | heh |
| 2024-09-21 21:15:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 21:16:39 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-09-21 21:17:10 +0200 | briandaed | (~root@185.234.210.211.r.toneticgroup.pl) (Remote host closed the connection) |
| 2024-09-21 21:17:49 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 260 seconds) |
| 2024-09-21 21:19:11 +0200 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-06-76-69-85-220.dsl.bell.ca) (Remote host closed the connection) |
| 2024-09-21 21:20:23 +0200 | rekahsoft | (~rekahsoft@76.69.85.220) |
| 2024-09-21 21:20:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 21:20:42 +0200 | <tuxpaint> | monochrom: your hypothesis is somewhat confirmed i think. compiling with `rtsflags` and using `-V0.001` gets me the same startup time as -prof https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--V%20%E2%9F%A8se… |
| 2024-09-21 21:22:33 +0200 | <tuxpaint> | so i can compile with `-with-rtsopts="-V0.001"` and now it's the same. if i do `-V0.00001` it starts up even faster |
| 2024-09-21 21:23:29 +0200 | connrs | (~connrs@user/connrs) (Ping timeout: 248 seconds) |
| 2024-09-21 21:24:50 +0200 | rvalue- | rvalue |
| 2024-09-21 21:26:49 +0200 | <tuxpaint> | i guess my program doesn't use any timers, so the fastest option would be to use `-V0` and disable the RTS clock? |
| 2024-09-21 21:28:09 +0200 | <tomsmeding> | > The default is 0.001 seconds when profiling, and 0.01 otherwise. |
| 2024-09-21 21:28:11 +0200 | <tomsmeding> | ooh |
| 2024-09-21 21:28:43 +0200 | connrs | (~connrs@user/connrs) |
| 2024-09-21 21:29:50 +0200 | <tomsmeding> | tuxpaint: is this startup-time benchmark just curiosity, or do you have a real usecase for 1. wanting to use a high-level language like haskell, and 2. needing fast startup time? |
| 2024-09-21 21:30:01 +0200 | <tuxpaint> | interestingly, if i set it to a 8ms clock, runtime is 10ms. if i set it to 15ms clock, runtime is 17ms, up to 20ms, where anything there and above gives me ~22ms |
| 2024-09-21 21:30:41 +0200 | <tuxpaint> | 12ms startup time in a cli is perceivable to a user. i'm exploring languages to write clis in. |
| 2024-09-21 21:31:03 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 21:31:27 +0200 | <tuxpaint> | so i've been going through seeing how the basic experience of reading flags and files is, along with writing to stdout. |
| 2024-09-21 21:31:40 +0200 | <tomsmeding> | rust is a good candidate if you like haskell, otherwise (but I don't know anything about startup time here, so YMMV) ocaml |
| 2024-09-21 21:32:11 +0200 | <tuxpaint> | yeah, so far i have perl, python, c, go, nim, rust, haskell, c# done |
| 2024-09-21 21:32:35 +0200 | <tuxpaint> | ocaml sounds fun, i may give it a try |
| 2024-09-21 21:33:36 +0200 | <tomsmeding> | strict functional language, funny syntax sometimes (especially data type declarations), somewhat fewer fancy type system features than haskell, first-class mutability |
| 2024-09-21 21:35:49 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 21:35:51 +0200 | <tomsmeding> | tuxpaint: one thing that you may or may not be taking into account with perl and python is that they are interpreted, hence if you import a bunch of libraries, your startup time is going to suffer significantly |
| 2024-09-21 21:36:06 +0200 | <tuxpaint> | i am, which is why it was very confusing that haskell was starting up in the same amount of time |
| 2024-09-21 21:36:20 +0200 | <tomsmeding> | same would hold for nodejs |
| 2024-09-21 21:36:27 +0200 | <tuxpaint> | of course there's a balance between the user experience in how easy it is for me to write the cli (more features), and how fast it executes |
| 2024-09-21 21:36:49 +0200 | <tuxpaint> | haskell is fun; it was my first language when learning to code many years ago. the IO monad was very nice to work with - didn't have a chance to do IO when i first touched haskell. |
| 2024-09-21 21:39:00 +0200 | <tomsmeding> | case in point: I also got 12ms for the `main = pure ()` with default settings on my machine, but starting a full blown web server and immediately exiting with `exitSuccess` if there are no command line arguments (to ensure that nothing can be optimised away) takes 15ms |
| 2024-09-21 21:39:07 +0200 | <tuxpaint> | i'm looking around for 20ms in the code. maybe it has something to do with the rescheduling timer? |
| 2024-09-21 21:40:09 +0200 | <tomsmeding> | s |
| 2024-09-21 21:40:12 +0200 | <tomsmeding> | oops |
| 2024-09-21 21:41:05 +0200 | <tuxpaint> | yeah. if i set V=100ms, and i=5ms, i get 7ms |
| 2024-09-21 21:41:25 +0200 | <tuxpaint> | so it seems it waits for either the first tick of the reschedule timer, or the clock timer or something? |
| 2024-09-21 21:42:01 +0200 | <tuxpaint> | huh, but if i set both above 20ms, it then caps at 22ms runtime again |
| 2024-09-21 21:42:46 +0200 | <tomsmeding> | it seems the time is spent in shutdown, not in startup |
| 2024-09-21 21:43:35 +0200 | <tomsmeding> | with `main = putStrLn "hi"`, and looking at strace output with nanosecond timestamps attached, a whole bunch of stuff happens, then the write, then 8ms of nothing, then a few more syscalls and exit |
| 2024-09-21 21:43:52 +0200 | synchromesh | (~john@2406:5a00:241a:5600:5db8:4c32:8611:a0fa) (Read error: Connection reset by peer) |
| 2024-09-21 21:44:24 +0200 | <EvanR> | I have no noticed any startup time in haskell |
| 2024-09-21 21:44:28 +0200 | <tomsmeding> | and the first thing after the wait is a futex wait |
| 2024-09-21 21:44:47 +0200 | <tomsmeding> | EvanR: `echo 'main = pure ()' >pure.hs; ghc pure.hs -o pure; time ./pure` |
| 2024-09-21 21:44:54 +0200 | <tomsmeding> | repeat that last command ~10 times |
| 2024-09-21 21:44:58 +0200 | <tomsmeding> | how long does that take? |
| 2024-09-21 21:45:11 +0200 | synchromesh | (~john@2406:5a00:241a:5600:5db8:4c32:8611:a0fa) |
| 2024-09-21 21:45:27 +0200 | <tuxpaint> | hmm. so it's waiting to exit or something? i noticed it was "slow" initially because of the time it spent to return me back to interactive |
| 2024-09-21 21:46:20 +0200 | <EvanR> | it says real = 0.012s or 0.013s but when you press enter on ./pure, I am back to the prompt instantly |
| 2024-09-21 21:46:33 +0200 | <EvanR> | without the time command |
| 2024-09-21 21:46:45 +0200 | <tomsmeding> | how instant is "instantly" :P |
| 2024-09-21 21:47:07 +0200 | <dolio> | Sufficiently instantly for like 99.999% of use cases. |
| 2024-09-21 21:47:11 +0200 | <tomsmeding> | that is true |
| 2024-09-21 21:47:24 +0200 | <EvanR> | imperceptibly different from the equivalent C program |
| 2024-09-21 21:47:57 +0200 | <tomsmeding> | in bash, I do notice a difference between 'echo hi' and './pure' |
| 2024-09-21 21:48:20 +0200 | <tomsmeding> | I notice it less in fish, apparently fish prompt drawing takes time too :') |
| 2024-09-21 21:48:34 +0200 | <EvanR> | I'll try xterm |
| 2024-09-21 21:48:35 +0200 | <tuxpaint> | i notice a difference in my zsh between ./pure and ./pureinc |
| 2024-09-21 21:48:43 +0200 | <EvanR> | the best term |
| 2024-09-21 21:48:45 +0200 | <tuxpaint> | terminal=st |
| 2024-09-21 21:49:21 +0200 | <EvanR> | in xterm there is noticable delay in haskell and C :( |
| 2024-09-21 21:49:56 +0200 | <EvanR> | probably because I have to tricked out with fancy font |
| 2024-09-21 21:49:59 +0200 | <EvanR> | it |
| 2024-09-21 21:50:03 +0200 | <tomsmeding> | tuxpaint: https://paste.tomsmeding.com/2YnbokDI |
| 2024-09-21 21:50:27 +0200 | <EvanR> | lol |
| 2024-09-21 21:50:28 +0200 | <tomsmeding> | definitely in shutdown :D |
| 2024-09-21 21:50:35 +0200 | <tomsmeding> | well there's still a few ms left |
| 2024-09-21 21:50:40 +0200 | <EvanR> | 0.012 and 0.013 is less than the monitor refresh rate xD |
| 2024-09-21 21:50:49 +0200 | <dolio> | Yeah. |
| 2024-09-21 21:50:52 +0200 | <tomsmeding> | oh hey |
| 2024-09-21 21:50:55 +0200 | <tomsmeding> | I have no compositor |
| 2024-09-21 21:50:58 +0200 | <tomsmeding> | maybe that makes a difference |
| 2024-09-21 21:51:02 +0200 | <tuxpaint> | i can feel the difference as well in xterm - 12ms vs 3ms is perceivable for sure for many users. i can't notice much between the 3ms with -V0.0001 and 1.1ms in c |
| 2024-09-21 21:51:06 +0200 | <tuxpaint> | i have no compositor |
| 2024-09-21 21:51:31 +0200 | <tomsmeding> | (I'm in st too) |
| 2024-09-21 21:51:36 +0200 | <tomsmeding> | (but in tmux) |
| 2024-09-21 21:51:43 +0200 | <EvanR> | yes some users can see the results of their keystrokes before they show up on the monitor |
| 2024-09-21 21:51:45 +0200 | <tuxpaint> | i am in tmux as well. twinning! |
| 2024-09-21 21:52:11 +0200 | <tomsmeding> | :D (though st being st, it's likely there is some tmux-like thing involved) |
| 2024-09-21 21:52:36 +0200 | <EvanR> | these are some serious super users |
| 2024-09-21 21:52:54 +0200 | <tuxpaint> | you also have your own paste! mine is in go, not haskell though |
| 2024-09-21 21:53:20 +0200 | <tomsmeding> | 3 out of 5 of the links in the /topic are hosted by me :p |
| 2024-09-21 21:53:26 +0200 | <tomsmeding> | (ircbrowse is not written by me, just hosted) |
| 2024-09-21 21:54:27 +0200 | <tomsmeding> | monochrom: I think you would also enjoy this https://paste.tomsmeding.com/2YnbokDI |
| 2024-09-21 21:54:47 +0200 | <monochrom> | Yeah I saw. Haha. |
| 2024-09-21 21:56:11 +0200 | <tuxpaint> | this is calling libc yes? |
| 2024-09-21 21:56:21 +0200 | <tomsmeding> | yes, this is calling exit(3) via the C FFI |
| 2024-09-21 21:56:36 +0200 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Ping timeout: 272 seconds) |
| 2024-09-21 21:57:11 +0200 | <tuxpaint> | curious - is it possible at all to do syscalls in haskell without libc? |
| 2024-09-21 21:58:19 +0200 | <tomsmeding> | without libc, yes, without C, no, I think |
| 2024-09-21 21:58:40 +0200 | <tomsmeding> | as in, you can FFI to a function written in C, and in C you can do syscalls without needing libc |
| 2024-09-21 21:58:43 +0200 | euphores | (~SASL_euph@user/euphores) (Ping timeout: 245 seconds) |
| 2024-09-21 21:58:50 +0200 | <tomsmeding> | but haskell does not have some kind of inline assembly |
| 2024-09-21 22:00:23 +0200 | zero | zzz |
| 2024-09-21 22:02:18 +0200 | <geekosaur> | not reliably without libc |
| 2024-09-21 22:02:38 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:03:00 +0200 | <geekosaur> | the kernel's interface with glibc changes constantly. alternative libcs like musl need to keep up, and if something changed that they don't know about your program will crash |
| 2024-09-21 22:03:01 +0200 | <EvanR> | ghc generates its own code right |
| 2024-09-21 22:03:04 +0200 | <tuxpaint> | got it, makes sense |
| 2024-09-21 22:03:13 +0200 | <EvanR> | or experts llvm |
| 2024-09-21 22:03:14 +0200 | <tomsmeding> | geekosaur: surely that's false on linux? |
| 2024-09-21 22:03:24 +0200 | <geekosaur> | no, it is especially true on linux |
| 2024-09-21 22:03:31 +0200 | <tomsmeding> | wasn't Linus' mantra "don't break userspace"? |
| 2024-09-21 22:03:36 +0200 | <tuxpaint> | i am coming from golang world, where syscalls are implemented without any C. I know it is rather unique to go. |
| 2024-09-21 22:03:46 +0200 | <geekosaur> | yes, he did it by making a contract with the glibc maintainers |
| 2024-09-21 22:03:48 +0200 | <tomsmeding> | I know on macos the syscall interface is unstable |
| 2024-09-21 22:03:56 +0200 | <tomsmeding> | TIL |
| 2024-09-21 22:04:06 +0200 | <EvanR> | sounds like golang likes job security |
| 2024-09-21 22:04:20 +0200 | <geekosaur> | and glibc has massive amounts of code to look up and adapt to specific kernel versions' ABIs |
| 2024-09-21 22:04:20 +0200 | <EvanR> | constantly following changes in linux |
| 2024-09-21 22:04:27 +0200 | <tomsmeding> | I mean, exit(2) probably isn't going anywhere |
| 2024-09-21 22:04:37 +0200 | <geekosaur> | it did, actually |
| 2024-09-21 22:05:48 +0200 | <geekosaur> | In glibc up to version 2.3, the _exit() wrapper function invoked the kernel system call of the same name. Since |
| 2024-09-21 22:05:49 +0200 | <geekosaur> | glibc 2.3, the wrapper function invokes exit_group(2), in order to terminate all of the threads in a process. |
| 2024-09-21 22:05:49 +0200 | <geekosaur> | (The raw _exit() system call terminates only the calling thread.) |
| 2024-09-21 22:06:30 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-09-21 22:06:38 +0200 | <tomsmeding> | tuxpaint: seems those 6ms and 15ms numbers were including some shell overhead. I installed hyperfine, and `hyperfine -N ./pure` (i.e. not going via the shell) yields 13.8ms without exit(3), and 0.93ms with exit(3) |
| 2024-09-21 22:06:42 +0200 | <geekosaur> | (this is not according to POSIX, iirc, threads are associated with a process and _exit() kills the entire process. thanks the old LinuxThreads disaster for this) |
| 2024-09-21 22:06:47 +0200 | <tomsmeding> | seems almost _all_ of the time is spent in shutdown |
| 2024-09-21 22:06:59 +0200 | <tuxpaint> | yeah, i'm getting 1.1ms with exit() with hyperfine -N |
| 2024-09-21 22:07:22 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 272 seconds) |
| 2024-09-21 22:07:27 +0200 | <tomsmeding> | that seems within cpu speed variation |
| 2024-09-21 22:07:32 +0200 | <tomsmeding> | geekosaur: TIL |
| 2024-09-21 22:07:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 22:07:46 +0200 | <monochrom> | If you s/ccall "exit"/capi "stdlib.h exit"/ it will be more portable over various platforms that may make "exit()" a function or a macro or a syscall or anything. |
| 2024-09-21 22:08:02 +0200 | <tomsmeding> | monochrom: I know |
| 2024-09-21 22:08:02 +0200 | troojg | (~troojg@user/troojg) |
| 2024-09-21 22:08:03 +0200 | <geekosaur> | ^ |
| 2024-09-21 22:08:05 +0200 | <monochrom> | (The price is of course the compile time is longer.) |
| 2024-09-21 22:08:07 +0200 | <tuxpaint> | EvanR: its somewhat required as part of design, since having non-go code, or linking to libc would remove the "fast compilation speed and compile everything from scratch" feature. |
| 2024-09-21 22:08:11 +0200 | <monochrom> | OK heh :) |
| 2024-09-21 22:08:22 +0200 | <tuxpaint> | and yeah, it's google. they probably need more jobs for the employees they already have :) |
| 2024-09-21 22:09:00 +0200 | <geekosaur> | no, they just want absolute speed and went the accursedUnutterablePerformIO route |
| 2024-09-21 22:09:39 +0200 | <tomsmeding> | ah good, capi vs ccall import doesn't make a difference in timing |
| 2024-09-21 22:09:41 +0200 | <geekosaur> | so they can't update a kernel without auditing the kernel/libc interface and updating their go libs, or they get random crashes |
| 2024-09-21 22:09:58 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-21 22:10:12 +0200 | <EvanR> | move fast break things |
| 2024-09-21 22:10:21 +0200 | <tomsmeding> | tuxpaint: seems we have a workaround? :p |
| 2024-09-21 22:10:25 +0200 | <tuxpaint> | yep! |
| 2024-09-21 22:10:33 +0200 | <tuxpaint> | if you do syscalls through libc you have to do calls which fuck with the go scheduler. |
| 2024-09-21 22:10:37 +0200 | <tomsmeding> | use the capi style though, for the reasons monochrom mentioned |
| 2024-09-21 22:11:03 +0200 | <geekosaur> | (more likely they watch the commits list very closely so they have the necessary library changes by the time it's released) |
| 2024-09-21 22:11:24 +0200 | <tuxpaint> | it's not about absolute speed, it locks up the runtime and would make the language unusable |
| 2024-09-21 22:11:37 +0200 | <tomsmeding> | https://paste.tomsmeding.com/WzVl8hRp |
| 2024-09-21 22:11:50 +0200 | <tomsmeding> | note that buffers are not flushed by the RTS upon exit(3) |
| 2024-09-21 22:13:18 +0200 | <tomsmeding> | tuxpaint: that sounds weird to me; libc surely doesn't lock up the runtime any more than a system call does. The only reason would be that libc has overhead -- which I can accept -- but that would still just be "doing syscalls directly is faster". |
| 2024-09-21 22:13:41 +0200 | <tuxpaint> | it becomes a task that is uninterruptable by the go runtime, since the syscall is happening outside of the runtime, it has to make the most conservative assumptions possible |
| 2024-09-21 22:13:49 +0200 | <tomsmeding> | libc is just C code, which is just additional work that happens before and after the syscall -- which itself is just work that happens on a different privilege level |
| 2024-09-21 22:14:01 +0200 | <geekosaur> | blocking syscalls would be a problem, imagine that a go syscall is Haskell's `unsafe` |
| 2024-09-21 22:14:05 +0200 | <tomsmeding> | but a syscall is also uninterruptible |
| 2024-09-21 22:14:36 +0200 | <tomsmeding> | well, some are, but then the libc call would also be |
| 2024-09-21 22:14:49 +0200 | <tomsmeding> | (surely?) |
| 2024-09-21 22:15:18 +0200 | <geekosaur> | right, but you're not supposed to do either, you use the go function which offloads the call (similarly to Haskell's `safe`) so it doesn't block the scheduler |
| 2024-09-21 22:15:36 +0200 | <tomsmeding> | of course, but we're talking about how said go function is implemented |
| 2024-09-21 22:16:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:16:23 +0200 | <tomsmeding> | eventually there is some code in go's stdlib or RTS that does the actual syscall, be it directly or through libc |
| 2024-09-21 22:16:27 +0200 | <geekosaur> | right, I assume it offloads the actual call to a thread that isn't part of the scheduler so it can safely block |
| 2024-09-21 22:16:44 +0200 | <geekosaur> | similarly to what ghc's RTS does with `safe` calls |
| 2024-09-21 22:16:58 +0200 | <tomsmeding> | I dunno, maybe. But if so, then what's the difference (to go) between a syscall and a libc function that wraps that syscall? |
| 2024-09-21 22:17:11 +0200 | <tomsmeding> | (apart from the latter possibly being a little slower) |
| 2024-09-21 22:17:31 +0200 | <geekosaur> | speed. did you notice earlier when I mentioned the extra code to check kernel ABI versions? |
| 2024-09-21 22:17:50 +0200 | <tomsmeding> | sure, but tuxpaint is claiming that there is more than just speed |
| 2024-09-21 22:17:57 +0200 | <geekosaur> | I assume go's stdlib is wired to a particular kernel ABI and doesn't need the runtime checks |
| 2024-09-21 22:18:21 +0200 | <tuxpaint> | in go there is gomaxprocs, so each blocking thread takes a slot from gomaxprocs. say you have 20 slots, a cgo call will take one of those 20 slots when invoked, and cannot unblock the worker. |
| 2024-09-21 22:19:00 +0200 | <geekosaur> | other things that come up are C-style global constructors/destructors and things that look like syscalls but aren't directly and may use services like malloc which could well fail with the go runtime because the C runtime isn't initialized |
| 2024-09-21 22:19:11 +0200 | <tuxpaint> | while the pure-go syscall, they can unblock the worker and do something else while the syscall is waiting |
| 2024-09-21 22:19:26 +0200 | <tuxpaint> | and it doesn't take up when waiting, one of your gomaxprocs slots |
| 2024-09-21 22:19:31 +0200 | <tomsmeding> | tuxpaint: if you perform a syscall, your thread is blocked |
| 2024-09-21 22:19:39 +0200 | <geekosaur> | (ghc ensures the C RTS is set up, but go's pure-go approach means it probably isn't and going through libc will therefore be dangerous) |
| 2024-09-21 22:19:45 +0200 | <tomsmeding> | so something is contradictory here |
| 2024-09-21 22:19:51 +0200 | <tuxpaint> | the runtime does not see that thread as a thread that is "working" |
| 2024-09-21 22:19:58 +0200 | <geekosaur> | right |
| 2024-09-21 22:20:03 +0200 | <geekosaur> | like ghc's IO manager threads |
| 2024-09-21 22:20:12 +0200 | <tomsmeding> | ... okay, but the thread is still blocked and can't do anything else |
| 2024-09-21 22:20:26 +0200 | <geekosaur> | the IO manager manages them separately from standard threads |
| 2024-09-21 22:20:39 +0200 | <tomsmeding> | fine, but you still have a thread less for "normal" go code! |
| 2024-09-21 22:20:55 +0200 | <geekosaur> | no? it fires off completely separate threads for that |
| 2024-09-21 22:20:55 +0200 | <tuxpaint> | you can launch another thread and do work, you are not frozen |
| 2024-09-21 22:21:01 +0200 | <tomsmeding> | it's not like that `syscall` instruction can magically go off and run asynchronously |
| 2024-09-21 22:21:02 +0200 | <tuxpaint> | gomaxprocs does not determine the max amount of system threads |
| 2024-09-21 22:21:23 +0200 | <tomsmeding> | okay, but if you're willing to start another thread for that syscall, why not run the libc call in that new thread too? |
| 2024-09-21 22:21:30 +0200 | <tomsmeding> | I still don't see what the difference is |
| 2024-09-21 22:21:36 +0200 | <geekosaur> | you still don't have loibc initialized |
| 2024-09-21 22:21:46 +0200 | <tuxpaint> | yes, you can set gomaxprocs to a very high number, and do one thread per syscall |
| 2024-09-21 22:21:52 +0200 | <tomsmeding> | that's just `start()` at the start of the go _process_ |
| 2024-09-21 22:21:53 +0200 | <geekosaur> | libc *has a runtime*. go does not initialize that runtume |
| 2024-09-21 22:21:54 +0200 | <tuxpaint> | it makes it faster, but it's still very very slow |
| 2024-09-21 22:21:56 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds) |
| 2024-09-21 22:22:00 +0200 | <geekosaur> | libc calls can therefore crash |
| 2024-09-21 22:22:19 +0200 | <tuxpaint> | as in, unusably slow for many disk operations (think database) |
| 2024-09-21 22:22:47 +0200 | <tomsmeding> | tuxpaint: why could the runtime not spawn up a new system thread, that is _not_ registered as a go worker, to run the libc call in? |
| 2024-09-21 22:22:57 +0200 | <geekosaur> | (glibc's RTS startup actually does quite a lot, if you strace a program you'll see a _lot_ of activity before main() is called) |
| 2024-09-21 22:23:07 +0200 | <tomsmeding> | this libc call is written by go developers in the go standard library, it's not a random go programmer that goes through the cgo interface |
| 2024-09-21 22:23:31 +0200 | <tomsmeding> | and anyway, freeing up a worker is lying to yourself, because the time that you spend in kernel mode is also cpu time |
| 2024-09-21 22:23:32 +0200 | <tuxpaint> | well now you are calling libc right? |
| 2024-09-21 22:23:33 +0200 | <geekosaur> | …right, never mind |
| 2024-09-21 22:23:40 +0200 | <tuxpaint> | so you either need to link it, or rebuild it every time |
| 2024-09-21 22:23:47 +0200 | <tomsmeding> | geekosaur: right, but you just do that once, right? |
| 2024-09-21 22:23:49 +0200 | <tuxpaint> | which defeats the goal of having portable static binaries, and very fast build times |
| 2024-09-21 22:24:01 +0200 | <tuxpaint> | for such static binaries |
| 2024-09-21 22:24:10 +0200 | <geekosaur> | tomsmeding, in the go world you do _not_ call it. at all. |
| 2024-09-21 22:24:12 +0200 | <tomsmeding> | tuxpaint: is that linking/rebuilding/static binaries reason the only reason to not want to link libc? |
| 2024-09-21 22:24:22 +0200 | <tuxpaint> | imo yes. and it's a major language feature of go |
| 2024-09-21 22:24:24 +0200 | <tomsmeding> | because previously you were claiming, repeatedly, that there is a real runtime cost |
| 2024-09-21 22:24:29 +0200 | <geekosaur> | that's the whole point of this, libc is replaced by go's RTS |
| 2024-09-21 22:24:35 +0200 | <tomsmeding> | _apart_ from initialisation at the start of the process |
| 2024-09-21 22:24:53 +0200 | <tuxpaint> | there is no libc at all, that is one of the goals |
| 2024-09-21 22:25:04 +0200 | <tomsmeding> | and I have been trying to reason that there is no such cost, apart from libc being somewhat slower, which is what geekosaur has been saying all the time already |
| 2024-09-21 22:25:06 +0200 | <geekosaur> | and I told you part of what that runtime cost was |
| 2024-09-21 22:25:17 +0200 | <geekosaur> | but I'm bailing since I'm apparently talking to a wall |
| 2024-09-21 22:25:17 +0200 | <tuxpaint> | and its to have the fast compile times, and to compile the entire project from source every compile |
| 2024-09-21 22:25:18 +0200 | <tomsmeding> | as far as I understand, the gomaxprocs story is all irrelevant |
| 2024-09-21 22:25:26 +0200 | <tomsmeding> | I get that! |
| 2024-09-21 22:25:49 +0200 | <tomsmeding> | I get that 1. linking with libc means that the compiler has to do more, and that 2. going via libc takes longer than just doing the syscall, and 3. initialising libc takes time |
| 2024-09-21 22:25:50 +0200 | <geekosaur> | libc does extra runtime checks, it randomly wraps syscalls with extra goop that updates libc internal data, etc, |
| 2024-09-21 22:25:58 +0200 | <tomsmeding> | but you were saying that there's _more_ and I still haven't gotten clear what that is :p |
| 2024-09-21 22:26:13 +0200 | <tomsmeding> | I fucking KNOW, you two :') |
| 2024-09-21 22:26:27 +0200 | <tomsmeding> | sorry for the outburst |
| 2024-09-21 22:26:32 +0200 | <tuxpaint> | the only way to use libc in go is through CGO, it's treated as any other c library |
| 2024-09-21 22:26:40 +0200 | <tuxpaint> | there's no special things to handle libc safely, if that is what you are asking? |
| 2024-09-21 22:26:50 +0200 | <tomsmeding> | that is exactly what I'm asking |
| 2024-09-21 22:26:56 +0200 | <tuxpaint> | i guess you could make your own special wrappers with safety guarantees around each libc, yes |
| 2024-09-21 22:27:03 +0200 | <tuxpaint> | i think the go team felt that was just as much effort as doing it themselves |
| 2024-09-21 22:27:14 +0200 | <tomsmeding> | and I claim that these (hypothetical) libc calls are written by go developers in the go stdlib, so there's no good reason to have to go through all the usual hoops |
| 2024-09-21 22:27:33 +0200 | <tomsmeding> | libc calls can crash, but syscalls also can |
| 2024-09-21 22:27:39 +0200 | <geekosaur> | now you're in a quasi-philosophical argument with the go devs |
| 2024-09-21 22:27:43 +0200 | <tuxpaint> | yeah, there's no special handling of libc |
| 2024-09-21 22:27:50 +0200 | <geekosaur> | and, well, this is part of why I dont like or use go |
| 2024-09-21 22:27:59 +0200 | <tomsmeding> | tuxpaint: thank you, that answers my question :p |
| 2024-09-21 22:28:10 +0200 | <tomsmeding> | (something got lost in communication here, somewhere) |
| 2024-09-21 22:28:12 +0200 | <tuxpaint> | whether you should implement the syscalls with pure go, or handle libc specially, idk which is better |
| 2024-09-21 22:28:28 +0200 | <geekosaur> | google apparently thinks it's a good thing; I have not heard any statistics to back them up, but I;m sure they have them (but how true are they? lies, damned lies, and…) |
| 2024-09-21 22:28:30 +0200 | <tuxpaint> | but they're paying for it and it works. |
| 2024-09-21 22:29:11 +0200 | <tomsmeding> | right, direct syscalls vs libc handling is a game of tradeoffs: needing to track linux syscall ABI vs a little overhead |
| 2024-09-21 22:29:18 +0200 | <tuxpaint> | personally, as the developer i don't really care. if they changed how it worked one day i wouldn't really bat an eye. |
| 2024-09-21 22:29:30 +0200 | <geekosaur> | (and, of course, sunk cost fallacy such that if they turned out to be false, they think turning back would be too much work) |
| 2024-09-21 22:30:04 +0200 | <tuxpaint> | which is one of the ideas of go - don't worry too much about implementation, just write go code and let the language implementation people make the go code faster for you as the language evolves |
| 2024-09-21 22:30:39 +0200 | <tomsmeding> | (isn't that the idea of every language :p) |
| 2024-09-21 22:30:46 +0200 | <monochrom> | I will do quasi-politics instead. They say it's for speed, but I say it's for politics. If you go through any C lib, you confess that C is still native. Well Go wants to replace C and be called the new native, of course it can't go through a C lib for posture. |
| 2024-09-21 22:31:19 +0200 | <geekosaur> | I think not, I really do think they need to do this for speed |
| 2024-09-21 22:31:24 +0200 | <tuxpaint> | tomsmeding: you would think? but thinking about how many ways there are to do x in rust/c makes me think not |
| 2024-09-21 22:31:30 +0200 | <geekosaur> | which is why I compared it to accursedUnutterablePerformIO |
| 2024-09-21 22:31:54 +0200 | <monochrom> | Now imagine 10 years from now we Haskellers have to write "foreign import goapi" instead haha. |
| 2024-09-21 22:32:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:32:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 22:32:43 +0200 | <monochrom> | (Fortunately it didn't happen during the last 10 years, so by "induction" we're safe.) |
| 2024-09-21 22:32:46 +0200 | <tomsmeding> | tuxpaint: maybe, yes |
| 2024-09-21 22:32:59 +0200 | <tuxpaint> | dont worry. go can barely even do that within go. the plugin system requires everything to be compiled with the exact same compiler version, and it's awful |
| 2024-09-21 22:33:16 +0200 | <tuxpaint> | there is 0 stability guarantee for any go internals between versions. |
| 2024-09-21 22:33:41 +0200 | <tuxpaint> | that is all "implementation", developers are "not supposed to rely on it" |
| 2024-09-21 22:35:46 +0200 | <tuxpaint> | typical plugins systems are either grpc or wasm. and because of the cgo overhead, it's very common to compile code -> wasm, then use a pure-go wasm runtime. |
| 2024-09-21 22:36:45 +0200 | <tuxpaint> | even plugins written in go, many of them are written in go, then compiled via tinygo to wasm, then run via like wazero in go. since zero compatiblity between go versions. |
| 2024-09-21 22:37:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 22:43:54 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2024-09-21 22:47:17 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 22:47:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:50:45 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2024-09-21 22:51:55 +0200 | <EvanR> | more job security xD |
| 2024-09-21 22:52:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 23:03:24 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-09-21 23:03:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 23:08:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-09-21 23:17:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 23:17:29 +0200 | mikess | (~mikess@user/mikess) |
| 2024-09-21 23:20:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 23:22:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-21 23:27:59 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 23:30:46 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) |
| 2024-09-21 23:33:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-21 23:39:22 +0200 | athan | (~athan@syn-098-153-145-140.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-09-21 23:43:46 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 23:46:26 +0200 | pavonia | (~user@user/siracusa) |
| 2024-09-21 23:47:15 +0200 | aljazmc | (~aljazmc@user/aljazmc) |
| 2024-09-21 23:48:54 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-21 23:51:20 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-09-21 23:57:46 +0200 | aljazmc | (~aljazmc@user/aljazmc) (Quit: Leaving) |
| 2024-09-21 23:59:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |