Newest at the top
| 2024-11-18 19:31:54 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-18 19:31:17 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2024-11-18 19:31:12 +0100 | son0p | (~ff@2800:e6:4001:6cc3:2748:5c2a:65d9:57ac) (Ping timeout: 244 seconds) |
| 2024-11-18 19:31:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-11-18 19:20:41 +0100 | ystael | (~ystael@user/ystael) (Read error: Connection reset by peer) |
| 2024-11-18 19:17:49 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2024-11-18 19:17:32 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-18 19:15:09 +0100 | Wygulmage | (~k`@user/Wygulmage) (Quit: Client closed) |
| 2024-11-18 19:15:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-18 19:08:16 +0100 | kuribas | (~user@ptr-17d51eowbvu84pzojhe.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2024-11-18 19:07:05 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2024-11-18 19:05:59 +0100 | dpk | (~dpk@jains.nonceword.org) (Ping timeout: 260 seconds) |
| 2024-11-18 19:04:52 +0100 | Alleria | (~Alleria@user/alleria) (Client Quit) |
| 2024-11-18 19:03:05 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Quit: Nothing to see here. I wasn't there.) |
| 2024-11-18 19:03:04 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 260 seconds) |
| 2024-11-18 19:02:41 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 19:02:25 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 19:01:33 +0100 | euleritian | (~euleritia@77.22.252.159) (Ping timeout: 276 seconds) |
| 2024-11-18 19:01:27 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-11-18 19:00:34 +0100 | Alleria | (~Alleria@user/alleria) (Max SendQ exceeded) |
| 2024-11-18 18:59:24 +0100 | <iteratee> | with the root cause buried in the crypton-x509-store library. |
| 2024-11-18 18:59:03 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-18 18:58:18 +0100 | <iteratee> | it turned out that `credentialLoadX509` and `credentialLoadX509FromMemory` were returning the certificates in differing orders. |
| 2024-11-18 18:57:50 +0100 | ft | (~ft@p4fc2a26f.dip0.t-ipconnect.de) ft |
| 2024-11-18 18:56:29 +0100 | Alleria | (~Alleria@user/alleria) Alleria |
| 2024-11-18 18:55:50 +0100 | <iteratee> | I was getting certificate issues with the direct connection that I wasn't getting with the same certificate served by my reverse proxy. |
| 2024-11-18 18:54:58 +0100 | <iteratee> | so I created a UDP load balancer that went directly to my webserver. This means that the webserver needs the correct certificates to answer with quic. |
| 2024-11-18 18:54:22 +0100 | euleritian | (~euleritia@77.22.252.159) |
| 2024-11-18 18:53:57 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-11-18 18:53:56 +0100 | Alleria_ | (~Alleria@user/alleria) (Max SendQ exceeded) |
| 2024-11-18 18:53:26 +0100 | <iteratee> | My load balancer will answer requests via QUIC, but will only connect downstream via TCP. |
| 2024-11-18 18:52:58 +0100 | <iteratee> | Chased down an interesting bug recently. I was trying to set up direct QUIC access to a server I have running. |
| 2024-11-18 18:52:47 +0100 | killerstorm | (~killersto@224.225.60.94.rev.vodafone.pt) (Quit: Client closed) |
| 2024-11-18 18:49:25 +0100 | iteratee | (~kyle@162.218.222.207) |
| 2024-11-18 18:48:07 +0100 | Alleria_ | (~Alleria@user/alleria) Alleria |
| 2024-11-18 18:47:07 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f69701fb6560bc0f0be.dip0.t-ipconnect.de) acidjnk |
| 2024-11-18 18:34:15 +0100 | hellwolf | (~user@ce28-37de-4848-1507-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
| 2024-11-18 18:33:55 +0100 | hellwolf | (~user@04ed-dbc2-42ba-2a72-0f00-4d40-07d0-2001.sta.estpak.ee) (Remote host closed the connection) |
| 2024-11-18 18:32:07 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3113-e8b3-4dc5-4d20-737c-18a7.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-18 18:28:13 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-18 18:26:09 +0100 | shapr | (~user@2600:4040:5c49:5600:7905:5c67:d410:b5e3) (Ping timeout: 248 seconds) |
| 2024-11-18 18:25:27 +0100 | <zzz> | thanks |
| 2024-11-18 18:25:25 +0100 | <zzz> | i actually prefer not using State in this particular instance |
| 2024-11-18 18:24:59 +0100 | <geekosaur> | and yes, especially if it's going to be a large tree I'd `fromList` at the end |
| 2024-11-18 18:24:43 +0100 | Leonard26 | (~Leonard26@49.236.26.53) (Quit: Client closed) |
| 2024-11-18 18:24:40 +0100 | <geekosaur> | (but you'd need to inspect Core to find out) |
| 2024-11-18 18:24:09 +0100 | <zzz> | and then again maybe not. i guess IntMap.fromList can be more performant than IntMap.insert every step |
| 2024-11-18 18:24:04 +0100 | <geekosaur> | if ghc's doing its thing correctly, the state monad should get optimized down to the manual version |
| 2024-11-18 18:22:33 +0100 | Alleria | (~Alleria@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2024-11-18 18:22:30 +0100 | <zzz> | i guess i could create a new IntMap and update it each step instead of appending to a linked list and then using IntMap.fromList but other than that |