Newest at the top
| 2025-12-11 20:06:47 +0100 | kuribas | (~user@2a02:1808:cd:df9d:3fd8:99c:a12:7c8) kuribas |
| 2025-12-11 20:05:36 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2025-12-11 20:03:48 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-12-11 20:03:05 +0100 | omidmash | (~omidmash@user/omidmash) omidmash |
| 2025-12-11 20:02:25 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-11 20:01:30 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-11 20:01:09 +0100 | Googulator | (~Googulato@87-97-86-146.pool.digikabel.hu) |
| 2025-12-11 20:01:02 +0100 | Googulator | (~Googulato@87-97-86-146.pool.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 19:58:38 +0100 | califax | (~califax@user/califx) califx |
| 2025-12-11 19:57:28 +0100 | omidmash | (~omidmash@user/omidmash) (Quit: The Lounge - https://thelounge.chat) |
| 2025-12-11 19:57:06 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-12-11 19:50:57 +0100 | __monty__ | (~toonn@user/toonn) (Ping timeout: 256 seconds) |
| 2025-12-11 19:45:28 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2025-12-11 19:45:22 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2025-12-11 19:43:27 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Ping timeout: 252 seconds) |
| 2025-12-11 19:43:13 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2025-12-11 19:42:04 +0100 | kuribas | (~user@2a02:1808:cd:df9d:1dcb:cff3:20e8:95d8) (Ping timeout: 246 seconds) |
| 2025-12-11 19:38:35 +0100 | raym | (~ray@user/raym) raym |
| 2025-12-11 19:36:55 +0100 | raym | (~ray@user/raym) (Ping timeout: 240 seconds) |
| 2025-12-11 19:31:10 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 245 seconds) |
| 2025-12-11 19:30:24 +0100 | spew | (~spew@user/spew) (Quit: WeeChat 4.7.2) |
| 2025-12-11 19:28:50 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-12-11 19:18:46 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-12-11 19:16:10 +0100 | <EvanR> | return to the world |
| 2025-12-11 19:15:58 +0100 | <EvanR> | level 60, you're done |
| 2025-12-11 19:15:27 +0100 | ft | (~ft@p508db844.dip0.t-ipconnect.de) ft |
| 2025-12-11 19:15:06 +0100 | <Rembane> | Finally max level! |
| 2025-12-11 19:14:44 +0100 | <haskellbridge> | <Morj> Sadder still is that I thought I finished learning |
| 2025-12-11 19:14:39 +0100 | <EvanR> | ;_; |
| 2025-12-11 19:14:31 +0100 | <haskellbridge> | <Morj> I've been learning erlang recently, and haven't seen anything about transactional semantics. Sad |
| 2025-12-11 19:12:45 +0100 | <haskellbridge> | <sm> I haven't used erlang, but yes that sounds right, they like to throw something away if it fails |
| 2025-12-11 19:12:01 +0100 | <haskellbridge> | <sm> same principle |
| 2025-12-11 19:11:49 +0100 | <haskellbridge> | <sm> that's running software rather than dev in process, but you know what I mean |
| 2025-12-11 19:11:46 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-12-11 19:11:05 +0100 | <haskellbridge> | <sm> I know php is a good example, you get a fresh state every request |
| 2025-12-11 19:10:38 +0100 | <EvanR> | which is not what erlang is usually promoting |
| 2025-12-11 19:10:23 +0100 | <EvanR> | well, transactional semantics are a good way to deal with that assumption |
| 2025-12-11 19:09:21 +0100 | <gentauro> | haskellbridge: that's actually the foundation of Erlang right? We know we are gonna fail at some point, lets add that to the equation. |
| 2025-12-11 19:09:19 +0100 | Square | (~Square4@user/square) (Ping timeout: 240 seconds) |
| 2025-12-11 19:07:18 +0100 | Googulator24 | Googulator |
| 2025-12-11 19:06:55 +0100 | Googulator24 | (~Googulato@87-97-86-146.pool.digikabel.hu) |
| 2025-12-11 19:06:45 +0100 | tromp | (~textual@2001:1c00:3487:1b00:dd4:56d:fd02:60e2) |
| 2025-12-11 19:06:43 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2025-12-11 19:06:33 +0100 | Googulator24 | (~Googulato@2a01-036d-0106-01cb-8583-2a78-a55c-bee5.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-11 19:05:20 +0100 | <haskellbridge> | <sm> I guess my point is, as we work with computers and tools we are working with very complex state which will never be entirely bug free, sometimes it's more cost effective to try a state reset than to debug what's going wrong |
| 2025-12-11 19:04:09 +0100 | Guest87 | (~Guest87@2405:201:d006:986f:5c73:3a20:69d:7d07) (Quit: Client closed) |
| 2025-12-11 19:03:55 +0100 | <geekosaur> | see `patchelf` |
| 2025-12-11 19:03:47 +0100 | <geekosaur> | in particular, it varies on NixOS |
| 2025-12-11 19:03:37 +0100 | <haskellbridge> | <sm> (not something I would do often, but sometimes the dumb hands-free test is worth doing) |
| 2025-12-11 19:03:27 +0100 | <geekosaur> | leading to confusing error messages because `exec` has no way to pass back precisely what wasn't found |