2025/03/28

Newest at the top

2025-03-28 18:30:59 +0100 <absence> merijn: f' g' and h' are applicative functors that return some operation (e.g. "pure (+1)"), so I just want to apply them.
2025-03-28 18:30:39 +0100euphores(~SASL_euph@user/euphores) (Quit: Leaving.)
2025-03-28 18:29:52 +0100tromp(~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-03-28 18:29:41 +0100L29Ah(~L29Ah@wikipedia/L29Ah) L29Ah
2025-03-28 18:24:24 +0100OlzhasYergali(~OlzhasYer@188.130.156.6)
2025-03-28 18:24:14 +0100 <merijn> absence: What's it trying to accomplish?
2025-03-28 18:23:54 +0100 <EvanR> are you sure you don't want to reverse the applicative or something
2025-03-28 18:23:47 +0100 <merijn> I can't tell if that's trying to be idiom brackets or something else
2025-03-28 18:23:02 +0100 <absence> Is there a way to do something like "(\f g h a -> f (g (h a))) <$> f' <*> g' <*> h' <*> a'" without having to manually specify the combining function to the left?
2025-03-28 18:22:40 +0100 <lambdabot> [Char] -> c
2025-03-28 18:22:39 +0100 <EvanR> :t fix . error
2025-03-28 18:22:00 +0100weary-traveler(~user@user/user363627) user363627
2025-03-28 18:17:35 +0100Sgeo(~Sgeo@user/sgeo) Sgeo
2025-03-28 18:12:53 +0100acidjnk(~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) acidjnk
2025-03-28 18:06:18 +0100 <lambdabot> Floating c => c -> c
2025-03-28 18:06:17 +0100 <int-e> :t abs . sin
2025-03-28 18:06:09 +0100 <lambdabot> Num a => a -> a
2025-03-28 18:06:07 +0100 <int-e> :t abs
2025-03-28 18:06:00 +0100jespada(~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) jespada
2025-03-28 17:58:20 +0100L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 265 seconds)
2025-03-28 17:58:09 +0100nitrix(~nitrix@user/meow/nitrix) nitrix
2025-03-28 17:55:04 +0100acidjnk(~acidjnk@p200300d6e71c4f71c835c1b6e3010b6c.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2025-03-28 17:51:40 +0100 <monochrom> But I thought you would want to absolve, not resolve, your sin. >:)
2025-03-28 17:51:19 +0100nitrix(~nitrix@user/meow/nitrix) (Ping timeout: 260 seconds)
2025-03-28 17:51:18 +0100pyooquepuke
2025-03-28 17:51:18 +0100puke(~puke@user/puke) (Killed (erbium.libera.chat (Nickname regained by services)))
2025-03-28 17:51:17 +0100pyooque(~puke@user/puke) puke
2025-03-28 17:46:54 +0100 <monochrom> "You must not sin." >:)
2025-03-28 17:44:23 +0100prasad(~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net)
2025-03-28 17:41:48 +0100chele(~chele@user/chele) (Remote host closed the connection)
2025-03-28 17:38:11 +0100malte(~malte@mal.tc) malte
2025-03-28 17:34:05 +0100prasad(~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) (Read error: Connection reset by peer)
2025-03-28 17:31:31 +0100 <EvanR> in the far lands
2025-03-28 17:31:27 +0100 <EvanR> watch yourself
2025-03-28 17:31:19 +0100 <EvanR> it's true "correct rounded result" guarantee doesn't cover the entire domain of sin in ieee754
2025-03-28 17:30:37 +0100 <jle`> that's deep
2025-03-28 17:30:37 +0100 <tomsmeding> EvanR: floating-point numbers only go so far though
2025-03-28 17:30:23 +0100 <tomsmeding> cheers :)
2025-03-28 17:30:20 +0100 <EvanR> (actually, sin has unlimited radius of convergence so there's that)
2025-03-28 17:30:14 +0100 <agentultra> thanks again for all your help :D
2025-03-28 17:29:57 +0100 <tomsmeding> :)
2025-03-28 17:29:52 +0100 <agentultra> well, they'll have a bug report coming soon to get the process started.
2025-03-28 17:29:40 +0100 <EvanR> the good news about libm
2025-03-28 17:29:28 +0100 <tomsmeding> EvanR: it's not at all, just declare that you depend on libm
2025-03-28 17:29:08 +0100 <tomsmeding> it's ld-linux.so, the runtime linker itself, that is relevant here (which is, despite its name, actually an executable)
2025-03-28 17:28:56 +0100 <agentultra> gotcha... that seems reasonable
2025-03-28 17:28:55 +0100 <EvanR> it is indeed difficult to resolve one's own sin
2025-03-28 17:28:34 +0100 <tomsmeding> dlopen is not involved here, that is for manually calling into the runtime linker at runtime
2025-03-28 17:28:20 +0100 <tomsmeding> hence in the second case, `sin` remains unresolved, which results in an error at runtime
2025-03-28 17:28:01 +0100 <tomsmeding> `sin`, but then afterwards, tb_client introduces new ones. The second occurrence of -lm (this is where I'm a bit unsure) is ignored because libm was already specified (?)