| 2024-06-02 00:01:07 +0200 | andrewboltachev | (~andrey@178.141.226.53) (Quit: Leaving.) |
| 2024-06-02 00:01:15 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-06-02 00:12:31 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-02 00:12:31 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 246 seconds) |
| 2024-06-02 00:14:35 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-06-02 00:15:29 +0200 | fliife | tjbc |
| 2024-06-02 00:15:53 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-06-02 00:15:58 +0200 | tjbc | fliife |
| 2024-06-02 00:17:33 +0200 | fliife | (~fliife@user/fliife) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-02 00:17:43 +0200 | fliife | (~fliife@user/fliife) |
| 2024-06-02 00:18:49 +0200 | fliife | tjbc |
| 2024-06-02 00:19:21 +0200 | tjbc | (~fliife@user/fliife) (Remote host closed the connection) |
| 2024-06-02 00:19:50 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Read error: Connection reset by peer) |
| 2024-06-02 00:20:01 +0200 | fliife | (~fliife@user/fliife) |
| 2024-06-02 00:21:48 +0200 | fliife | tjbc |
| 2024-06-02 00:22:06 +0200 | tjbc | fliife |
| 2024-06-02 00:23:04 +0200 | fliife | (~fliife@user/fliife) (Client Quit) |
| 2024-06-02 00:23:14 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-06-02 00:24:14 +0200 | fliife | (~fliife@user/fliife) |
| 2024-06-02 00:28:16 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds) |
| 2024-06-02 00:29:24 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-06-02 00:34:36 +0200 | ACuriousMoose | (~ACuriousM@142.68.181.38) (Ping timeout: 260 seconds) |
| 2024-06-02 00:39:26 +0200 | fliife | (~fliife@user/fliife) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-02 00:40:06 +0200 | tjbc | (~tjbc@user/fliife) |
| 2024-06-02 00:46:07 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 246 seconds) |
| 2024-06-02 00:55:30 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-06-02 00:57:11 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-06-02 01:18:35 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 268 seconds) |
| 2024-06-02 01:20:44 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 268 seconds) |
| 2024-06-02 01:27:47 +0200 | nain | (~nain@169.150.196.154) (Quit: Konversation terminated!) |
| 2024-06-02 01:29:17 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-06-02 01:35:14 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-06-02 01:35:58 +0200 | kimiamania | (~76637481@user/kimiamania) (Quit: PegeLinux) |
| 2024-06-02 01:36:18 +0200 | kimiamania | (~76637481@user/kimiamania) |
| 2024-06-02 01:44:00 +0200 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2024-06-02 01:47:34 +0200 | acidjnk | (~acidjnk@p200300d6e714dc29c5d26c84eddccd81.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2024-06-02 01:54:41 +0200 | kimiamania | (~76637481@user/kimiamania) (Quit: PegeLinux) |
| 2024-06-02 01:57:30 +0200 | kimiamania | (~65804703@user/kimiamania) |
| 2024-06-02 02:07:44 +0200 | pavonia | (~user@user/siracusa) |
| 2024-06-02 02:18:22 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Remote host closed the connection) |
| 2024-06-02 02:19:20 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-06-02 02:19:20 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Read error: Connection reset by peer) |
| 2024-06-02 02:19:20 +0200 | califax | (~califax@user/califx) (Read error: Connection reset by peer) |
| 2024-06-02 02:19:20 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Read error: Connection reset by peer) |
| 2024-06-02 02:19:37 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-06-02 02:19:45 +0200 | califax | (~califax@user/califx) |
| 2024-06-02 02:20:02 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-06-02 02:20:23 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-06-02 02:23:43 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) |
| 2024-06-02 02:23:46 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 246 seconds) |
| 2024-06-02 02:24:18 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-06-02 02:47:28 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: Leaving) |
| 2024-06-02 03:22:28 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2024-06-02 03:24:23 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 268 seconds) |
| 2024-06-02 03:35:10 +0200 | troydm | (~troydm@user/troydm) (Ping timeout: 268 seconds) |
| 2024-06-02 03:50:54 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-06-02 03:59:40 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2024-06-02 04:05:04 +0200 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2024-06-02 04:05:35 +0200 | op_4 | (~tslil@user/op-4/x-9116473) |
| 2024-06-02 04:16:16 +0200 | son0p | (~ff@186.121.56.64) (Ping timeout: 260 seconds) |
| 2024-06-02 04:34:55 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-06-02 04:50:43 +0200 | td_ | (~td@i53870928.versanet.de) (Ping timeout: 268 seconds) |
| 2024-06-02 04:52:02 +0200 | td_ | (~td@i53870901.versanet.de) |
| 2024-06-02 05:04:09 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-06-02 05:08:36 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-06-02 05:12:18 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-06-02 05:17:14 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-06-02 05:20:39 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-06-02 05:27:40 +0200 | Rodney_ | (~Rodney@176.254.244.83) (Ping timeout: 260 seconds) |
| 2024-06-02 05:31:54 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-06-02 05:50:13 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds) |
| 2024-06-02 05:50:16 +0200 | Garbanzo | (~Garbanzo@2602:304:6eac:dc10:fbf2:b01f:1d47:7542) |
| 2024-06-02 05:55:09 +0200 | aforemny | (~aforemny@2001:9e8:6ce2:0:e082:74dd:a9a3:528e) (Ping timeout: 268 seconds) |
| 2024-06-02 05:55:24 +0200 | aforemny_ | (~aforemny@i59F516D1.versanet.de) |
| 2024-06-02 06:09:23 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-06-02 06:10:17 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-06-02 06:12:50 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 260 seconds) |
| 2024-06-02 06:13:49 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-06-02 06:16:21 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-06-02 06:24:56 +0200 | son0p | (~ff@167.0.161.21) |
| 2024-06-02 06:26:50 +0200 | lol__ | jcarpenter2 |
| 2024-06-02 06:38:39 +0200 | mulk | (~mulk@p5b112e4a.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2024-06-02 06:40:53 +0200 | mulk | (~mulk@p5b2dc1a2.dip0.t-ipconnect.de) |
| 2024-06-02 06:43:10 +0200 | andrei_n | (~andrei_n@2a02:a03f:c091:a800:fde8:6a4:b1d:60ec) |
| 2024-06-02 06:44:27 +0200 | andrei_n | (~andrei_n@2a02:a03f:c091:a800:fde8:6a4:b1d:60ec) (Client Quit) |
| 2024-06-02 07:04:59 +0200 | leah2 | (~leah@vuxu.org) (Ping timeout: 260 seconds) |
| 2024-06-02 07:08:51 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 268 seconds) |
| 2024-06-02 07:37:00 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-02 07:37:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2024-06-02 07:39:55 +0200 | xdminsy | (~xdminsy@117.147.70.212) (Quit: Konversation terminated!) |
| 2024-06-02 07:40:21 +0200 | xdminsy | (~xdminsy@117.147.70.212) |
| 2024-06-02 07:49:32 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-06-02 07:49:49 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-06-02 07:54:10 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-06-02 07:56:32 +0200 | wheatengineer | (~frederik@p200300f63f4e89007666e2f77a3735a1.dip0.t-ipconnect.de) |
| 2024-06-02 08:03:08 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-06-02 08:05:23 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.1.1) |
| 2024-06-02 08:12:11 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-02 08:21:51 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-02 08:21:55 +0200 | poscat | (~poscat@user/poscat) (Ping timeout: 268 seconds) |
| 2024-06-02 08:22:07 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-02 08:22:23 +0200 | poscat | (~poscat@user/poscat) |
| 2024-06-02 08:22:56 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-02 08:57:51 +0200 | wheatengineer-fa | (~frederik@193.32.248.193) |
| 2024-06-02 09:00:01 +0200 | tt1231097 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: The Lounge - https://thelounge.chat) |
| 2024-06-02 09:00:13 +0200 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) |
| 2024-06-02 09:00:19 +0200 | wheatengineer | (~frederik@p200300f63f4e89007666e2f77a3735a1.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2024-06-02 09:01:40 +0200 | wheatengineer | (~frederik@p200300f63f4e89007666e2f77a3735a1.dip0.t-ipconnect.de) |
| 2024-06-02 09:02:51 +0200 | tt1231097 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-06-02 09:03:28 +0200 | wheatengineer-fa | (~frederik@193.32.248.193) (Ping timeout: 246 seconds) |
| 2024-06-02 09:04:47 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 264 seconds) |
| 2024-06-02 09:05:09 +0200 | mei | (~mei@user/mei) |
| 2024-06-02 09:07:24 +0200 | andrewboltachev | (~andrey@178.141.226.53) |
| 2024-06-02 09:09:30 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Quit: WeeChat 4.2.2) |
| 2024-06-02 09:22:43 +0200 | wheatengineer | (~frederik@p200300f63f4e89007666e2f77a3735a1.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2024-06-02 09:28:19 +0200 | mei | (~mei@user/mei) (Ping timeout: 246 seconds) |
| 2024-06-02 09:29:22 +0200 | mei | (~mei@user/mei) |
| 2024-06-02 09:38:19 +0200 | cheater | (~Username@user/cheater) |
| 2024-06-02 09:43:54 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-06-02 09:46:39 +0200 | poscat0x04 | (~poscat@user/poscat) |
| 2024-06-02 09:46:43 +0200 | poscat | (~poscat@user/poscat) (Ping timeout: 268 seconds) |
| 2024-06-02 09:50:04 +0200 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-06-02 09:54:58 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-06-02 10:00:45 +0200 | acidjnk | (~acidjnk@p200300d6e714dc176c976a8b55dd22bd.dip0.t-ipconnect.de) |
| 2024-06-02 10:01:21 +0200 | leah2 | (~leah@vuxu.org) |
| 2024-06-02 10:09:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-06-02 10:26:36 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-06-02 10:33:45 +0200 | Garbanzo | (~Garbanzo@2602:304:6eac:dc10:fbf2:b01f:1d47:7542) (Remote host closed the connection) |
| 2024-06-02 10:42:15 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-02 10:43:16 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-06-02 10:44:27 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-02 10:46:24 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-06-02 10:47:25 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2024-06-02 10:55:33 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2024-06-02 11:17:22 +0200 | rosco | (~rosco@90.58.221.226) |
| 2024-06-02 11:22:30 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-06-02 11:23:43 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-06-02 11:26:01 +0200 | billchenchina | (~billchenc@103.152.35.21) |
| 2024-06-02 11:26:48 +0200 | andrewboltachev | (~andrey@178.141.226.53) (Quit: Leaving.) |
| 2024-06-02 11:29:05 +0200 | billchenchina | (~billchenc@103.152.35.21) (Client Quit) |
| 2024-06-02 11:38:59 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-06-02 11:54:34 +0200 | tremon | (~tremon@83.80.159.219) |
| 2024-06-02 11:59:21 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-06-02 12:03:35 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-06-02 12:10:43 +0200 | wheatengineer | (~frederik@p200300f63f4e89007666e2f77a3735a1.dip0.t-ipconnect.de) |
| 2024-06-02 12:23:26 +0200 | sefidel | (~sefidel@user/sefidel) (Remote host closed the connection) |
| 2024-06-02 12:24:24 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-06-02 12:25:53 +0200 | gastus | (~gastus@185.6.123.201) |
| 2024-06-02 12:26:32 +0200 | sefidel | (~sefidel@user/sefidel) |
| 2024-06-02 12:45:51 +0200 | TonyStone | (~TonyStone@user/TonyStone) (Ping timeout: 268 seconds) |
| 2024-06-02 12:49:47 +0200 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2024-06-02 12:50:12 +0200 | kimiamania | (~65804703@user/kimiamania) |
| 2024-06-02 12:58:58 +0200 | TonyStone | (~TonyStone@user/TonyStone) |
| 2024-06-02 13:02:29 +0200 | mrmr1553343 | (~mrmr@user/mrmr) (Quit: Bye, See ya later!) |
| 2024-06-02 13:10:21 +0200 | pie_ | (~pie_bnc@user/pie/x-2818909) () |
| 2024-06-02 13:10:32 +0200 | pie_ | (~pie_bnc@user/pie/x-2818909) |
| 2024-06-02 13:14:45 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-06-02 13:18:51 +0200 | mrmr1553343 | (~mrmr@user/mrmr) |
| 2024-06-02 13:28:10 +0200 | <lxsameer> | b |
| 2024-06-02 13:30:25 +0200 | <int-e> | i c u |
| 2024-06-02 13:32:19 +0200 | rosco | (~rosco@90.58.221.226) (Ping timeout: 260 seconds) |
| 2024-06-02 13:33:23 +0200 | rosco | (~rosco@90.58.221.226) |
| 2024-06-02 13:35:14 +0200 | <ncf> | b i c a l s e t s |
| 2024-06-02 13:51:58 +0200 | rosco | (~rosco@90.58.221.226) (Quit: Lost terminal) |
| 2024-06-02 13:53:07 +0200 | rosco | (~rosco@90.58.221.226) |
| 2024-06-02 13:54:55 +0200 | wheatengineer | (~frederik@p200300f63f4e89007666e2f77a3735a1.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2024-06-02 13:55:51 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-06-02 14:17:07 +0200 | philopsos1 | (~caecilius@user/philopsos) (Ping timeout: 268 seconds) |
| 2024-06-02 14:23:25 +0200 | Rodney_ | (~Rodney@176.254.244.83) |
| 2024-06-02 14:29:04 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-06-02 14:40:33 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2024-06-02 14:42:04 +0200 | AlexZenon | (~alzenon@178.34.150.84) (Quit: ;-) |
| 2024-06-02 14:42:55 +0200 | AlexNoo | (~AlexNoo@178.34.150.84) (Quit: Leaving) |
| 2024-06-02 14:50:42 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Remote host closed the connection) |
| 2024-06-02 15:00:27 +0200 | ocra8 | (ocra8@user/ocra8) (Quit: WeeChat 4.2.2) |
| 2024-06-02 15:03:17 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2024-06-02 15:29:01 +0200 | AlexNoo | (~AlexNoo@178.34.150.84) |
| 2024-06-02 15:29:48 +0200 | AlexZenon | (~alzenon@178.34.150.84) |
| 2024-06-02 15:44:53 +0200 | Square | (~Square@user/square) (Quit: Leaving) |
| 2024-06-02 15:45:59 +0200 | red-snail | (~snail@static.151.210.203.116.clients.your-server.de) (Ping timeout: 252 seconds) |
| 2024-06-02 16:14:42 +0200 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2024-06-02 16:14:45 +0200 | rosco | (~rosco@90.58.221.226) (Quit: Lost terminal) |
| 2024-06-02 16:19:46 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2024-06-02 16:21:53 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-06-02 16:22:17 +0200 | mrmr15533431 | (~mrmr@user/mrmr) |
| 2024-06-02 16:22:43 +0200 | mrmr1553343 | (~mrmr@user/mrmr) (Ping timeout: 246 seconds) |
| 2024-06-02 16:22:43 +0200 | mrmr15533431 | mrmr1553343 |
| 2024-06-02 16:23:36 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2024-06-02 16:24:18 +0200 | <lxsameer> | Any recommendation for an high level networking library? I need to build a TCP/Unix socket service |
| 2024-06-02 16:26:30 +0200 | ocra8 | (ocra8@user/ocra8) |
| 2024-06-02 16:34:27 +0200 | <probie> | lxsameer: Can you elaborate on what you mean by "high level"? |
| 2024-06-02 16:35:58 +0200 | <lxsameer> | probie: e.g calling syscalls and manually take care of every detail == low level, A nice abstraction or framework to care about your communication only == highlevel |
| 2024-06-02 16:35:59 +0200 | red-snail | (~snail@static.151.210.203.116.clients.your-server.de) |
| 2024-06-02 16:36:52 +0200 | TMA | (tma@twin.jikos.cz) (Ping timeout: 260 seconds) |
| 2024-06-02 16:42:59 +0200 | igghibu | (~igghibu@178.249.211.83) |
| 2024-06-02 16:43:07 +0200 | igghibu | (~igghibu@178.249.211.83) (Client Quit) |
| 2024-06-02 16:43:29 +0200 | igghibu | (~igghibu@178.249.211.83) |
| 2024-06-02 16:47:47 +0200 | aforemny | (~aforemny@2001:9e8:6cce:6100:d5d5:d4fb:65d2:c482) |
| 2024-06-02 16:49:26 +0200 | aforemny_ | (~aforemny@i59F516D1.versanet.de) (Ping timeout: 268 seconds) |
| 2024-06-02 16:54:49 +0200 | troydm | (~troydm@user/troydm) |
| 2024-06-02 17:01:58 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Quit: https://zer0bitz.dy.fi) |
| 2024-06-02 17:06:19 +0200 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2024-06-02 17:07:10 +0200 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) |
| 2024-06-02 17:10:33 +0200 | igghibu | (~igghibu@178.249.211.83) (Quit: igghibu) |
| 2024-06-02 17:15:36 +0200 | kmein | (~weechat@user/kmein) (Ping timeout: 260 seconds) |
| 2024-06-02 17:21:07 +0200 | <probie> | lxsameer: But are your requirements at level of "I could write my program reading/writing stdin/stdout and then wrap it with socat", or do you need a bit more control? |
| 2024-06-02 17:22:17 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-06-02 17:22:46 +0200 | mechap | (~mechap@user/mechap) |
| 2024-06-02 17:24:06 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-06-02 17:25:59 +0200 | <probie> | Depending on what you want network-simple https://hackage.haskell.org/package/network-simple probably works well enough. If you need ssl, perhaps crypton-connection https://hackage.haskell.org/package/crypton-connection |
| 2024-06-02 17:28:05 +0200 | <mauke> | manually take care of every detail = raw sockets; communication only = stream sockets a.k.a tcp |
| 2024-06-02 17:35:31 +0200 | <EvanR> | it's funny because all these answers are much lower level than what you get in python or javascript. Because haskell comes with nice concurrency which is useful for not just networking, so a library doesn't have to deal with that |
| 2024-06-02 17:36:47 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-06-02 17:38:23 +0200 | myme | (~myme@2a01:799:d5c:5f00:1e69:7aff:feab:e7ae) (Ping timeout: 256 seconds) |
| 2024-06-02 17:45:32 +0200 | nschoe- | (~nschoe@2a01:e0a:8e:a190:542f:7ca5:d166:8539) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-02 17:45:49 +0200 | nschoe | (~nschoe@2a01:e0a:8e:a190:b029:5729:77ae:d1dd) |
| 2024-06-02 17:48:35 +0200 | rosco | (~rosco@90.58.221.226) |
| 2024-06-02 17:49:48 +0200 | son0p | (~ff@167.0.161.21) (Quit: Leaving) |
| 2024-06-02 17:51:30 +0200 | turlando | (~turlando@user/turlando) (Quit: No Ping reply in 180 seconds.) |
| 2024-06-02 17:52:17 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) |
| 2024-06-02 17:52:47 +0200 | turlando | (~turlando@user/turlando) |
| 2024-06-02 18:02:40 +0200 | inedia | (~irc@2600:3c00:e000:287::1) (Quit: WeeChat 4.1.2) |
| 2024-06-02 18:04:40 +0200 | inedia | (~irc@2600:3c00:e000:287::1) |
| 2024-06-02 18:07:48 +0200 | ak-1_ | (~ak-1@149.50.189.146) |
| 2024-06-02 18:08:45 +0200 | ak-1 | (~ak-1@149.50.189.92) (Ping timeout: 272 seconds) |
| 2024-06-02 18:10:26 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-06-02 18:10:42 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Quit: WeeChat 4.2.1) |
| 2024-06-02 18:11:00 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-06-02 18:13:23 +0200 | son0p | (~ff@167.0.161.21) |
| 2024-06-02 18:15:05 +0200 | aforemny | (~aforemny@2001:9e8:6cce:6100:d5d5:d4fb:65d2:c482) (Ping timeout: 256 seconds) |
| 2024-06-02 18:15:09 +0200 | rosco | (~rosco@90.58.221.226) (Ping timeout: 268 seconds) |
| 2024-06-02 18:19:13 +0200 | aforemny | (~aforemny@i59F516FA.versanet.de) |
| 2024-06-02 18:23:50 +0200 | rosco | (~rosco@90.58.221.226) |
| 2024-06-02 18:30:18 +0200 | <haskellbridge> | <pzka> EvanR: what are lower level python or js lib you're thinking for ? |
| 2024-06-02 18:32:19 +0200 | <EvanR> | python and js get hype for their high level evented i/o libraries |
| 2024-06-02 18:32:36 +0200 | <haskellbridge> | <pzka> because I don't see much difference between network-simple and https://docs.python.org/3/library/socket.html |
| 2024-06-02 18:33:25 +0200 | glguy | (g@libera/staff/glguy) (Read error: Connection reset by peer) |
| 2024-06-02 18:33:38 +0200 | <EvanR> | I'm comparing the high level haskell suggestion of "tcp socket" to high level twisted |
| 2024-06-02 18:33:55 +0200 | glguy | (g@libera/staff/glguy) |
| 2024-06-02 18:37:27 +0200 | <haskellbridge> | <pzka> is there no event driven networking framework in Haskell ? |
| 2024-06-02 18:38:43 +0200 | <haskellbridge> | <sm (@simonmic:matrix.org)> what did you find on hackage ? |
| 2024-06-02 18:39:24 +0200 | <geekosaur> | (is that really your display name?) |
| 2024-06-02 18:39:36 +0200 | <haskellbridge> | <pzka> sm: many thing |
| 2024-06-02 18:40:52 +0200 | <haskellbridge> | <sm (@simonmic:matrix.org)> maybe pick the best known framework of that kind and search for its name, it might be mentioned in descriptions |
| 2024-06-02 18:51:55 +0200 | <EvanR> | event driven framework in haskell might amount to looping over a TChan |
| 2024-06-02 18:52:54 +0200 | <EvanR> | then event sources don't need to written against a framework, they just use a TChan |
| 2024-06-02 18:57:29 +0200 | kmein | (~weechat@user/kmein) |
| 2024-06-02 19:09:21 +0200 | <haskellbridge> | <pzka> @sm I just took twisted's description of himself in their doc. |
| 2024-06-02 19:09:21 +0200 | <haskellbridge> | ... long message truncated: https://kf8nh.com/_matrix/media/v3/download/kf8nh.com/MmYeXVsivFNcOiebQhzNpoCD (3 lines) |
| 2024-06-02 19:10:03 +0200 | <jackdk> | @hackage reflex-backend-socket exists, but I don't think anyone built anything nontrivial atop it. Caveat lector |
| 2024-06-02 19:10:04 +0200 | <lambdabot> | https://hackage.haskell.org/package/reflex-backend-socket exists, but I don't think anyone built anything nontrivial atop it. Caveat lector |
| 2024-06-02 19:10:39 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2024-06-02 19:11:51 +0200 | <haskellbridge> | <pzka> interesting project |
| 2024-06-02 19:13:01 +0200 | yin | (~yin@user/zero) |
| 2024-06-02 19:15:24 +0200 | euleritian | (~euleritia@dynamic-176-001-216-155.176.1.pool.telefonica.de) |
| 2024-06-02 19:16:38 +0200 | <monochrom> | We have efficient green threads. We just use green threads, one thread per blocking I/O. |
| 2024-06-02 19:17:01 +0200 | <monochrom> | Another way to put it: the RTS already contains the event loop. |
| 2024-06-02 19:17:14 +0200 | <haskellbridge> | <sm (@simonmic:matrix.org)> I spent a few minutes searching for buzzwords and found eg amazon EventBridge things on hackage. Cloud haskell also comes to mind. But yes there's no well known framework to point you at. |
| 2024-06-02 19:18:36 +0200 | <monochrom> | It is interesting how Haskell is very different and so conventional wisdoms from other languages simply don't carry over. |
| 2024-06-02 19:19:17 +0200 | <monochrom> | "how do I write a for loop?" : just don't, use a lazy list :: "how do I write an event loop?" : just don't, use threads. |
| 2024-06-02 19:21:26 +0200 | <glguy> | whoops, I used green threads to implement my event loop https://github.com/glguy/irc-core/blob/v2/src/Client/EventLoop.hs#L137-L160 |
| 2024-06-02 19:23:42 +0200 | <monochrom> | I teach a Unix course including select() and epoll(). I also teach that reality that just because you call send()/write() once for 5 bytes doesn't mean that the receiver just needs one recv()/read() and expects to get all 5 in one go. |
| 2024-06-02 19:25:14 +0200 | mechap | (~mechap@user/mechap) (Quit: WeeChat 4.3.0) |
| 2024-06-02 19:27:12 +0200 | <monochrom> | Then I thought of giving them an assignment on writing your own select()/epoll() loop communicating with multiple clients. Well, the complexity dawns on me that given the fragmentation mentioned, you now have to keep so much bookkeeping state for each client, you are writing your own OS. |
| 2024-06-02 19:27:32 +0200 | <monochrom> | So why not use the existing OS? Just use threads. |
| 2024-06-02 19:36:33 +0200 | TactfulCitrus | (~al@2a02:8012:87a6:0:fbe0:6116:6e30:e047) (Ping timeout: 268 seconds) |
| 2024-06-02 19:41:51 +0200 | <haskellbridge> | <pzka> I agree that asynchronous programming is more complex, but threads are more costly. Matter of choice I guess |
| 2024-06-02 19:43:06 +0200 | <geekosaur> | not in Haskell |
| 2024-06-02 19:43:21 +0200 | <monochrom> | This is where you take advantage of cheap green threads from GHC. IOW GHC RTS does the reinvent-my-own-OS for you. |
| 2024-06-02 19:43:24 +0200 | <geekosaur> | they're designed to be extremely cheap (but I think this comes with other tradeoffs) |
| 2024-06-02 19:43:40 +0200 | <monochrom> | But even with Unix OS threads it is not too bad. |
| 2024-06-02 19:44:02 +0200 | <glguy> | threads introduce synchronization complexity, even in Haskell. There's no single ideal solution; it's all tradeoffs |
| 2024-06-02 19:48:33 +0200 | <monochrom> | I come from the angle that code that is trivial to write and obviously correct at first glance has a higher priority than a constant factor of cost. |
| 2024-06-02 19:50:29 +0200 | <glguy> | If you're writing GHC/Haskell then the green threads are the concurrency primitive and they're pretty easy to use, but they do make somethings harder to synchronize |
| 2024-06-02 19:50:43 +0200 | <monochrom> | OK you can then reply that GHC RTS itself cannot possibly be trivial to write and obviously correct at first glance. So even correctness itself has a tradeoff between "is the issue in my code" and "is the issue in someone else's code" heh. |
| 2024-06-02 19:50:44 +0200 | euleritian | (~euleritia@dynamic-176-001-216-155.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-06-02 19:51:02 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-06-02 19:51:04 +0200 | <glguy> | threads can make the code less obviously correct at first glance, though, as you have to reason about a much more complicated interleaving |
| 2024-06-02 19:51:14 +0200 | <haskellbridge> | <pzka> you need synchronisation if you share data. This not necessarily induced by the threads usage |
| 2024-06-02 19:52:12 +0200 | <geekosaur> | Haskell changes that a bit, actually. you need to send data between threads, not share it |
| 2024-06-02 19:52:21 +0200 | <haskellbridge> | <pzka> I'm really not an expert on Haskell. So I'm willing to believe that green threads are a better solution in this language. |
| 2024-06-02 19:52:21 +0200 | <geekosaur> | the usual mechanism for that is a TChan |
| 2024-06-02 19:52:43 +0200 | <geekosaur> | this is because of purity |
| 2024-06-02 19:52:53 +0200 | <haskellbridge> | <pzka> Yes agree |
| 2024-06-02 19:52:57 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-02 19:53:02 +0200 | <haskellbridge> | <pzka> I was thinking about that too |
| 2024-06-02 19:53:18 +0200 | <glguy> | You can either send data with channels, or have shared state with MVars, TVars, etc |
| 2024-06-02 19:53:54 +0200 | <glguy> | STM is nice in how it allows you to wait any number of different events at once |
| 2024-06-02 19:54:21 +0200 | <geekosaur> | STM (pretty much anything prefixed with T) is a lightweight mechanism for both |
| 2024-06-02 19:54:29 +0200 | <haskellbridge> | <pzka> "An MVar t is a mutable location " Oh no ... |
| 2024-06-02 19:54:56 +0200 | <monochrom> | Read on. You will find that it is instead a message box of capacity 1. |
| 2024-06-02 19:55:05 +0200 | <haskellbridge> | <pzka> ah ok |
| 2024-06-02 19:55:14 +0200 | <monochrom> | So suddenly it's just a message queue not shared memory. |
| 2024-06-02 19:55:51 +0200 | <haskellbridge> | <pzka> ah yes I see so synchronisation is handled by the MVar itself right ? |
| 2024-06-02 19:56:11 +0200 | <haskellbridge> | <pzka> no need for semaphoe, mutex etc... |
| 2024-06-02 19:56:16 +0200 | <monochrom> | I follow my thesis supervisor in believing that message channels are much better than shared memory. |
| 2024-06-02 19:56:32 +0200 | <haskellbridge> | <pzka> (That's what I mean by synchronization) |
| 2024-06-02 19:56:41 +0200 | califax | (~califax@user/califx) |
| 2024-06-02 19:56:41 +0200 | <monochrom> | You can use MVar () to get a mutex. |
| 2024-06-02 19:57:21 +0200 | <monochrom> | But I would just (re)design everything around channels in the first place. |
| 2024-06-02 19:57:23 +0200 | <haskellbridge> | <pzka> ok |
| 2024-06-02 19:57:49 +0200 | <haskellbridge> | <pzka> sadly I have to go but this discussion was very interesting |
| 2024-06-02 19:57:57 +0200 | <monochrom> | rather than, IMO, regressively reactively use channels to emulate dark age shared memory. |
| 2024-06-02 19:58:03 +0200 | <haskellbridge> | <pzka> I will hjave a look to MVar |
| 2024-06-02 19:58:43 +0200 | <probie> | I don't think I'm willing to accept that "message channels are much better than shared memory". I'm happy with "message channels are nearly always much better than shared memory" though |
| 2024-06-02 19:58:47 +0200 | <haskellbridge> | <pzka> I think no "modern" language do that |
| 2024-06-02 19:59:23 +0200 | <monochrom> | Yeah I am happy with just "nearly always" |
| 2024-06-02 19:59:33 +0200 | <haskellbridge> | <pzka> Maybe for highly cpu bound application |
| 2024-06-02 19:59:54 +0200 | <monochrom> | I confess that I have a program that even just use one IORef with atomicModifyIORef. |
| 2024-06-02 20:00:36 +0200 | <glguy> | all of this depends on the program you're making |
| 2024-06-02 20:00:51 +0200 | <geekosaur> | doesn't the MVaar documentation (maybe it's the atomicModifyIORef docs) even suggest you do that if you're only using one? |
| 2024-06-02 20:01:12 +0200 | <monochrom> | I have a Data.Map. I put it in an IORef for multiple-thread access. There is no race condition because I only have 1 IORef, not even 2. |
| 2024-06-02 20:01:41 +0200 | <monochrom> | Yeah this is actually an underrated technique. |
| 2024-06-02 20:02:51 +0200 | <monochrom> | The trick is that Data.Map is immutable so all the talks about race conditions over a large data structure and how you now need elaborate lock-free techniques in mainstream imperative languages is completely lost because we are in an immutable functional language. |
| 2024-06-02 20:03:10 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-06-02 20:03:25 +0200 | <monochrom> | The only problem is it doesn't even scale to 2 IORefs. >:) |
| 2024-06-02 20:07:06 +0200 | <jackdk> | Ah, but we have product types for that |
| 2024-06-02 20:07:31 +0200 | <monochrom> | Haha true. Data.Map is just doing that on steroid. |
| 2024-06-02 20:08:19 +0200 | troydm | (~troydm@user/troydm) (Ping timeout: 268 seconds) |
| 2024-06-02 20:09:40 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-06-02 20:09:54 +0200 | <probie> | Vaguely related complaint. Go prefer message channels to shared memory, however since maps are mutable, to (safely) send a map over a channel, you have to copy the entire thing. |
| 2024-06-02 20:10:56 +0200 | <probie> | This means if you're sending across some struct which contains several maps, you're stuck either copying them all (even if only one changed) or having a more complicated protocol where you need to specify what parts have changed |
| 2024-06-02 20:11:13 +0200 | <probie> | meanwhile in Haskell-land, I don't even need to think about this |
| 2024-06-02 20:11:37 +0200 | <monochrom> | Selection bias but there is a reason I'm in this channel not the Go channel :) |
| 2024-06-02 20:12:16 +0200 | <monochrom> | I bet also for most of us here. :) |
| 2024-06-02 20:19:33 +0200 | <probie> | It's important to see what other languages are doing. Even the worst ones (apart from PHP) have some good ideas |
| 2024-06-02 20:32:20 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-02 20:33:10 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-06-02 20:34:45 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-06-02 20:36:00 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: Leaving) |
| 2024-06-02 20:41:48 +0200 | <yin> | why no whole-program compilation in haskell? |
| 2024-06-02 20:42:25 +0200 | <yin> | my intuition is that haskell has a huge potential for cross-library optimizations |
| 2024-06-02 20:42:35 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (WeeChat 4.2.2) |
| 2024-06-02 20:43:19 +0200 | <glguy> | yin: definitions can be inlined into the interface files generated when compiling a module for the cases where that's most impactful |
| 2024-06-02 20:47:04 +0200 | <geekosaur> | yin, jhc did WPC, and the GRIN project has been experimenting with a WPC mechanism for GHC |
| 2024-06-02 20:48:03 +0200 | adium | (adium@user/adium) (Leaving) |
| 2024-06-02 20:49:14 +0200 | <mauke> | does anyone know if there's a select() for haskell on hackage? |
| 2024-06-02 20:49:22 +0200 | <yin> | ooh that's nice |
| 2024-06-02 20:49:30 +0200 | <mauke> | or do I have to implement my own (on top of threads?)? |
| 2024-06-02 20:50:07 +0200 | <raehik> | Are there any parser combinator libraries out there that don't support backtracking? that probably generate LL(1) parsers? |
| 2024-06-02 20:50:40 +0200 | <raehik> | asking because it appears that's my type-level parser combinator lib is and I'm trying to reason about it |
| 2024-06-02 20:50:40 +0200 | <geekosaur> | mauke, I only see one and it's from 2013 |
| 2024-06-02 20:50:53 +0200 | phma | (~phma@host-67-44-208-88.hnremote.net) (Read error: Connection reset by peer) |
| 2024-06-02 20:51:46 +0200 | phma | (phma@2001:5b0:211c:2db8:8455:4a59:eacb:62a6) |
| 2024-06-02 20:51:47 +0200 | <monochrom> | mauke: There is an "epoll", there is a "kqueue". I heard of them a long time ago. Not sure if there are others. |
| 2024-06-02 20:52:51 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-02 20:52:56 +0200 | <geekosaur> | both of those will be OS dependent (epoll is Linux, kqueue is *BSD) |
| 2024-06-02 20:54:28 +0200 | causal | (~eric@50.35.88.207) |
| 2024-06-02 20:57:18 +0200 | califax | (~califax@user/califx) |
| 2024-06-02 21:05:31 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2024-06-02 21:08:43 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-06-02 21:11:38 +0200 | dispater | (~dispater@mail.brprice.uk) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-02 21:11:38 +0200 | orcus | (~orcus@mail.brprice.uk) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-06-02 21:13:37 +0200 | dispater | (~dispater@mail.brprice.uk) |
| 2024-06-02 21:14:07 +0200 | orcus | (~orcus@mail.brprice.uk) |
| 2024-06-02 21:17:33 +0200 | califax | (~califax@user/califx) |
| 2024-06-02 21:20:38 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-02 21:21:18 +0200 | andrei_n | (~andrei_n@2a02:a03f:c091:a800:f349:d45c:cf6b:1a3e) |
| 2024-06-02 21:37:26 +0200 | andrei_n | (~andrei_n@2a02:a03f:c091:a800:f349:d45c:cf6b:1a3e) (Ping timeout: 256 seconds) |
| 2024-06-02 21:45:55 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-06-02 21:48:51 +0200 | andrei_n | (~andrei_n@2a02:a03f:c091:a800:f349:d45c:cf6b:1a3e) |
| 2024-06-02 21:58:01 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2024-06-02 21:59:30 +0200 | michalz | (~michalz@185.246.207.221) |
| 2024-06-02 22:04:29 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-06-02 22:06:06 +0200 | vnogueira | (~vnogueira@2804:7f1:e2c0:4f34:9ed5:e091:ca3:9df2) |
| 2024-06-02 22:07:05 +0200 | vnogueira | (~vnogueira@2804:7f1:e2c0:4f34:9ed5:e091:ca3:9df2) () |
| 2024-06-02 22:19:45 +0200 | myme | (~myme@2a01:799:d5c:5f00:69d5:8c7b:dd4d:cbe8) |
| 2024-06-02 22:43:05 +0200 | andrei_n | (~andrei_n@2a02:a03f:c091:a800:f349:d45c:cf6b:1a3e) (Quit: Leaving) |
| 2024-06-02 22:53:53 +0200 | ak-1_ | (~ak-1@149.50.189.146) (Ping timeout: 252 seconds) |
| 2024-06-02 23:09:18 +0200 | m5zs7k | (aquares@web10.mydevil.net) (Ping timeout: 268 seconds) |
| 2024-06-02 23:15:26 +0200 | m5zs7k | (aquares@web10.mydevil.net) |
| 2024-06-02 23:16:08 +0200 | <dmj`> | yin: there's huge potential, GHC was started when memory was ~1MB, so everything had to be incremental compilation. Inlining typeclass definitions for the /entire/ program's dep. tree, not just interface files is a huge win. |
| 2024-06-02 23:21:17 +0200 | <mauke> | that works as long as your program doesn't create types at runtime |
| 2024-06-02 23:33:13 +0200 | michalz | (~michalz@185.246.207.221) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-06-02 23:35:15 +0200 | rosco | (~rosco@90.58.221.226) (Quit: Lost terminal) |
| 2024-06-02 23:39:10 +0200 | troydm | (~troydm@user/troydm) |
| 2024-06-02 23:46:58 +0200 | myxos | (~myxos@syn-065-028-251-121.res.spectrum.com) (Remote host closed the connection) |
| 2024-06-02 23:48:09 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2024-06-02 23:51:05 +0200 | troojg | (~troojg@99.36.5.199) |
| 2024-06-02 23:54:42 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |