Newest at the top
| 2025-03-28 18:29:52 +0100 | tromp | (~textual@2001:1c00:3487:1b00:6095:11f3:6fa5:fb3d) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-03-28 18:29:41 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-03-28 18:24:24 +0100 | OlzhasYergali | (~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 +0100 | weary-traveler | (~user@user/user363627) user363627 |
| 2025-03-28 18:17:35 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-28 18:12:53 +0100 | acidjnk | (~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 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) jespada |
| 2025-03-28 17:58:20 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 265 seconds) |
| 2025-03-28 17:58:09 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-03-28 17:55:04 +0100 | acidjnk | (~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 +0100 | nitrix | (~nitrix@user/meow/nitrix) (Ping timeout: 260 seconds) |
| 2025-03-28 17:51:18 +0100 | pyooque | puke |
| 2025-03-28 17:51:18 +0100 | puke | (~puke@user/puke) (Killed (erbium.libera.chat (Nickname regained by services))) |
| 2025-03-28 17:51:17 +0100 | pyooque | (~puke@user/puke) puke |
| 2025-03-28 17:46:54 +0100 | <monochrom> | "You must not sin." >:) |
| 2025-03-28 17:44:23 +0100 | prasad | (~Thunderbi@c-73-246-138-70.hsd1.in.comcast.net) |
| 2025-03-28 17:41:48 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2025-03-28 17:38:11 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-28 17:34:05 +0100 | prasad | (~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 (?) |
| 2025-03-28 17:27:59 +0100 | <tomsmeding> | agentultra: I think this is what's happening (but take this with a grain of salt): the `sin` symbol is Weak in libtb_client.so (as we saw), which means (man 1 nm) that it's allowed to be undefined at link time. When compiling with -ltb_client -lm, `sin` is first undefined, and then libm provides a definition. When compiling with -lm -tb_client -lm, the first -lm resolves any missing references to |
| 2025-03-28 17:26:36 +0100 | <agentultra> | I'm going to see if they'll accept a patch from me to to change their linker options, if that's even possible. The library is actually written in Zig :S |