| 2026-03-10 00:03:13 +0100 | mangoiv | (~mangoiv@user/mangoiv) (Quit: The Lounge - https://thelounge.chat) |
| 2026-03-10 00:03:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-10 00:03:42 +0100 | Vajb | (~Vajb@n7m5g0hrctljxjtgjiv-1.v6.elisa-mobile.fi) (Remote host closed the connection) |
| 2026-03-10 00:03:52 +0100 | Vajb | (~Vajb@n7m5g0hrctljxjtgjiv-1.v6.elisa-mobile.fi) |
| 2026-03-10 00:04:36 +0100 | mangoiv | (~mangoiv@2a01:4f9:c012:6c0e::) |
| 2026-03-10 00:05:44 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-03-10 00:07:35 +0100 | mangoiv | (~mangoiv@2a01:4f9:c012:6c0e::) (Changing host) |
| 2026-03-10 00:07:35 +0100 | mangoiv | (~mangoiv@user/mangoiv) mangoiv |
| 2026-03-10 00:09:23 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-03-10 00:09:26 +0100 | emmanuelux | (~em@user/emmanuelux) (Read error: Connection reset by peer) |
| 2026-03-10 00:12:46 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-03-10 00:14:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 00:17:57 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Quit: Leaving...) |
| 2026-03-10 00:19:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 00:21:39 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2026-03-10 00:25:09 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3f2f:c15f:718f:76d4) (Quit: xff0x) |
| 2026-03-10 00:26:42 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 248 seconds) |
| 2026-03-10 00:27:20 +0100 | xff0x | (~xff0x@2405:6580:b080:900:2fb0:3523:ec48:69d) |
| 2026-03-10 00:31:24 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-10 00:31:34 +0100 | GdeVolpi1 | (~GdeVolpia@user/GdeVolpiano) (Ping timeout: 244 seconds) |
| 2026-03-10 00:33:29 +0100 | GdeVolpiano | (~GdeVolpia@user/GdeVolpiano) GdeVolpiano |
| 2026-03-10 00:36:07 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 276 seconds) |
| 2026-03-10 00:46:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 00:53:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-03-10 00:57:40 +0100 | xff0x | (~xff0x@2405:6580:b080:900:2fb0:3523:ec48:69d) (Ping timeout: 245 seconds) |
| 2026-03-10 00:58:32 +0100 | xff0x | (~xff0x@2405:6580:b080:900:90e4:21a8:dac4:88fd) |
| 2026-03-10 01:07:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 01:12:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-10 01:14:58 +0100 | traxex | (traxex@user/traxex) (Ping timeout: 244 seconds) |
| 2026-03-10 01:16:30 +0100 | skum | (~skum@user/skum) skum |
| 2026-03-10 01:18:23 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 272 seconds) |
| 2026-03-10 01:20:19 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-03-10 01:22:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 01:23:35 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-03-10 01:27:40 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-10 01:38:41 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 01:44:16 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-10 01:45:53 +0100 | xff0x | (~xff0x@2405:6580:b080:900:90e4:21a8:dac4:88fd) (Ping timeout: 252 seconds) |
| 2026-03-10 01:54:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 01:59:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-10 02:01:07 +0100 | mud | (~mud@user/kadoban) (Remote host closed the connection) |
| 2026-03-10 02:07:07 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 276 seconds) |
| 2026-03-10 02:10:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 02:17:48 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 02:20:36 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-10 02:21:27 +0100 | Tuplanolla | (~Tuplanoll@88-114-89-88.elisa-laajakaista.fi) (Ping timeout: 255 seconds) |
| 2026-03-10 02:23:30 +0100 | acidjnk | (~acidjnk@p200300d6e700e5883f4cc5b601caa082.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-03-10 02:25:29 +0100 | stackdroid18 | (~stackdroi@user/stackdroid) () |
| 2026-03-10 02:29:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 02:34:35 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-03-10 02:35:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-10 02:47:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 02:52:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-10 02:54:15 +0100 | Kamuela | (~kamuela@2601:18c:8203:d800:145:1034:2ba9:8fdf) (Quit: Textual IRC Client: www.textualapp.com) |
| 2026-03-10 02:57:55 +0100 | Goodbye_Vincent1 | (cyvahl@freakshells.net) (Ping timeout: 264 seconds) |
| 2026-03-10 03:02:57 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 03:04:16 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-03-10 03:08:12 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 03:08:33 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 03:12:40 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 245 seconds) |
| 2026-03-10 03:18:52 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-10 03:23:14 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 248 seconds) |
| 2026-03-10 03:34:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 03:39:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-03-10 03:50:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 03:55:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 03:55:40 +0100 | karenw | (~karenw@user/karenw) (Ping timeout: 276 seconds) |
| 2026-03-10 03:55:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 03:57:01 +0100 | xff0x_ | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2026-03-10 03:58:17 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 248 seconds) |
| 2026-03-10 04:00:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-10 04:02:54 +0100 | xff0x_ | xff0x |
| 2026-03-10 04:11:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 04:17:26 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 268 seconds) |
| 2026-03-10 04:18:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-10 04:18:40 +0100 | ar3ph | (~ar3ph@user/ar3ph) (Quit: bye) |
| 2026-03-10 04:19:23 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:95b4:8c24:55ef:64fa) |
| 2026-03-10 04:23:48 +0100 | skum | (~skum@user/skum) (Ping timeout: 246 seconds) |
| 2026-03-10 04:26:43 +0100 | czan | (~czan@user/mange) czan |
| 2026-03-10 04:27:41 +0100 | tromp | (~textual@2001:1c00:3487:1b00:e975:d7be:a717:768f) (Ping timeout: 268 seconds) |
| 2026-03-10 04:29:18 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 04:34:11 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-03-10 04:44:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 04:49:38 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-03-10 04:50:30 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 268 seconds) |
| 2026-03-10 04:55:28 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) (Ping timeout: 256 seconds) |
| 2026-03-10 04:56:17 +0100 | img | (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-03-10 04:57:31 +0100 | img | (~img@user/img) img |
| 2026-03-10 05:00:34 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 05:06:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-10 05:16:21 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 05:21:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 05:31:50 +0100 | mud | (~mud@user/kadoban) kadoban |
| 2026-03-10 05:32:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 05:33:24 +0100 | Goodbye_Vincent1 | (cyvahl@freakshells.net) Goodbye_Vincent |
| 2026-03-10 05:37:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 05:39:44 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 05:40:05 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 05:41:29 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:95b4:8c24:55ef:64fa) (Remote host closed the connection) |
| 2026-03-10 05:47:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 05:48:42 +0100 | czan | (~czan@user/mange) (Ping timeout: 268 seconds) |
| 2026-03-10 05:54:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2026-03-10 05:56:44 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 05:56:54 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 05:57:03 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 05:59:59 +0100 | qqq | (~qqq@185.54.21.187) |
| 2026-03-10 06:01:06 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-10 06:03:55 +0100 | Pozyomka | (~pyon@user/pyon) (Ping timeout: 245 seconds) |
| 2026-03-10 06:11:15 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 06:11:29 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 06:12:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 06:17:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-03-10 06:19:23 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-10 06:23:57 +0100 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2026-03-10 06:24:44 +0100 | qqq | (~qqq@185.54.21.187) (Ping timeout: 252 seconds) |
| 2026-03-10 06:26:43 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2026-03-10 06:28:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 06:28:56 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-10 06:32:03 +0100 | qqq | (~qqq@185.54.21.187) |
| 2026-03-10 06:32:56 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2026-03-10 06:33:03 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-10 06:40:03 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-10 06:42:12 +0100 | divlamir | (~divlamir@user/divlamir) (Read error: Connection reset by peer) |
| 2026-03-10 06:42:24 +0100 | divlamir | (~divlamir@user/divlamir) divlamir |
| 2026-03-10 06:44:44 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-03-10 06:49:12 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 255 seconds) |
| 2026-03-10 06:49:23 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-10 06:55:46 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-10 06:57:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 07:03:19 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 07:06:15 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-03-10 07:07:48 +0100 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 2026-03-10 07:08:21 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-10 07:09:47 +0100 | emmanuelux | (~em@user/emmanuelux) emmanuelux |
| 2026-03-10 07:10:51 +0100 | skum | (~skum@user/skum) skum |
| 2026-03-10 07:13:41 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 07:18:05 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-03-10 07:26:43 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 264 seconds) |
| 2026-03-10 07:28:53 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 272 seconds) |
| 2026-03-10 07:29:03 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 07:36:23 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2026-03-10 07:40:36 +0100 | skum | (~skum@user/skum) (Ping timeout: 264 seconds) |
| 2026-03-10 07:44:57 +0100 | skum | (~skum@user/skum) skum |
| 2026-03-10 07:47:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 07:51:50 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-10 07:58:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 08:03:45 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-10 08:14:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 08:14:59 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2026-03-10 08:19:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 08:29:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 08:31:30 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-10 08:35:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-03-10 08:45:24 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 08:46:15 +0100 | Axman6 | (~Axman6@user/axman6) Axman6 |
| 2026-03-10 08:50:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-10 08:59:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-10 09:05:51 +0100 | srazkvt | (~sarah@user/srazkvt) srazkvt |
| 2026-03-10 09:07:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-10 09:09:21 +0100 | fp1 | (~Thunderbi@2001:708:20:1406::10c5) fp |
| 2026-03-10 09:10:09 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2026-03-10 09:31:04 +0100 | chele | (~chele@user/chele) chele |
| 2026-03-10 09:38:21 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2026-03-10 09:43:51 +0100 | emmanuelux | (~em@user/emmanuelux) (Quit: bye) |
| 2026-03-10 09:44:37 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-10 09:47:30 +0100 | oskarw | (~user@user/oskarw) oskarw |
| 2026-03-10 09:50:30 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-03-10 09:52:58 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-10 09:56:26 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2026-03-10 09:58:59 +0100 | acidjnk | (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) acidjnk |
| 2026-03-10 10:16:40 +0100 | olivial | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2026-03-10 10:16:56 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2026-03-10 10:18:56 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-03-10 10:21:30 +0100 | chele | (~chele@user/chele) chele |
| 2026-03-10 10:29:53 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) |
| 2026-03-10 10:29:53 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) (Changing host) |
| 2026-03-10 10:29:53 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 10:31:23 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 10:35:27 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-10 10:39:33 +0100 | <Freakie> | hi, I was here a few days ago with questions about profiling my program involving BDD algorithms (in case anyone was there and remember) |
| 2026-03-10 10:41:31 +0100 | <Freakie> | over half my runtime is still spent on garbage collecting and further profiling suggests that something like 90% of all of my allocations are spent on updating a priority queue (a lot of elements are inserted). I'm not sure I can do much to help my situation but if anyone could lend some insight again I'd be grateful |
| 2026-03-10 10:41:59 +0100 | danza | (~danza@user/danza) (Ping timeout: 245 seconds) |
| 2026-03-10 10:45:31 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-10 10:50:52 +0100 | <probie> | How is the priority queue implemented? |
| 2026-03-10 10:51:50 +0100 | <Freakie> | I've used a typeclass as an abstraction over different implementations |
| 2026-03-10 10:52:09 +0100 | <Freakie> | mostly I've just used Data.Set, but I've also played around with MultiSet and the MinQueue from pqueue |
| 2026-03-10 10:52:43 +0100 | <Freakie> | they both seem to have the same allocation rate from what I've been able to gather from experimentation |
| 2026-03-10 10:54:40 +0100 | <Freakie> | my fear is that the priority queues just have to handle too much data but on the input sizes I need to handle to the point that rebalancing is infeasible |
| 2026-03-10 10:56:19 +0100 | <probie> | Inserting an element is always going to cause an allocation (or more). You can't really avoid that without mutation (or linearity) |
| 2026-03-10 10:58:01 +0100 | <Freakie> | the space cost just seems absurdly high still |
| 2026-03-10 10:58:33 +0100 | <Freakie> | I was considering maybe restructuring my program to reuse the priority queue between different stages of the application so the pointer is kept alive throghout |
| 2026-03-10 10:58:42 +0100 | <Freakie> | but i'm not sure if that's the right track |
| 2026-03-10 10:59:38 +0100 | <Freakie> | otherwise I should be able to take advantage of my data structure to offload a lot of the work to using lists which should prevent a lot of rebalancing (and therefore allocations) |
| 2026-03-10 11:00:28 +0100 | <Freakie> | for me the issue is just having been told multiple times that spending >50% of the runtime on GC suggests that something is wrong with the program ,so I was hoping to have some better way of evaluating that statement |
| 2026-03-10 11:02:26 +0100 | tromp | (~textual@2001:1c00:3487:1b00:5cb9:87bb:7dcb:d170) |
| 2026-03-10 11:06:33 +0100 | fp1 | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 248 seconds) |
| 2026-03-10 11:08:01 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 272 seconds) |
| 2026-03-10 11:11:08 +0100 | dhil | (~dhil@5.151.29.141) dhil |
| 2026-03-10 11:16:16 +0100 | <probie> | Without actually seeing the code, all anyone here can do is guess. If the situation allows it, try a priority queue backed by some kind of mutable STVector, since you'll be able to enqueue/dequeue without allocations (beyond the occasional allocation to resize the backing vector) |
| 2026-03-10 11:16:53 +0100 | tromp | (~textual@2001:1c00:3487:1b00:5cb9:87bb:7dcb:d170) (Ping timeout: 272 seconds) |
| 2026-03-10 11:19:43 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 11:21:58 +0100 | <Freakie> | unfortunately purity is pretty essential to what i'm trying to do, which is also why I'm having a difficult time brainstorming alternatives |
| 2026-03-10 11:22:00 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-03-10 11:24:30 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2026-03-10 11:27:11 +0100 | danz32096 | (~danza@user/danza) danza |
| 2026-03-10 11:29:06 +0100 | danza | (~danza@user/danza) (Ping timeout: 248 seconds) |
| 2026-03-10 11:33:24 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2026-03-10 11:39:02 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 11:39:21 +0100 | <jreicher> | Freakie: Just in case it helps, may I question why the garbage collection is "undesirable"? That might sound stupid, but what reason do you have to think it's not needed for your use case? |
| 2026-03-10 11:39:24 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 11:39:41 +0100 | <jreicher> | Some things just have to be GCed; that's the nature of them. (Not the implementation, but the algorithm itself) |
| 2026-03-10 11:40:30 +0100 | <probie> | Freakie: does performance improve if you make the nursery bigger? (e.g. try something like `+RTS -A64m -RTS`) |
| 2026-03-10 11:48:46 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 11:52:22 +0100 | acidjnk_new | (~acidjnk@p200300d6e700e547f0589d3e513577e0.dip0.t-ipconnect.de) acidjnk |
| 2026-03-10 11:55:31 +0100 | acidjnk | (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2026-03-10 11:56:58 +0100 | <Freakie> | I've thought about nursery size before but never got around to it, I guess I'll give it a try in not too long |
| 2026-03-10 11:57:33 +0100 | <Freakie> | jreicher it's "undesirable" in the sense that up to 3/4 of the actual runtime is spent not doing work but just garbage collection |
| 2026-03-10 11:58:30 +0100 | <Freakie> | obviously garbage collection is unavoidable but if the runtime explodes for reasons not directly related to the work itself (i.e., not following the asymptotics) then it should be fixed |
| 2026-03-10 12:00:20 +0100 | <Freakie> | what confuses me a little is that the algorithm has two parts that are supposed to be roughly equal in work intensity but according to my profiles (at least the eventlog2html renders of them), only one of the algorithms are truly "busy" in terms of allocations |
| 2026-03-10 12:00:28 +0100 | <Freakie> | and I'm not sure how exactly to troubleshoot that |
| 2026-03-10 12:03:43 +0100 | xff0x | (~xff0x@2405:6580:b080:900:cfba:7074:7dbc:e7e9) |
| 2026-03-10 12:10:43 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 12:11:08 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 12:20:08 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 12:20:42 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 12:21:42 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Quit: CiaoSen) |
| 2026-03-10 12:23:44 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-03-10 12:26:40 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-10 12:29:40 +0100 | tristanC | (~tristanC@user/tristanc) tristanC |
| 2026-03-10 12:35:20 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 12:35:34 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 12:37:57 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 272 seconds) |
| 2026-03-10 12:39:45 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 12:40:09 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 12:42:32 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 12:45:19 +0100 | danz32096 | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-10 12:51:04 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2026-03-10 12:55:16 +0100 | <comerijn> | Freakie: How big is your queue? |
| 2026-03-10 12:56:44 +0100 | <comerijn> | because there's a well known blogpost from ages ago of a company struggle with Haskell GC also for a queue and part of their problem (and, I suspect, yours) was that their inherent problem involved a large liveset |
| 2026-03-10 12:56:56 +0100 | <comerijn> | And large live sets are a worst case for GHCs GC approach |
| 2026-03-10 12:57:09 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 12:59:44 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-10 13:01:04 +0100 | <c_wraith> | Huh. I never really thought about making each entry in a container its own compact region, but there are cases where that could really reduce GC pressure. (like if there aren't all that many entries, but they have a lot of internal pointers) |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 13:03:37 +0100 | <Freakie> | I've been considering doing that as well but it's a larger process |
| 2026-03-10 13:03:50 +0100 | <Freakie> | (assuming you're responding to my previous comments) |
| 2026-03-10 13:14:57 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-03-10 13:17:29 +0100 | <comerijn> | Freakie: Did you see my comments? |
| 2026-03-10 13:17:35 +0100 | <comerijn> | Freakie: Also, how big is your live set? |
| 2026-03-10 13:18:55 +0100 | <comerijn> | Freakie: Also you mentioned avoiding allocations, but those are incredibly cheap so that's almost never worth it |
| 2026-03-10 13:19:28 +0100 | <Freakie> | comerijn: sorry no, I had to change locations so I haven't seen anything for the past hour |
| 2026-03-10 13:20:11 +0100 | <Freakie> | by live set do you mean maximum residency or total memory in use as per reported by +RTS -s or do you mean the number of objects that are live at a time? |
| 2026-03-10 13:20:21 +0100 | <comerijn> | Freakie: Max residency |
| 2026-03-10 13:20:31 +0100 | <comerijn> | Freakie: And I asked how big your queue was |
| 2026-03-10 13:21:00 +0100 | <comerijn> | Freakie: Note that (unlike what you may be used to from most GC languages) GHC's GC scales in live data, not garbage |
| 2026-03-10 13:21:17 +0100 | <comerijn> | Freakie: Therefore big live sets will increase your GC times quite a bit |
| 2026-03-10 13:21:41 +0100 | <Freakie> | I assume that's linked to pointers being acylic |
| 2026-03-10 13:21:43 +0100 | <comerijn> | And my other previous comment: there's a well known blogpost from ages ago of a company struggle with Haskell GC also for a queue and part of their problem (and, I suspect, yours) was that their inherent problem involved a large liveset |
| 2026-03-10 13:22:25 +0100 | <Freakie> | I don't have any metrics on the queue size but it's likely to be quite large in general because of the problem itself I'm benchmarking (encoding a boolean formula for n-queens) |
| 2026-03-10 13:22:35 +0100 | <Freakie> | doublechecking residency |
| 2026-03-10 13:22:40 +0100 | <comerijn> | Freakie: That and the fact that laziness does lots of short-lived allocations, so the GC is tuned for fast allocation and short-lived data |
| 2026-03-10 13:22:59 +0100 | <Leary> | Freakie: In future, check the logs; they're linked in the topic. |
| 2026-03-10 13:23:09 +0100 | <Freakie> | can you link the post again? |
| 2026-03-10 13:23:18 +0100 | <comerijn> | I'll have to see if I can find it |
| 2026-03-10 13:23:49 +0100 | <comerijn> | Freakie: What c_wraith mentioned might help (compact regions) those let you treat large chunks of life data as a single pointer, which will speed up GC considerably |
| 2026-03-10 13:24:09 +0100 | <Freakie> | I already had compactness in mind but the one time I tried doing it it, it seemed to have no effect |
| 2026-03-10 13:24:10 +0100 | <comerijn> | Freakie: GHC does a copy&collect (so all live data is copied into a new heap, then we just wipe the old heap) |
| 2026-03-10 13:24:13 +0100 | <Freakie> | I've done lots of small optimizations since |
| 2026-03-10 13:24:29 +0100 | <comerijn> | Freakie: The problem is that if you have 4GB residency then you're copying 4GB each GC |
| 2026-03-10 13:24:46 +0100 | <Freakie> | right now my workaround (for memory) is using concurrent GC which slightly increases runtime but significantly helps with memory consumption |
| 2026-03-10 13:24:52 +0100 | <comerijn> | Freakie: Compact regions let you dump 4GB into a single compact region and then skip copying it while it's live) |
| 2026-03-10 13:25:06 +0100 | <comerijn> | Freakie: Oh, also where you giving any specific GC flags? |
| 2026-03-10 13:25:29 +0100 | <Freakie> | for n = 7 max residency is at about 40 mb while for n = 8 it jumpts to 920 mb |
| 2026-03-10 13:25:33 +0100 | <Freakie> | in my benchmark |
| 2026-03-10 13:26:05 +0100 | <Freakie> | i've played around with concurrency (--nonmoving-gc) and --nonmoving-dense-allocator-count |
| 2026-03-10 13:26:18 +0100 | <Freakie> | nursery sizes seemed to have little effect as well |
| 2026-03-10 13:26:42 +0100 | <comerijn> | Freakie: Are you running threaded runtime and large number of capabilities? |
| 2026-03-10 13:26:56 +0100 | <Freakie> | no, I thought that would be too difficult to reason |
| 2026-03-10 13:26:57 +0100 | <comerijn> | Freakie: nonmoving-gc will generally have lower throughput |
| 2026-03-10 13:27:05 +0100 | <comerijn> | Freakie: then the regular one |
| 2026-03-10 13:27:29 +0100 | <comerijn> | The main downside of the moving GC is that it causes longer GC pauses (bad for latency sensitive/real-time applications) |
| 2026-03-10 13:27:47 +0100 | <Freakie> | nonmoving-gc roughly halved residency and total memory in use for the largest input size I've tested |
| 2026-03-10 13:27:47 +0100 | <comerijn> | But in terms of productivity the default GC is better |
| 2026-03-10 13:28:10 +0100 | <Freakie> | I mean yeah productivity suffered *technically* but the runtime was about the same |
| 2026-03-10 13:28:28 +0100 | <Freakie> | it's an acceptable time loss compared to being able to actually scale the problem (if it doesn't get worse for even greater input sizes anyway) |
| 2026-03-10 13:28:31 +0100 | <comerijn> | Freakie: Try the default GC with the -qg runtime option? |
| 2026-03-10 13:28:53 +0100 | <comerijn> | Might wanna try tweaking the number of generations too? |
| 2026-03-10 13:28:58 +0100 | <Freakie> | it didn't seem to have much of an impact when I tried but I could try again |
| 2026-03-10 13:29:00 +0100 | <Freakie> | for both of those |
| 2026-03-10 13:29:03 +0100 | <comerijn> | hmm |
| 2026-03-10 13:29:33 +0100 | <Freakie> | I'm planning on restructuring the code so that it can take use of the layout of the lists I'm working with |
| 2026-03-10 13:29:34 +0100 | <comerijn> | Freakie: this blog https://www.channable.com/tech/lessons-in-managing-haskell-memory |
| 2026-03-10 13:30:12 +0100 | <Freakie> | which shouldn't help asymptotically but should reduce the dependency on hte priority queue |
| 2026-03-10 13:30:44 +0100 | <comerijn> | What are you putting in the queue? |
| 2026-03-10 13:30:47 +0100 | <Freakie> | I'm a little unsure how compact regions might help since other than what I just mentioned I don't think there are a lot of options to separate the regions during the iterations of the algorithm itself |
| 2026-03-10 13:31:03 +0100 | <Freakie> | are you familiar with binary decision diagrams? just for the sake of terminology |
| 2026-03-10 13:31:20 +0100 | <comerijn> | Yeah |
| 2026-03-10 13:32:08 +0100 | <Freakie> | yeah so I have a list representation of the BDD nodes that I need to either work on top down or bottom up; in either case I need to get as much information as possible from the input lists before proceeding to the tail |
| 2026-03-10 13:32:35 +0100 | <comerijn> | Freakie: The point of regions is that you have, say 500 MB of data that is live for your entire algorithm then you reduce the GC cost of that data from "copy 500 MB" to "copy a pointer to the compact region" |
| 2026-03-10 13:32:44 +0100 | <Freakie> | so the priority queue gives the most relevant information based on where in the list I am |
| 2026-03-10 13:33:16 +0100 | <comerijn> | Freakie: So you're incrementally building the representation of a BDD? |
| 2026-03-10 13:33:35 +0100 | <Freakie> | yes and no? depends on the algorithm |
| 2026-03-10 13:33:57 +0100 | <Freakie> | the apply algorithm takes two bdds (lists) and outputs lists of arcs that make up an unreduced bdd |
| 2026-03-10 13:34:10 +0100 | <Freakie> | a separate algorithm then builds up the BDD again |
| 2026-03-10 13:34:19 +0100 | <Freakie> | other times it's just traversal for e.g. satcount |
| 2026-03-10 13:35:17 +0100 | <Freakie> | the point of the priority queue is to extract all relevant data from a particular node before progressing past it, but there's no neat structure in terms of compactness |
| 2026-03-10 13:35:31 +0100 | <Freakie> | because the children can be anywhere on a deeper level |
| 2026-03-10 13:35:31 +0100 | <comerijn> | Freakie: Where compact regions help is if you have a large BDD that you keep around indefinitely, by shoving it off into a compact region it basically no longer counts as live data for the GC scaling |
| 2026-03-10 13:36:00 +0100 | <Freakie> | so basically you mean pinning the BDDs while traversing them? |
| 2026-03-10 13:36:52 +0100 | <Freakie> | I think it wouldn't help much though because almost all of the allocations in my program comes manipulating the priority queue (regardless of the implementation) |
| 2026-03-10 13:36:56 +0100 | <comerijn> | Freakie: Ok, so you have some tree data structure scattered across your heap, right? Every GC you copy that entire thing to a new heap, then wipe the old. If that tree is huge and you keep it around a long time, that's a lot of continual copying |
| 2026-03-10 13:38:04 +0100 | <comerijn> | Freakie: When you create a compact region the GC copies a (transitive) data structure from the heap to a separate region, and then during GC we either free the entire region at once or only copy the pointer to the region to the new heap. Reducing GC cost from however large the data to 1 pointer |
| 2026-03-10 13:38:09 +0100 | <Freakie> | the thing is just that the BDDs themselves are not that large relative to the data allocated during the algorithms |
| 2026-03-10 13:38:36 +0100 | <comerijn> | ok, so that's probably not where your cost is |
| 2026-03-10 13:38:46 +0100 | <Freakie> | for n = 8 the largest BDD generated only has like 10k nodes while the number of insertions to the PQ can hit double digits |
| 2026-03-10 13:38:51 +0100 | <comerijn> | Freakie: The same applies for any of the data during the algorithms :) |
| 2026-03-10 13:39:12 +0100 | <Freakie> | yeah I jjust mean to say that the extra cost of traversing the input lists shouldn't be the deciding factor |
| 2026-03-10 13:39:26 +0100 | <Freakie> | I can utilize the levelwise layout of the lists though |
| 2026-03-10 13:39:31 +0100 | <comerijn> | Depends how often you trigger GC ;) |
| 2026-03-10 13:40:06 +0100 | <comerijn> | Freakie: I mean, you don't have to limit yourself to compact individual BDD. You can compact essentially any arbitrary tree of data |
| 2026-03-10 13:40:31 +0100 | <comerijn> | Including (parts) of your priority queue |
| 2026-03-10 13:40:33 +0100 | <Freakie> | I know, I'm just not working with many other data structures than the BDDs themselves (which are represented by lists, and only traversed during algorithms) and the priroity queue |
| 2026-03-10 13:41:02 +0100 | <Freakie> | maybe a compact PQ could help but then I suppose the region will just keep growing till the algorithm is done? |
| 2026-03-10 13:42:24 +0100 | <Freakie> | otherwise I was planning on using the levelwise layout of the BDD to separate the closest data (for example what needs to be processed on the current and next level) from the priority queue itself |
| 2026-03-10 13:42:51 +0100 | <Freakie> | and then sorting them lazily (i.e. when you actually need to traverse said level) |
| 2026-03-10 13:43:16 +0100 | <Freakie> | do you know if the compact regions are deep copied? |
| 2026-03-10 13:43:25 +0100 | <Freakie> | (it's desired in what I'm trying to do) |
| 2026-03-10 13:44:09 +0100 | <comerijn> | Freakie: deep copying question makes no sense |
| 2026-03-10 13:44:13 +0100 | <comerijn> | Data is immutable |
| 2026-03-10 13:44:31 +0100 | <comerijn> | A compact region is not mutable |
| 2026-03-10 13:44:45 +0100 | <Freakie> | yes but sharing is a problem in theory for what the algorithms need to do |
| 2026-03-10 13:45:12 +0100 | <Freakie> | it seems counterintuitive but it's a pretty essential part (at least if the algorithms actually manage to scale to the problem sizes they want toa ddress) |
| 2026-03-10 13:45:16 +0100 | <comerijn> | sharing or not sharing is not obsevable |
| 2026-03-10 13:45:48 +0100 | <comerijn> | Freakie: In an immutable setting, how do you think you could possibly observe whether something is shared? |
| 2026-03-10 13:45:53 +0100 | <Freakie> | I'm trying to work with I/O efficient algorithms and sharing can imply page faults |
| 2026-03-10 13:46:05 +0100 | <Freakie> | it's nothing to do with referential transparency and everything to do with data locality |
| 2026-03-10 13:46:12 +0100 | m1dnight_ | (~m1dnight@141.134.26.23) (Ping timeout: 244 seconds) |
| 2026-03-10 13:46:27 +0100 | <comerijn> | At the point why not take an entirely different approach |
| 2026-03-10 13:46:30 +0100 | <comerijn> | *that |
| 2026-03-10 13:46:39 +0100 | <Freakie> | well technically it would only matter once data needs to be pushed to the disk |
| 2026-03-10 13:46:55 +0100 | <comerijn> | Why not give your data a Storable instance and just allocate blocks of memory explicitly |
| 2026-03-10 13:47:54 +0100 | <Freakie> | it would problem be something like that if I get that far |
| 2026-03-10 13:48:36 +0100 | <Freakie> | the point is more that the whole model of computation i'm working with only counts I/O operations as costful, hence *in theory* pointer sharing is problematic |
| 2026-03-10 13:48:56 +0100 | <Freakie> | the same problem can be moved to cache level |
| 2026-03-10 13:49:17 +0100 | <Freakie> | at which point in-memory sharing is also problematic |
| 2026-03-10 13:50:08 +0100 | <Freakie> | I hope it doesn't sound like I'm being difficult, I'm just working with a lot of constraints (albeit intentioanlly) |
| 2026-03-10 14:02:37 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 14:07:24 +0100 | jreicher | (~joelr@user/jreicher) (Ping timeout: 256 seconds) |
| 2026-03-10 14:07:38 +0100 | nschoe- | (~nschoe@2a01:e0a:8e:a190:bcc4:c62f:8a83:eae8) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2026-03-10 14:07:55 +0100 | nschoe | (~nschoe@82-65-202-30.subs.proxad.net) nschoe |
| 2026-03-10 14:17:19 +0100 | adamCS | (~adamCS@70.19.85.77) (Remote host closed the connection) |
| 2026-03-10 14:18:33 +0100 | gabiruh | (~gabiruh@191.252.222.55) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2026-03-10 14:20:54 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2026-03-10 14:25:49 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-03-10 14:26:17 +0100 | Fijxu | (~Fijxu@user/fijxu) (Read error: Connection reset by peer) |
| 2026-03-10 14:26:23 +0100 | adamCS | (~adamCS@70.19.85.77) adamCS |
| 2026-03-10 14:26:29 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 14:27:44 +0100 | Fijxu_ | (~Fijxu@user/fijxu) fijxu |
| 2026-03-10 14:30:10 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 245 seconds) |
| 2026-03-10 14:36:22 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-03-10 14:44:10 +0100 | Square2 | (~Square4@user/square) Square |
| 2026-03-10 14:55:36 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 264 seconds) |
| 2026-03-10 14:56:38 +0100 | gawen | (~gawen@user/gawen) (Quit: cya) |
| 2026-03-10 14:57:25 +0100 | gawen | (~gawen@user/gawen) gawen |
| 2026-03-10 15:03:57 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 246 seconds) |
| 2026-03-10 15:06:08 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Ping timeout: 252 seconds) |
| 2026-03-10 15:08:03 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 15:08:03 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 15:08:03 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 15:11:37 +0100 | srazkvt | (~sarah@user/srazkvt) (Quit: Konversation terminated!) |
| 2026-03-10 15:11:43 +0100 | st_aldini | (~Betterbir@136.48.46.187) st_aldini |
| 2026-03-10 15:12:57 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-10 15:25:16 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 15:25:16 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 15:25:16 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 15:41:25 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 15:48:41 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 15:53:39 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 272 seconds) |
| 2026-03-10 16:04:57 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 16:08:33 +0100 | machinedgod | (~machinedg@d172-219-48-230.abhsia.telus.net) machinedgod |
| 2026-03-10 16:10:18 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-10 16:19:08 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-03-10 16:22:19 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 16:22:19 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 16:22:19 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 16:24:22 +0100 | pabs3 | (~pabs3@user/pabs3) (Read error: Connection reset by peer) |
| 2026-03-10 16:24:56 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2026-03-10 16:28:21 +0100 | FANTOM_ | (~fantom@90.251.214.54) (Ping timeout: 265 seconds) |
| 2026-03-10 16:28:22 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 276 seconds) |
| 2026-03-10 16:30:17 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 265 seconds) |
| 2026-03-10 16:35:31 +0100 | FANTOM | (~fantom@90.251.214.54) |
| 2026-03-10 16:37:00 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 16:38:38 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-10 16:41:45 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2026-03-10 16:45:47 +0100 | qqq | (~qqq@185.54.21.187) (Remote host closed the connection) |
| 2026-03-10 16:51:25 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 16:51:25 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 16:51:25 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 16:57:25 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 17:04:19 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) m1dnight |
| 2026-03-10 17:06:54 +0100 | omnifunctor | (~omnifunct@user/semifunctor) (Remote host closed the connection) |
| 2026-03-10 17:09:02 +0100 | pounce | (8a023a9e4a@user/cute/pounce) pounce |
| 2026-03-10 17:14:10 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-10 17:14:35 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 17:15:27 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 17:18:41 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 252 seconds) |
| 2026-03-10 17:20:31 +0100 | mtorpey | (~mtorpey@pc29565.cs.st-andrews.ac.uk) |
| 2026-03-10 17:21:44 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Quit: Later) |
| 2026-03-10 17:22:30 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) |
| 2026-03-10 17:23:37 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Client Quit) |
| 2026-03-10 17:24:05 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) rncwnd |
| 2026-03-10 17:26:28 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Client Quit) |
| 2026-03-10 17:26:57 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) |
| 2026-03-10 17:27:21 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-10 17:28:10 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Client Quit) |
| 2026-03-10 17:28:41 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) rncwnd |
| 2026-03-10 17:30:00 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) (Ping timeout: 255 seconds) |
| 2026-03-10 17:31:15 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-10 17:32:20 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Client Quit) |
| 2026-03-10 17:32:50 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) |
| 2026-03-10 17:37:35 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) (Client Quit) |
| 2026-03-10 17:37:54 +0100 | rncwnd | (~quassel@2a01:4f8:221:27c6::1) rncwnd |
| 2026-03-10 17:40:30 +0100 | Digitteknohippie | (~user@user/digit) Digit |
| 2026-03-10 17:40:36 +0100 | Digit | (~user@user/digit) (Ping timeout: 264 seconds) |
| 2026-03-10 17:47:06 +0100 | Digitteknohippie | (~user@user/digit) (Ping timeout: 255 seconds) |
| 2026-03-10 17:49:27 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49ae:b06e:43ec:7652) |
| 2026-03-10 17:49:27 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:49ae:b06e:43ec:7652) (Changing host) |
| 2026-03-10 17:49:27 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 17:50:06 +0100 | peterbecich | (~Thunderbi@71.84.33.135) peterbecich |
| 2026-03-10 17:50:11 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 272 seconds) |
| 2026-03-10 17:53:28 +0100 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-10 18:02:08 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2026-03-10 18:09:02 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2026-03-10 18:22:38 +0100 | mtorpey | (~mtorpey@pc29565.cs.st-andrews.ac.uk) () |
| 2026-03-10 18:23:07 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2026-03-10 18:28:18 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 248 seconds) |
| 2026-03-10 18:28:25 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) (Read error: Connection reset by peer) |
| 2026-03-10 18:28:57 +0100 | jreicher | (~joelr@user/jreicher) jreicher |
| 2026-03-10 18:32:34 +0100 | pointlessslippe1 | (~pointless@62.106.85.17) pointlessslippe1 |
| 2026-03-10 18:35:37 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 248 seconds) |
| 2026-03-10 18:36:33 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 18:37:00 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 18:45:05 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2026-03-10 18:47:23 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-10 18:58:41 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-10 19:03:19 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 264 seconds) |
| 2026-03-10 19:05:15 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2026-03-10 19:06:03 +0100 | euphores | (~SASL_euph@user/euphores) euphores |
| 2026-03-10 19:07:15 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) ChaiTRex |
| 2026-03-10 19:17:24 +0100 | dhil | (~dhil@5.151.29.141) (Ping timeout: 245 seconds) |
| 2026-03-10 19:18:53 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-03-10 19:19:51 +0100 | kaskal | (~kaskal@2a02:8388:1a8b:7d00:6457:882b:213f:f9cd) (Quit: ZNC - https://znc.in) |
| 2026-03-10 19:20:09 +0100 | kaskal | (~kaskal@84-115-235-223.cable.dynamic.surfer.at) kaskal |
| 2026-03-10 19:22:43 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) m1dnight |
| 2026-03-10 19:30:53 +0100 | prdak | (~Thunderbi@user/prdak) prdak |
| 2026-03-10 19:31:20 +0100 | somemathguy | (~somemathg@user/somemathguy) (Ping timeout: 268 seconds) |
| 2026-03-10 19:32:39 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Quit: CiaoSen) |
| 2026-03-10 19:32:51 +0100 | somemathguy | (~somemathg@user/somemathguy) somemathguy |
| 2026-03-10 19:35:30 +0100 | prdak | (~Thunderbi@user/prdak) (Ping timeout: 256 seconds) |
| 2026-03-10 19:45:10 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 245 seconds) |
| 2026-03-10 19:46:28 +0100 | roconnor | (~quassel@rocq/roconnor) roconnor |
| 2026-03-10 19:51:19 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |