| 2024-04-30 00:03:16 +0200 | michalz | (~michalz@185.246.207.203) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-30 00:04:07 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:90bc:b4a5:eea5:19e6) (Remote host closed the connection) |
| 2024-04-30 00:07:07 +0200 | dolio | (~dolio@130.44.134.54) (Ping timeout: 256 seconds) |
| 2024-04-30 00:07:53 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-04-30 00:08:50 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-04-30 00:11:12 +0200 | waldo | (~waldo@user/waldo) |
| 2024-04-30 00:13:02 +0200 | pavonia | (~user@user/siracusa) |
| 2024-04-30 00:13:09 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Read error: Connection reset by peer) |
| 2024-04-30 00:21:09 +0200 | acidjnk | (~acidjnk@p200300d6e714dc2634962692522af535.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2024-04-30 00:22:29 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 240 seconds) |
| 2024-04-30 00:26:41 +0200 | qqq | (~qqq@92.43.167.61) (Quit: leaving) |
| 2024-04-30 00:27:52 +0200 | yin | (~yin@user/zero) (Ping timeout: 260 seconds) |
| 2024-04-30 00:28:49 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 00:32:59 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 252 seconds) |
| 2024-04-30 00:36:37 +0200 | xdminsy | (~xdminsy@117.147.70.233) (Quit: Konversation terminated!) |
| 2024-04-30 00:37:03 +0200 | xdminsy | (~xdminsy@117.147.70.233) |
| 2024-04-30 00:47:06 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 00:47:17 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-04-30 00:48:10 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-04-30 00:50:08 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-04-30 00:50:59 +0200 | kaptch | (~kaptch@84.238.85.45) |
| 2024-04-30 00:50:59 +0200 | kaptch | (~kaptch@84.238.85.45) (Client Quit) |
| 2024-04-30 00:51:55 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 00:52:59 +0200 | mima | (~mmh@aftr-62-216-211-53.dynamic.mnet-online.de) (Ping timeout: 272 seconds) |
| 2024-04-30 00:55:09 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 256 seconds) |
| 2024-04-30 00:57:02 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2024-04-30 01:00:36 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-04-30 01:02:18 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 260 seconds) |
| 2024-04-30 01:04:28 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-04-30 01:07:52 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 01:09:37 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 01:14:15 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 252 seconds) |
| 2024-04-30 01:15:47 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-04-30 01:30:20 +0200 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2024-04-30 01:31:31 +0200 | <c_wraith> | Just spent hours tracking down an emergency production issue caused by a 10-year-old type issue that was never exercised. I wish $dayjob used a language that actually cares about that.. |
| 2024-04-30 01:33:34 +0200 | <geekosaur> | oy |
| 2024-04-30 01:33:49 +0200 | <waldo> | what is this $dayjob thing |
| 2024-04-30 01:33:56 +0200 | <waldo> | it appears in ##rust also |
| 2024-04-30 01:34:02 +0200 | <c_wraith> | the thing that finances my life of feeding a cat. |
| 2024-04-30 01:34:56 +0200 | <waldo> | yeah but why is it used in such close time proximity to the other use in the other channel |
| 2024-04-30 01:35:28 +0200 | <waldo> | probably a cabal? |
| 2024-04-30 01:35:48 +0200 | <waldo> | that's how I spend my time these days, |
| 2024-04-30 01:36:03 +0200 | <waldo> | analyzing irc chat room conversations, trying to find the pattern |
| 2024-04-30 01:36:18 +0200 | <waldo> | irc chat is like hiv virus isn't it |
| 2024-04-30 01:36:35 +0200 | <waldo> | maybe I should cut myself off |
| 2024-04-30 01:36:42 +0200 | <c_wraith> | probably a good idea |
| 2024-04-30 01:38:54 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-04-30 01:38:55 +0200 | waldo | (~waldo@user/waldo) (Quit: waldo) |
| 2024-04-30 01:41:40 +0200 | <yushyin> | odd |
| 2024-04-30 01:45:25 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 01:51:38 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 252 seconds) |
| 2024-04-30 02:06:18 +0200 | dolio | (~dolio@130.44.134.54) |
| 2024-04-30 02:06:21 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 02:11:12 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-30 02:11:31 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 272 seconds) |
| 2024-04-30 02:15:57 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 2024-04-30 02:24:17 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 02:27:37 +0200 | finsternis | (~X@23.226.237.192) |
| 2024-04-30 02:28:59 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 02:31:01 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 02:33:05 +0200 | YuutaW | (~YuutaW@mail.yuuta.moe) |
| 2024-04-30 02:36:43 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 256 seconds) |
| 2024-04-30 02:38:50 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 02:41:32 +0200 | <Axman6> | very |
| 2024-04-30 02:46:07 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 268 seconds) |
| 2024-04-30 02:52:02 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 02:52:08 +0200 | jorj | (~jorj@user/jorj) |
| 2024-04-30 02:52:51 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 02:56:10 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2024-04-30 02:57:31 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 246 seconds) |
| 2024-04-30 03:03:20 +0200 | TonyStone | (~TonyStone@user/TonyStone) |
| 2024-04-30 03:07:54 +0200 | dsrt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-04-30 03:09:42 +0200 | shapr | (~user@c-24-218-186-89.hsd1.ma.comcast.net) (Remote host closed the connection) |
| 2024-04-30 03:10:38 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 260 seconds) |
| 2024-04-30 03:11:42 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-04-30 03:15:45 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 245 seconds) |
| 2024-04-30 03:20:06 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 03:22:01 +0200 | cheater_ | (~Username@user/cheater) |
| 2024-04-30 03:23:40 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 256 seconds) |
| 2024-04-30 03:23:46 +0200 | cheater_ | cheater |
| 2024-04-30 03:29:25 +0200 | otto_s | (~user@p5de2f4e6.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-04-30 03:30:30 +0200 | otto_s | (~user@p4ff27e40.dip0.t-ipconnect.de) |
| 2024-04-30 03:34:37 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 03:35:23 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 03:36:32 +0200 | tri | (~tri@2607:fb90:ad06:c188:4cd3:9cb3:a1f9:52b3) |
| 2024-04-30 03:40:02 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 260 seconds) |
| 2024-04-30 03:40:57 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-04-30 03:50:27 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 252 seconds) |
| 2024-04-30 03:51:22 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-04-30 03:58:49 +0200 | phma | (~phma@host-67-44-208-75.hnremote.net) (Read error: Connection reset by peer) |
| 2024-04-30 04:00:15 +0200 | phma | (phma@2001:5b0:2172:9258:5c6c:8366:4239:d1fd) |
| 2024-04-30 04:02:04 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-30 04:06:18 +0200 | tri_ | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-30 04:06:46 +0200 | tri__ | (~tri@2607:fb91:d8d:8428:8d98:5850:5d68:328f) |
| 2024-04-30 04:09:36 +0200 | tri___ | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-30 04:09:55 +0200 | tri | (~tri@2607:fb90:ad06:c188:4cd3:9cb3:a1f9:52b3) (Ping timeout: 245 seconds) |
| 2024-04-30 04:10:30 +0200 | tri_ | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 255 seconds) |
| 2024-04-30 04:12:23 +0200 | tri___ | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-04-30 04:12:50 +0200 | tri__ | (~tri@2607:fb91:d8d:8428:8d98:5850:5d68:328f) (Ping timeout: 245 seconds) |
| 2024-04-30 04:22:15 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-04-30 04:24:39 +0200 | mei | (~mei@user/mei) |
| 2024-04-30 04:25:33 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.1.1) |
| 2024-04-30 04:27:15 +0200 | foul_owl | (~kerry@174-21-71-155.tukw.qwest.net) (Ping timeout: 268 seconds) |
| 2024-04-30 04:29:25 +0200 | td_ | (~td@i5387093D.versanet.de) (Ping timeout: 255 seconds) |
| 2024-04-30 04:30:03 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-04-30 04:30:59 +0200 | td_ | (~td@i53870902.versanet.de) |
| 2024-04-30 04:36:53 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-30 04:39:07 +0200 | foul_owl | (~kerry@185.216.231.179) |
| 2024-04-30 04:41:26 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2024-04-30 04:46:11 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-04-30 04:53:37 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-04-30 04:54:06 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-30 04:58:00 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-30 05:07:11 +0200 | ski | (~ski@ext-1-033.eduroam.chalmers.se) (Ping timeout: 264 seconds) |
| 2024-04-30 05:08:17 +0200 | aforemny_ | (~aforemny@i59F516CA.versanet.de) |
| 2024-04-30 05:08:51 +0200 | ski | (~ski@ext-1-033.eduroam.chalmers.se) |
| 2024-04-30 05:08:59 +0200 | aforemny | (~aforemny@i59F516F8.versanet.de) (Ping timeout: 264 seconds) |
| 2024-04-30 05:21:03 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 05:21:44 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 05:27:13 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 272 seconds) |
| 2024-04-30 05:32:45 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 252 seconds) |
| 2024-04-30 05:34:50 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-04-30 05:37:14 +0200 | mei | (~mei@user/mei) |
| 2024-04-30 05:40:18 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 05:44:21 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-30 05:45:17 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 256 seconds) |
| 2024-04-30 05:57:51 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 06:01:12 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-04-30 06:03:15 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 245 seconds) |
| 2024-04-30 06:09:24 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-30 06:16:15 +0200 | tri_ | (~tri@2607:fb90:b10f:47a3:51d7:cdf1:c1a7:3d00) |
| 2024-04-30 06:17:49 +0200 | tri__ | (~tri@2607:fb90:b1ab:4243:713b:b2d:b4c9:5170) |
| 2024-04-30 06:20:06 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2024-04-30 06:21:27 +0200 | tri_ | (~tri@2607:fb90:b10f:47a3:51d7:cdf1:c1a7:3d00) (Ping timeout: 255 seconds) |
| 2024-04-30 06:32:01 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 06:36:45 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 268 seconds) |
| 2024-04-30 06:36:46 +0200 | causal | (~eric@50.35.88.207) |
| 2024-04-30 06:38:46 +0200 | phma | (phma@2001:5b0:2172:9258:5c6c:8366:4239:d1fd) (Read error: Connection reset by peer) |
| 2024-04-30 06:39:15 +0200 | phma | (~phma@2001:5b0:2172:9258:5c6c:8366:4239:d1fd) |
| 2024-04-30 06:46:10 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 245 seconds) |
| 2024-04-30 06:46:42 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 260 seconds) |
| 2024-04-30 06:47:29 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-04-30 07:05:07 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 07:11:10 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 245 seconds) |
| 2024-04-30 07:14:08 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-04-30 07:17:06 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-04-30 07:19:05 +0200 | tri__ | (~tri@2607:fb90:b1ab:4243:713b:b2d:b4c9:5170) (Remote host closed the connection) |
| 2024-04-30 07:23:38 +0200 | Rodney_ | (~Rodney@176.254.244.83) (Read error: Connection reset by peer) |
| 2024-04-30 07:29:16 +0200 | ACuriousMoose7 | (~ACuriousM@142.68.181.38) |
| 2024-04-30 07:30:02 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-04-30 07:30:29 +0200 | ACuriousMoose | (~ACuriousM@142.68.181.38) (Ping timeout: 240 seconds) |
| 2024-04-30 07:30:30 +0200 | ACuriousMoose7 | ACuriousMoose |
| 2024-04-30 07:39:20 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-04-30 07:42:55 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-04-30 07:43:59 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2024-04-30 07:51:09 +0200 | michalz | (~michalz@185.246.207.193) |
| 2024-04-30 07:54:35 +0200 | krei-se | (~krei-se@p5085d49b.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-04-30 07:58:57 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 07:59:25 +0200 | steew | (~steew@user/steew) (Remote host closed the connection) |
| 2024-04-30 08:10:20 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 08:13:51 +0200 | Rodney_ | (~Rodney@176.254.244.83) |
| 2024-04-30 08:16:39 +0200 | dtman34 | (~dtman34@2601:447:d001:ed50:e2b0:b15b:8890:6869) (Ping timeout: 268 seconds) |
| 2024-04-30 08:19:12 +0200 | krei-se | (~krei-se@p57af22bf.dip0.t-ipconnect.de) |
| 2024-04-30 08:24:16 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 08:26:27 +0200 | dtman34 | (~dtman34@c-75-72-163-222.hsd1.mn.comcast.net) |
| 2024-04-30 08:27:43 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:99e7:4463:681a:66ac) (Ping timeout: 272 seconds) |
| 2024-04-30 08:28:22 +0200 | jle` | (~jle`@2603:8001:3b02:84d4:2ec9:5672:626b:934d) |
| 2024-04-30 08:29:23 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 264 seconds) |
| 2024-04-30 08:32:50 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 245 seconds) |
| 2024-04-30 08:35:20 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-04-30 08:38:28 +0200 | kuribas | (~user@2a02:1808:85:df78:ebd1:2ca1:ec6f:f34e) |
| 2024-04-30 08:39:58 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-04-30 08:42:38 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 08:49:39 +0200 | malte | (~malte@mal.tc) (Ping timeout: 252 seconds) |
| 2024-04-30 08:50:58 +0200 | malte | (~malte@mal.tc) |
| 2024-04-30 08:52:20 +0200 | mima | (~mmh@aftr-62-216-211-48.dynamic.mnet-online.de) |
| 2024-04-30 08:52:53 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 240 seconds) |
| 2024-04-30 08:56:20 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-04-30 09:02:07 +0200 | kuribas | (~user@2a02:1808:85:df78:ebd1:2ca1:ec6f:f34e) (Ping timeout: 255 seconds) |
| 2024-04-30 09:04:12 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 09:09:45 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 255 seconds) |
| 2024-04-30 09:22:50 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 09:28:31 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 09:31:35 +0200 | Yumemi | (~Yumemi@2001:bc8:47a0:1b14::1) (Ping timeout: 245 seconds) |
| 2024-04-30 09:31:50 +0200 | Yumemi | (~Yumemi@chamoin.net) |
| 2024-04-30 09:32:00 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 256 seconds) |
| 2024-04-30 09:32:16 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-04-30 09:37:02 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) (Quit: WeeChat 2.9) |
| 2024-04-30 09:37:07 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-04-30 09:38:00 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-04-30 09:39:29 +0200 | califax | (~califax@user/califx) |
| 2024-04-30 09:42:06 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 09:44:48 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-04-30 09:45:28 +0200 | califax | (~califax@user/califx) |
| 2024-04-30 09:45:44 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-04-30 09:46:43 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) (Ping timeout: 260 seconds) |
| 2024-04-30 09:50:16 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 255 seconds) |
| 2024-04-30 09:56:04 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-04-30 10:06:40 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-30 10:18:20 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 10:19:01 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) |
| 2024-04-30 10:19:01 +0200 | mreh | (~matthew@host86-160-168-68.range86-160.btcentralplus.com) |
| 2024-04-30 10:21:47 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:2128:605:71c4:66a4) |
| 2024-04-30 10:28:15 +0200 | JimL | (~quassel@89.162.16.26) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-04-30 10:28:33 +0200 | JimL | (~quassel@89.162.16.26) |
| 2024-04-30 10:29:52 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 255 seconds) |
| 2024-04-30 10:29:58 +0200 | ft | (~ft@p4fc2a1f9.dip0.t-ipconnect.de) (Quit: leaving) |
| 2024-04-30 10:35:03 +0200 | JimL | (~quassel@89.162.16.26) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-04-30 10:35:21 +0200 | JimL | (~quassel@89.162.16.26) |
| 2024-04-30 10:37:10 +0200 | JimL | (~quassel@89.162.16.26) (Client Quit) |
| 2024-04-30 10:37:29 +0200 | JimL | (~quassel@89.162.16.26) |
| 2024-04-30 10:40:40 +0200 | chele | (~chele@user/chele) |
| 2024-04-30 10:42:49 +0200 | califax_ | (~califax@user/califx) |
| 2024-04-30 10:42:50 +0200 | califax | (~califax@user/califx) (Ping timeout: 260 seconds) |
| 2024-04-30 10:44:08 +0200 | califax_ | califax |
| 2024-04-30 10:45:49 +0200 | danza | (~francesco@151.57.154.79) |
| 2024-04-30 10:47:28 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-04-30 10:47:56 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Remote host closed the connection) |
| 2024-04-30 10:48:54 +0200 | <ski> | tomsmeding : `/topic' ? |
| 2024-04-30 10:53:35 +0200 | <tomsmeding> | ski: hm? |
| 2024-04-30 11:04:19 +0200 | <tomsmeding> | :q |
| 2024-04-30 11:04:24 +0200 | <tomsmeding> | ... oops |
| 2024-04-30 11:07:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-30 11:07:58 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-04-30 11:10:28 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 260 seconds) |
| 2024-04-30 11:18:55 +0200 | <ski> | tomsmeding : it doesn't display topic for you, in weechat ? |
| 2024-04-30 11:18:57 +0200 | califax | (~califax@user/califx) |
| 2024-04-30 11:20:21 +0200 | <tomsmeding> | it does |
| 2024-04-30 11:20:29 +0200 | <tomsmeding> | what made you think that? |
| 2024-04-30 11:21:06 +0200 | tolt | (~kevin@li219-154.members.linode.com) |
| 2024-04-30 11:21:33 +0200 | <ski> | <tomsmeding> I've learned to read it -- it took me an embarrassingly long time to figure out how to scroll to the end in weechat |
| 2024-04-30 11:21:41 +0200 | <tomsmeding> | oh |
| 2024-04-30 11:21:51 +0200 | <tomsmeding> | I see the first screenwidth of the topic above the channel buffer |
| 2024-04-30 11:22:03 +0200 | <dminuoso> | tomsmeding: And how do you scroll to the end in weechat? |
| 2024-04-30 11:22:08 +0200 | <tomsmeding> | (and also the whole thing on join, but I don't often first-time-join a channel ;) ) |
| 2024-04-30 11:22:23 +0200 | <tomsmeding> | dminuoso: by using the mouse scroll wheel when the mouse is on that line in the terminal (!) |
| 2024-04-30 11:22:25 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 245 seconds) |
| 2024-04-30 11:22:38 +0200 | <tomsmeding> | there's also a bizarrely obscure keybind for it iirc |
| 2024-04-30 11:22:46 +0200 | <dminuoso> | Oh I have mouse mode turned off, because I cant deal with it. |
| 2024-04-30 11:22:47 +0200 | <ncf> | /set weechat.bar.title.size_max 3 |
| 2024-04-30 11:22:56 +0200 | <ski> | yea, just saying you can, at least in Irssi, repeat the whole topic, with `/topic', and i'd imagine also in weechat |
| 2024-04-30 11:22:56 +0200 | <dminuoso> | It just does.. things and confuses me |
| 2024-04-30 11:23:03 +0200 | <tomsmeding> | and have it take up more than 1 line of my screen? no thanks :) |
| 2024-04-30 11:23:17 +0200 | <tomsmeding> | ski: right, /topic indeed also repeats it |
| 2024-04-30 11:23:25 +0200 | <dminuoso> | But yeah, I just use /topic |
| 2024-04-30 11:23:41 +0200 | ski | bound `C-home' and `C-end' to scroll to top and bottom of scrollback buffer |
| 2024-04-30 11:24:29 +0200 | qqq | (~qqq@92.43.167.61) |
| 2024-04-30 11:24:46 +0200 | tolt_ | (~kevin@li219-154.members.linode.com) |
| 2024-04-30 11:25:38 +0200 | <tomsmeding> | dminuoso: F10 to scroll forward, F9 to scroll back |
| 2024-04-30 11:25:48 +0200 | <tomsmeding> | (found by spelunking in /key list) |
| 2024-04-30 11:27:00 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 11:27:08 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-04-30 11:27:44 +0200 | tolt | (~kevin@li219-154.members.linode.com) (Ping timeout: 260 seconds) |
| 2024-04-30 11:30:19 +0200 | <tomsmeding> | I have a (haskell) function that allocates a whole bunch of data on the heap, and another function that consumes it all again. I know that all data in that particular data structure will be live until the second function consumes it, and the data ought to be kept live as long as the second function is live (it has a pointer to it in its closure); it's pointless for the GC to traverse the data |
| 2024-04-30 11:30:20 +0200 | tolt_ | (~kevin@li219-154.members.linode.com) (Quit: WeeChat 4.2.2) |
| 2024-04-30 11:30:21 +0200 | <tomsmeding> | structure while the second function is still live |
| 2024-04-30 11:30:51 +0200 | <tomsmeding> | and because the structure is large, the GC actually takes a long time to traverse it, and repeatedly does so while it's being constructed -- lots of wasted cpu cycles |
| 2024-04-30 11:31:11 +0200 | <tomsmeding> | the thing is, 1. I'm allocating that structure in parallel, and 2. it has lots of internal sharing |
| 2024-04-30 11:31:25 +0200 | tolt | (~kevin@li219-154.members.linode.com) |
| 2024-04-30 11:31:37 +0200 | <tomsmeding> | I'd like to use a compact region, but that doesn't apply here because of (1.) and (2.), right? |
| 2024-04-30 11:32:40 +0200 | <tomsmeding> | (GC is really taking up a significant percentage of the runtime here, like >60%, so it really matters) |
| 2024-04-30 11:32:42 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2024-04-30 11:33:45 +0200 | swamp_ | (~zmt00@user/zmt00) |
| 2024-04-30 11:34:53 +0200 | tolt | (~kevin@li219-154.members.linode.com) (Client Quit) |
| 2024-04-30 11:35:11 +0200 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 272 seconds) |
| 2024-04-30 11:35:40 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 11:37:11 +0200 | Guest27 | (~Guest27@50.47.204.13) |
| 2024-04-30 11:37:45 +0200 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 256 seconds) |
| 2024-04-30 11:43:49 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 11:44:49 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-04-30 11:46:14 +0200 | demon-cat | (~demon-cat@82-132-225-207.dab.02.net) |
| 2024-04-30 11:46:56 +0200 | tolt | (~weechat-h@li219-154.members.linode.com) |
| 2024-04-30 11:47:03 +0200 | chele | (~chele@user/chele) |
| 2024-04-30 11:47:42 +0200 | danza | (~francesco@151.57.154.79) (Ping timeout: 255 seconds) |
| 2024-04-30 11:48:59 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:2128:605:71c4:66a4) (Ping timeout: 260 seconds) |
| 2024-04-30 11:49:21 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 11:51:35 +0200 | AlexNoo | (~AlexNoo@94.233.241.102) (Ping timeout: 245 seconds) |
| 2024-04-30 11:52:00 +0200 | danza | (~francesco@151.57.154.79) |
| 2024-04-30 11:52:11 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Ping timeout: 264 seconds) |
| 2024-04-30 11:55:10 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 260 seconds) |
| 2024-04-30 11:55:36 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-04-30 11:56:05 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 272 seconds) |
| 2024-04-30 12:05:07 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) |
| 2024-04-30 12:06:08 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-04-30 12:08:39 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 12:12:07 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-04-30 12:12:35 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-04-30 12:13:40 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 245 seconds) |
| 2024-04-30 12:14:16 +0200 | danza | (~francesco@151.57.154.79) (Remote host closed the connection) |
| 2024-04-30 12:14:38 +0200 | danza | (~francesco@151.57.154.79) |
| 2024-04-30 12:17:21 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.1.1) |
| 2024-04-30 12:19:39 +0200 | danza | (~francesco@151.57.154.79) (Ping timeout: 255 seconds) |
| 2024-04-30 12:20:07 +0200 | ski | ski_ |
| 2024-04-30 12:20:20 +0200 | mwnaylor | (~user@2601:5cf:837e:2bb0::f472) (Ping timeout: 245 seconds) |
| 2024-04-30 12:20:22 +0200 | Guest27 | (~Guest27@50.47.204.13) (Quit: Client closed) |
| 2024-04-30 12:20:54 +0200 | ski | (~ski@remote11.chalmers.se) |
| 2024-04-30 12:25:36 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 260 seconds) |
| 2024-04-30 12:26:59 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 264 seconds) |
| 2024-04-30 12:38:16 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2024-04-30 12:41:55 +0200 | <probie> | Does anyone have strong opinions where test data should go? Should it go under /test and coexist with source files, or should it live somewhere else? |
| 2024-04-30 12:43:21 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 12:48:26 +0200 | Square3 | (~Square4@user/square) |
| 2024-04-30 12:49:52 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 12:50:35 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-04-30 12:51:10 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 255 seconds) |
| 2024-04-30 12:53:31 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-04-30 12:54:57 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 12:58:10 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
| 2024-04-30 12:59:05 +0200 | demon-cat | (~demon-cat@82-132-225-207.dab.02.net) (Read error: Connection reset by peer) |
| 2024-04-30 12:59:08 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-30 12:59:26 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2024-04-30 12:59:55 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 260 seconds) |
| 2024-04-30 13:00:53 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-04-30 13:08:49 +0200 | jorj | (~jorj@user/jorj) (Quit: jorj) |
| 2024-04-30 13:09:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-30 13:09:48 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 252 seconds) |
| 2024-04-30 13:10:29 +0200 | euleritian | (~euleritia@dynamic-176-006-191-139.176.6.pool.telefonica.de) |
| 2024-04-30 13:12:04 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 13:12:43 +0200 | <[exa]> | probie: tbh best to have them generated with some program in test/ because it gives others a chance to generate harsher test data |
| 2024-04-30 13:15:04 +0200 | <[exa]> | but other than that good question, I only see cabal specifying the actual data files (like the ones that would get installed and sourced with `getDataFileName` |
| 2024-04-30 13:16:21 +0200 | mima | (~mmh@aftr-62-216-211-48.dynamic.mnet-online.de) (Ping timeout: 256 seconds) |
| 2024-04-30 13:18:25 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 246 seconds) |
| 2024-04-30 13:19:19 +0200 | euleritian | (~euleritia@dynamic-176-006-191-139.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-30 13:19:38 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 13:20:03 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-30 13:34:50 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Quit: Gateway shutdown) |
| 2024-04-30 13:38:23 +0200 | byte | (~byte@149.28.222.189) (Ping timeout: 264 seconds) |
| 2024-04-30 13:39:35 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-04-30 13:41:23 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 264 seconds) |
| 2024-04-30 13:41:41 +0200 | euleritian | (~euleritia@dynamic-176-006-191-139.176.6.pool.telefonica.de) |
| 2024-04-30 13:42:13 +0200 | byte | (~byte@149.28.222.189) |
| 2024-04-30 13:46:59 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 13:54:27 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:2128:605:71c4:66a4) |
| 2024-04-30 13:58:29 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 240 seconds) |
| 2024-04-30 13:59:09 +0200 | <haskellbridge> | <maralorn> Dear Lens experts: Can you please tell me how to implement an indexedAdjoin for indexedtraversals in the lens library? I thought maybe it isn’t possible, but optics has iadjoin and I also see no reason for it to be impossible. |
| 2024-04-30 14:01:10 +0200 | <haskellbridge> | <maralorn> Huh, maybe I can just copy the implementation from optics. It seems to go via van Laarhoven lenses anyway. |
| 2024-04-30 14:01:49 +0200 | zetef | (~quassel@2a02:2f00:5202:1200:2128:605:71c4:66a4) (Ping timeout: 256 seconds) |
| 2024-04-30 14:08:10 +0200 | euleritian | (~euleritia@dynamic-176-006-191-139.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-30 14:09:23 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Ping timeout: 268 seconds) |
| 2024-04-30 14:09:57 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 14:12:33 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 14:16:40 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 260 seconds) |
| 2024-04-30 14:16:41 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 14:17:10 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2024-04-30 14:17:50 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 245 seconds) |
| 2024-04-30 14:18:23 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-04-30 14:19:35 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2024-04-30 14:21:33 +0200 | danza | (~francesco@151.57.205.242) |
| 2024-04-30 14:22:38 +0200 | <Axman6> | what're the types you're looking for? |
| 2024-04-30 14:23:35 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1) |
| 2024-04-30 14:24:08 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-04-30 14:24:58 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 260 seconds) |
| 2024-04-30 14:25:22 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-04-30 14:26:32 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) |
| 2024-04-30 14:26:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-30 14:30:10 +0200 | <haskellbridge> | <maralorn> Axman6: IndexedTraversal' i s a -> IndexedTraversal' i s a -> IndexedTraversal' i s a? |
| 2024-04-30 14:31:19 +0200 | <ncf> | maybe you can start by defining an indexed lensProduct and then mimic the definition from Control.Lens.Unsound? |
| 2024-04-30 14:35:05 +0200 | AlexNoo | (~AlexNoo@94.233.240.47) |
| 2024-04-30 14:41:23 +0200 | <haskellbridge> | <maralorn> I think I got something. |
| 2024-04-30 14:41:35 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-04-30 14:41:45 +0200 | <haskellbridge> | <maralorn> iadjoin tv1 tv2 = lensProduct (partsOf (tv1 . withIndex)) (partsOf (tv2 . withIndex)) . both . each . itraversed |
| 2024-04-30 14:43:20 +0200 | <ncf> | heh, i guess that works |
| 2024-04-30 14:47:00 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 268 seconds) |
| 2024-04-30 14:47:11 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 14:48:37 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 14:49:07 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-04-30 14:51:46 +0200 | mima | (~mmh@dhcp-138-246-3-52.dynamic.eduroam.mwn.de) |
| 2024-04-30 14:54:29 +0200 | AlexNoo | (~AlexNoo@94.233.240.47) (Quit: Leaving) |
| 2024-04-30 14:54:54 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 14:55:06 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 14:55:46 +0200 | acidjnk | (~acidjnk@p200300d6e714dc3178eb6b7df1157d0e.dip0.t-ipconnect.de) |
| 2024-04-30 15:02:33 +0200 | Pixi` | (~Pixi@user/pixi) |
| 2024-04-30 15:05:08 +0200 | danza | (~francesco@151.57.205.242) (Read error: Connection reset by peer) |
| 2024-04-30 15:06:24 +0200 | Pixi | (~Pixi@user/pixi) (Ping timeout: 252 seconds) |
| 2024-04-30 15:07:45 +0200 | Rodney_ | MinceR |
| 2024-04-30 15:08:15 +0200 | MinceR | Guest4005 |
| 2024-04-30 15:08:59 +0200 | Guest4005 | Rodney_ |
| 2024-04-30 15:11:25 +0200 | danza | (~francesco@151.57.187.43) |
| 2024-04-30 15:20:16 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 15:23:03 +0200 | AlexNoo | (~AlexNoo@94.233.240.47) |
| 2024-04-30 15:27:40 +0200 | AlexZenon | (~alzenon@94.233.240.47) |
| 2024-04-30 15:29:43 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 260 seconds) |
| 2024-04-30 15:30:03 +0200 | danza_ | (~francesco@151.43.202.238) |
| 2024-04-30 15:30:30 +0200 | danza | (~francesco@151.57.187.43) (Read error: Connection reset by peer) |
| 2024-04-30 15:30:51 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-30 15:35:23 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-04-30 15:36:24 +0200 | euleritian | (~euleritia@dynamic-176-001-019-076.176.1.pool.telefonica.de) |
| 2024-04-30 15:46:48 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2024-04-30 15:49:19 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 15:51:40 +0200 | yin | (~yin@user/zero) (Ping timeout: 256 seconds) |
| 2024-04-30 15:53:07 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 15:59:52 +0200 | michalz | (~michalz@185.246.207.193) (Remote host closed the connection) |
| 2024-04-30 16:00:09 +0200 | michalz | (~michalz@185.246.207.201) |
| 2024-04-30 16:00:33 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 272 seconds) |
| 2024-04-30 16:01:14 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 16:01:39 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1) |
| 2024-04-30 16:03:12 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 16:12:21 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2024-04-30 16:17:53 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-30 16:18:55 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in) |
| 2024-04-30 16:25:51 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 16:30:19 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 255 seconds) |
| 2024-04-30 16:30:29 +0200 | euleritian | (~euleritia@dynamic-176-001-019-076.176.1.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-30 16:31:00 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 16:31:40 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 16:32:00 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 245 seconds) |
| 2024-04-30 16:39:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-30 16:46:30 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 252 seconds) |
| 2024-04-30 16:48:09 +0200 | mima | (~mmh@dhcp-138-246-3-52.dynamic.eduroam.mwn.de) (Ping timeout: 252 seconds) |
| 2024-04-30 16:48:48 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) (Ping timeout: 268 seconds) |
| 2024-04-30 16:55:33 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-04-30 17:04:10 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 17:08:05 +0200 | xff0x | (~xff0x@softbank219059019218.bbtec.net) (Ping timeout: 240 seconds) |
| 2024-04-30 17:08:29 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-04-30 17:08:43 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Read error: Connection reset by peer) |
| 2024-04-30 17:11:04 +0200 | mzschr | (~mzschr@2a07-a880-4603-1035-18b5-1e9f-f698-63a6.pool6.ovpn.com) |
| 2024-04-30 17:11:48 +0200 | shapr | (~user@c-24-218-186-89.hsd1.ma.comcast.net) |
| 2024-04-30 17:14:43 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-04-30 17:15:07 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Read error: Connection reset by peer) |
| 2024-04-30 17:15:12 +0200 | famubu | (~julinuser@user/famubu) (Quit: leaving) |
| 2024-04-30 17:21:11 +0200 | danza_ | danza |
| 2024-04-30 17:21:30 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-04-30 17:29:25 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 17:30:31 +0200 | gorignak | (~gorignak@user/gorignak) (Quit: quit) |
| 2024-04-30 17:32:39 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 17:39:29 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2024-04-30 17:40:16 +0200 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2024-04-30 17:40:28 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 256 seconds) |
| 2024-04-30 17:47:25 +0200 | barak | (~barak@2a0d:6fc2:68c1:7200:3cf2:a87d:a02b:3e21) |
| 2024-04-30 17:49:34 +0200 | nschoe | (~nschoe@2a01:e0a:8e:a190:f3a1:c501:e8bd:2571) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-30 17:49:51 +0200 | nschoe | (~nschoe@2a01:e0a:8e:a190:6f57:1144:3b82:7ce1) |
| 2024-04-30 17:50:11 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2024-04-30 17:50:47 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-04-30 17:52:02 +0200 | zmt01 | (~zmt00@user/zmt00) |
| 2024-04-30 17:52:11 +0200 | lol_ | (~lol@2603:3016:1e01:b940:e453:9e02:8346:816a) |
| 2024-04-30 17:52:55 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-04-30 17:53:14 +0200 | yin | (~yin@user/zero) (Ping timeout: 268 seconds) |
| 2024-04-30 17:53:19 +0200 | dagit9841 | (~dagit@2001:558:6025:38:71c6:9d58:7252:8976) |
| 2024-04-30 17:53:42 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 17:53:55 +0200 | yandere | (sid467876@id-467876.ilkley.irccloud.com) (Ping timeout: 260 seconds) |
| 2024-04-30 17:54:34 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 17:54:51 +0200 | Pozyomka | (~pyon@user/pyon) (Ping timeout: 260 seconds) |
| 2024-04-30 17:55:19 +0200 | swamp_ | (~zmt00@user/zmt00) (Ping timeout: 260 seconds) |
| 2024-04-30 17:55:24 +0200 | dagit | (~dagit@2001:558:6025:38:71c6:9d58:7252:8976) (Remote host closed the connection) |
| 2024-04-30 17:55:27 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 17:55:47 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b940:2575:1903:5fc2:ed7c) (Ping timeout: 260 seconds) |
| 2024-04-30 17:56:36 +0200 | Pozyomka | (~pyon@user/pyon) |
| 2024-04-30 17:57:17 +0200 | Aleksejs | (~Aleksejs@107.170.21.106) (Ping timeout: 240 seconds) |
| 2024-04-30 17:58:07 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 260 seconds) |
| 2024-04-30 17:58:30 +0200 | yandere | (sid467876@id-467876.ilkley.irccloud.com) |
| 2024-04-30 18:00:52 +0200 | thaumavorio | (~thaumavor@thaumavor.io) (Ping timeout: 256 seconds) |
| 2024-04-30 18:03:27 +0200 | mikess | (~mikess@user/mikess) |
| 2024-04-30 18:05:26 +0200 | <shapr> | @quote |
| 2024-04-30 18:05:26 +0200 | <lambdabot> | Ezla says: Why does Haskell need so many thunks? |
| 2024-04-30 18:07:25 +0200 | thaumavorio | (~thaumavor@thaumavor.io) |
| 2024-04-30 18:07:30 +0200 | xal | (~xal@mx1.xal.systems) (Quit: No Ping reply in 180 seconds.) |
| 2024-04-30 18:08:41 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-04-30 18:08:45 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-30 18:09:39 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 18:10:40 +0200 | Aleksejs | (~Aleksejs@107.170.21.106) |
| 2024-04-30 18:14:40 +0200 | <danza> | @quote again |
| 2024-04-30 18:14:41 +0200 | <lambdabot> | Baughn says: From my point of view, anyone who understands everything ghc can do is /scary/. I'm sure that will change once I reach that level myself, but then again, there's also the possibility |
| 2024-04-30 18:14:41 +0200 | <lambdabot> | that I'll be in a permanent state of autophobia. |
| 2024-04-30 18:15:06 +0200 | <danza> | :D |
| 2024-04-30 18:18:07 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 18:19:26 +0200 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) |
| 2024-04-30 18:20:04 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Quit: quit) |
| 2024-04-30 18:21:24 +0200 | mima | (~mmh@dhcp-138-246-3-42.dynamic.eduroam.mwn.de) |
| 2024-04-30 18:21:46 +0200 | <yin> | TIL about autophobia |
| 2024-04-30 18:22:02 +0200 | motherfsck | (~motherfsc@user/motherfsck) |
| 2024-04-30 18:28:01 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-30 18:29:18 +0200 | destituion | (~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1) (Read error: Connection reset by peer) |
| 2024-04-30 18:29:20 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-04-30 18:29:35 +0200 | destituion | (~destituio@85.221.111.174) |
| 2024-04-30 18:31:56 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-04-30 18:33:44 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 256 seconds) |
| 2024-04-30 18:34:49 +0200 | <dminuoso> | Haskell - where indenting a type signature lifts.. it well to the value level. |
| 2024-04-30 18:35:12 +0200 | <dminuoso> | Not just that, but in my specific code example, it altered the code, and type checked too. |
| 2024-04-30 18:35:32 +0200 | <dminuoso> | What a strange experience. |
| 2024-04-30 18:36:02 +0200 | <danza> | sounds like consistent design... |
| 2024-04-30 18:36:28 +0200 | <yin> | dminuoso: how? |
| 2024-04-30 18:36:34 +0200 | <danza> | but what you mean by "it altered the code"? |
| 2024-04-30 18:36:37 +0200 | dsrt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2024-04-30 18:40:40 +0200 | <yin> | i am not a fan of the layout rules but i can't picture such a case |
| 2024-04-30 18:42:05 +0200 | mima | (~mmh@dhcp-138-246-3-42.dynamic.eduroam.mwn.de) (Ping timeout: 240 seconds) |
| 2024-04-30 18:43:05 +0200 | <dminuoso> | Oh yeah let me try and derive a motivating example that I can share |
| 2024-04-30 18:47:01 +0200 | <dminuoso> | Okay this is a bit more elaborate, but basically I had a polyvariadic typeclass trick going on, and indending the subsequent top level type signature placed it as an argument into the last (nested) where binding |
| 2024-04-30 18:50:19 +0200 | <dminuoso> | Though its conceivable that bindings of type `(t -> t) -> t -> t` (without an explicit type signature) could fall into this trap as well |
| 2024-04-30 18:50:19 +0200 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-04-30 18:50:41 +0200 | <dminuoso> | Or `t -> t` even, stuff of that shape |
| 2024-04-30 18:51:33 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2024-04-30 18:51:40 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 18:57:24 +0200 | Square | (~Square@user/square) |
| 2024-04-30 18:57:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-30 18:57:52 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) (Quit: Lost terminal) |
| 2024-04-30 19:00:08 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-04-30 19:02:42 +0200 | ft | (~ft@p3e9bc1bf.dip0.t-ipconnect.de) |
| 2024-04-30 19:02:42 +0200 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-04-30 19:02:50 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-30 19:08:49 +0200 | yin | (~yin@user/zero) (Ping timeout: 256 seconds) |
| 2024-04-30 19:10:21 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 19:15:13 +0200 | <yin> | ah i see |
| 2024-04-30 19:15:26 +0200 | <yin> | multiline signatures i'm guessing |
| 2024-04-30 19:20:35 +0200 | <yin> | or maybe i'm misunderstanding |
| 2024-04-30 19:23:58 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 19:24:35 +0200 | danza | (~francesco@151.43.202.238) (Ping timeout: 264 seconds) |
| 2024-04-30 19:28:05 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 240 seconds) |
| 2024-04-30 19:31:14 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-04-30 19:32:25 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 245 seconds) |
| 2024-04-30 19:35:52 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-04-30 19:42:13 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-30 19:43:35 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 19:45:24 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-04-30 19:45:24 +0200 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-04-30 19:45:50 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-04-30 19:48:28 +0200 | destituion | (~destituio@85.221.111.174) (Ping timeout: 260 seconds) |
| 2024-04-30 19:48:33 +0200 | raym | (~ray@user/raym) (Ping timeout: 268 seconds) |
| 2024-04-30 19:51:34 +0200 | glguy | (g@libera/staff/glguy) (Quit: Quit) |
| 2024-04-30 19:52:49 +0200 | glguy | (g@libera/staff/glguy) |
| 2024-04-30 19:55:07 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-04-30 19:55:37 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-04-30 19:56:13 +0200 | destituion | (~destituio@2a02:2121:340:2456:fffe:d0f:7737:dd1) |
| 2024-04-30 19:57:35 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 264 seconds) |
| 2024-04-30 19:58:17 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-04-30 19:59:02 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-04-30 19:59:02 +0200 | mzschr | (~mzschr@2a07-a880-4603-1035-18b5-1e9f-f698-63a6.pool6.ovpn.com) (Quit: Client closed) |
| 2024-04-30 20:02:33 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-04-30 20:09:39 +0200 | <justsomeguy> | Can someone help me understand how fmap can be implemented in terms of (\f xs -> xs >>= return . f)? |
| 2024-04-30 20:10:22 +0200 | <monochrom> | I don't understand the question. You already have an implementation right there. :) |
| 2024-04-30 20:10:49 +0200 | <monochrom> | But if the question is why it is correct, then the answer is it is one of the monad laws. |
| 2024-04-30 20:11:04 +0200 | <geekosaur> | in category theory >>= is join + fmap. by applying an identity to one of those operations, you can reconstruct the other; so `return`/`pure` lets you recover `fmap` and `id` lets you recover `join` |
| 2024-04-30 20:11:46 +0200 | <geekosaur> | (well, in CT >>= doesn't exist; more correctly, that's how you would define it in CT) |
| 2024-04-30 20:12:17 +0200 | <yin> | something something lawful instances |
| 2024-04-30 20:12:45 +0200 | <geekosaur> | the monad laws document the relationship that makes this work |
| 2024-04-30 20:12:54 +0200 | <c_wraith> | I'm pretty sure that law is free if the other laws are followed. |
| 2024-04-30 20:13:01 +0200 | <int-e> | join (fmap (return . f) xs) = join (fmap return (fmap f xs)) = fmap f xs |
| 2024-04-30 20:16:41 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 20:21:14 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (Read error: Connection reset by peer) |
| 2024-04-30 20:21:27 +0200 | <justsomeguy> | I'm just thinking out loud here.. Since return wraps the argument to f, then f must operate on an unwrapped type. |
| 2024-04-30 20:21:37 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2024-04-30 20:22:41 +0200 | <monochrom> | Oh, how it type-checks? That's much easier. :) |
| 2024-04-30 20:24:03 +0200 | philopsos | (~caecilius@user/philopsos) |
| 2024-04-30 20:26:00 +0200 | <yin> | > pure . pure . pure $ 7 :: Maybe [Maybe Int] -- justsomeguy |
| 2024-04-30 20:26:01 +0200 | <lambdabot> | Just [Just 7] |
| 2024-04-30 20:26:51 +0200 | <monochrom> | Aw, that is not as fun as Maybe [IO Int] :) |
| 2024-04-30 20:28:01 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 268 seconds) |
| 2024-04-30 20:29:10 +0200 | <EvanR> | :t (Just 'c' >>=) |
| 2024-04-30 20:29:11 +0200 | <lambdabot> | (Char -> Maybe b) -> Maybe b |
| 2024-04-30 20:29:20 +0200 | <EvanR> | :t (return . ord) |
| 2024-04-30 20:29:21 +0200 | <lambdabot> | Monad m => Char -> m Int |
| 2024-04-30 20:30:09 +0200 | <EvanR> | :t (Just 'c' >>=) (return . ord) |
| 2024-04-30 20:30:10 +0200 | <lambdabot> | Maybe Int |
| 2024-04-30 20:30:41 +0200 | <EvanR> | square peg square hole |
| 2024-04-30 20:31:36 +0200 | <yin> | MTL: https://www.youtube.com/watch?v=6pDH66X3ClA |
| 2024-04-30 20:32:37 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2024-04-30 20:34:19 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-04-30 20:34:24 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-04-30 20:40:37 +0200 | <mauke> | return wraps the result of f |
| 2024-04-30 20:43:00 +0200 | iteratee | (~kyle@162.218.222.207) (Ping timeout: 252 seconds) |
| 2024-04-30 20:47:42 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-04-30 20:49:12 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-04-30 20:54:12 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 20:54:32 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 268 seconds) |
| 2024-04-30 20:55:48 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-04-30 20:56:50 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-04-30 20:58:30 +0200 | TheOneWhoFuncts | (~Thunderbi@14.98.244.193) |
| 2024-04-30 20:58:43 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 260 seconds) |
| 2024-04-30 20:58:43 +0200 | yin | (~yin@user/zero) (Ping timeout: 260 seconds) |
| 2024-04-30 20:59:47 +0200 | TheOneWhoFuncts | (~Thunderbi@14.98.244.193) (Client Quit) |
| 2024-04-30 21:00:35 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 21:02:36 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 21:03:24 +0200 | <tomsmeding> | is t here a compact region like thing that you can add to in parallel? |
| 2024-04-30 21:04:16 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2024-04-30 21:04:17 +0200 | <tomsmeding> | I have a program that, while in its "construction phase", builds up a large data structure in parallel; it's only added to, no part of the data structure can ever be collected by the GC in this program phase |
| 2024-04-30 21:04:28 +0200 | <tomsmeding> | the structure has lots of internal sharing |
| 2024-04-30 21:04:44 +0200 | <tomsmeding> | then in the second phase of the program I consume this entire data structure, and afterwards the GC can collect it |
| 2024-04-30 21:05:23 +0200 | yin | (~yin@user/zero) (Ping timeout: 264 seconds) |
| 2024-04-30 21:05:24 +0200 | <tomsmeding> | as-is, if I don't set the GC nursery size obscenely high (like 4GB), during construction phase the GC repeatedly traverses the whole thing uselessly, and ends up taking >60% of the total program runtime |
| 2024-04-30 21:05:29 +0200 | <tomsmeding> | can I prevent that? |
| 2024-04-30 21:06:22 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-04-30 21:06:33 +0200 | <monochrom> | Does the current compact region already works under parallelism? |
| 2024-04-30 21:06:45 +0200 | <tomsmeding> | `compactAdd` takes a lock on the compact region |
| 2024-04-30 21:06:51 +0200 | <tomsmeding> | so it's not really suitable for me |
| 2024-04-30 21:07:04 +0200 | <tomsmeding> | there's literally an MVar there in the API in `ghc-compact` |
| 2024-04-30 21:07:10 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 21:07:35 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-04-30 21:08:07 +0200 | <tomsmeding> | perhaps this is just something that would be hard to design an API for |
| 2024-04-30 21:08:31 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 256 seconds) |
| 2024-04-30 21:09:09 +0200 | xal | (~xal@mx1.xal.systems) () |
| 2024-04-30 21:09:29 +0200 | <tomsmeding> | I know pretty well from what points this data structure is reachable, so if there was some technique I could use to mark certain GC roots as "don't traverse from here, just assume this live", there's a decent chance I could make that work |
| 2024-04-30 21:10:01 +0200 | <tomsmeding> | but exactly what values are GC roots does not really reflect well to the haskell source world, I guess |
| 2024-04-30 21:10:21 +0200 | <sm> | probie I like to have test code as close to tested code as possible without obscuring the latter too much. These things are in tension, at least with typical tools. Currently I have three tiers: a little bit of doctest code in function haddocks; a bit more HUnit test code at the bottom of each module; and more extensive functional tests under test/* |
| 2024-04-30 21:11:15 +0200 | <sm> | you want the friction of writing and updating tests to be as low as possible, obviously |
| 2024-04-30 21:11:40 +0200 | rvalue- | rvalue |
| 2024-04-30 21:11:45 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-30 21:13:55 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-04-30 21:14:33 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Quit: peterbecich) |
| 2024-04-30 21:14:50 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 21:15:13 +0200 | <mauke> | tomsmeding: if you make a StablePtr to your structure, does that affect GC behavior? |
| 2024-04-30 21:15:41 +0200 | yin | (~yin@user/zero) (Ping timeout: 240 seconds) |
| 2024-04-30 21:15:47 +0200 | <tomsmeding> | mauke: I'm adding to my structure "at the top" all the time, so the root of the data structure changes all the time |
| 2024-04-30 21:15:54 +0200 | <tomsmeding> | so I'd have to create new StablePtrs all the time |
| 2024-04-30 21:15:58 +0200 | <tomsmeding> | would that be a good idea? |
| 2024-04-30 21:16:29 +0200 | <mauke> | honestly, no idea :-) |
| 2024-04-30 21:17:13 +0200 | <tomsmeding> | I think I recall from somewhere that StablePtrs are kept in a list somewhere in the RTS |
| 2024-04-30 21:17:16 +0200 | <tomsmeding> | so you shouldn't make tons of them |
| 2024-04-30 21:17:52 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 21:18:50 +0200 | <mauke> | could make a StablePtr (IORef a), I guess. but I'm not sure if that even does anything |
| 2024-04-30 21:19:23 +0200 | <tomsmeding> | I could try having each thread have its own StablePtr (IORef a) to its "head" of the structure |
| 2024-04-30 21:19:35 +0200 | <tomsmeding> | it's clever, let's see if that does anything |
| 2024-04-30 21:20:45 +0200 | <mauke> | as a last resort, write the whole thing using manually allocated memory :-) |
| 2024-04-30 21:20:47 +0200 | <c_wraith> | Does StablePtr do anything there? my impression was that it just wraps an arbitrary value in a way that lets you send it via a void* in the FFI |
| 2024-04-30 21:21:08 +0200 | <tomsmeding> | > A stable pointer is a reference to a Haskell expression that is guaranteed not to be affected by garbage collection, i.e., it will neither be deallocated nor will the value of the stable pointer itself change during garbage collection |
| 2024-04-30 21:21:39 +0200 | <c_wraith> | (and the mechanism is that it picks a number that can be cast to a void*, then throws it into a hash table in the RTS...) |
| 2024-04-30 21:21:51 +0200 | <tomsmeding> | maybe this would make only the IORef not move, and still make the GC copy the whole data structure every time :) |
| 2024-04-30 21:22:19 +0200 | <tomsmeding> | oh I see |
| 2024-04-30 21:22:32 +0200 | <tomsmeding> | I was deluded by castStablePtrToPtr's existence, but that doesn't return a pointer that actually means anything |
| 2024-04-30 21:22:39 +0200 | <tomsmeding> | yeah no this is unlikely to work |
| 2024-04-30 21:23:03 +0200 | <tomsmeding> | meh and this would be an annoying refactor |
| 2024-04-30 21:23:55 +0200 | <c_wraith> | compact regions really don't help during construction, unless things can be done in phases. |
| 2024-04-30 21:24:18 +0200 | <tomsmeding> | the construction phase of my program frankly does little else than add lots of stuff to this structure |
| 2024-04-30 21:24:30 +0200 | <tomsmeding> | (the structure gets pretty large) |
| 2024-04-30 21:25:08 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) (Quit: Konversation terminated!) |
| 2024-04-30 21:25:15 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-04-30 21:25:20 +0200 | <c_wraith> | is there no way to all to make the data structure constructed from the top down, so that it isn't created until it's consumed? that's the easiest way to control memory use. |
| 2024-04-30 21:25:40 +0200 | <tomsmeding> | unfortunately not |
| 2024-04-30 21:25:46 +0200 | <tomsmeding> | this really must be constructed from the bottom up |
| 2024-04-30 21:26:12 +0200 | <tomsmeding> | (it's a kind of "tape"/"log" of a computation that is performed; the second phase of the program interprets this tape in reverse) |
| 2024-04-30 21:26:23 +0200 | <tomsmeding> | (this is reverse-mode automatic differentiation, in case you're curious) |
| 2024-04-30 21:26:38 +0200 | <c_wraith> | well, then... making the nursery huge isn't terrible. that's why the option exists. |
| 2024-04-30 21:27:22 +0200 | <tomsmeding> | and hope that the GC doesn't trigger too often |
| 2024-04-30 21:27:38 +0200 | <tomsmeding> | unsatisfying but probably the best answer |
| 2024-04-30 21:28:19 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-04-30 21:37:47 +0200 | <monochrom> | I don't think top-down reduces fruitless GC anyway. It just changes data to thunks. |
| 2024-04-30 21:38:05 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-04-30 21:38:07 +0200 | <tomsmeding> | it would reduce the peak heap size a lot |
| 2024-04-30 21:40:24 +0200 | <monochrom> | I wonder if "diff list but for snoc list" helps. |
| 2024-04-30 21:40:29 +0200 | yin | (~yin@user/zero) (Ping timeout: 240 seconds) |
| 2024-04-30 21:41:02 +0200 | <tomsmeding> | if you replace the nodes of the data structure by closures, you don't make the heap size any smaller |
| 2024-04-30 21:41:09 +0200 | <tomsmeding> | you just create indirection |
| 2024-04-30 21:41:25 +0200 | <tomsmeding> | you just get a network of closures with the exact same structure as the original data structure :) |
| 2024-04-30 21:42:46 +0200 | benjaminl | (~benjaminl@user/benjaminl) (Ping timeout: 246 seconds) |
| 2024-04-30 21:42:55 +0200 | <monochrom> | That would be what I said about "just changes data to thunks". |
| 2024-04-30 21:43:26 +0200 | <monochrom> | But changing to thunks can be worthwhile if it enables streaming. |
| 2024-04-30 21:46:22 +0200 | <EvanR> | data is definitely data while closures might contain a bunch of closures, or thunks. So closures are the better bet xD |
| 2024-04-30 21:46:33 +0200 | <tomsmeding> | monochrom: I'm not exactly sure what you mean; the problem that I have is that the GC uselessly traverses my huge data structure that is live anyway |
| 2024-04-30 21:47:01 +0200 | <tomsmeding> | I don't see how making things thunks, or doing the difference-list thing, etc. helps there |
| 2024-04-30 21:49:04 +0200 | <int-e> | sometimes laziness makes the live data smaller |
| 2024-04-30 21:49:21 +0200 | <int-e> | presumably this is not one of those cases |
| 2024-04-30 21:49:31 +0200 | <tomsmeding> | I mean, the whole structure _is_ lazy |
| 2024-04-30 21:49:40 +0200 | <tomsmeding> | so it's all thunks anyway |
| 2024-04-30 21:49:44 +0200 | <tomsmeding> | maybe I should try changing that |
| 2024-04-30 21:49:45 +0200 | <monochrom> | In the sense that "[m..n] = m : [m+1 .. n]" is a thunk that generates a little data and a new thunk, and although you still have to GC, it fruitfully collects dead data, and the surviving new thunk is still small, so the overall memory footprint stays small.. |
| 2024-04-30 21:50:03 +0200 | <tomsmeding> | monochrom: there is no dead data in my application |
| 2024-04-30 21:50:06 +0200 | <tomsmeding> | at least not in this structure |
| 2024-04-30 21:50:10 +0200 | <monochrom> | :( |
| 2024-04-30 21:50:18 +0200 | <tomsmeding> | everything that I add to it stays until the second phase of the program |
| 2024-04-30 21:50:31 +0200 | <tomsmeding> | that's why I want the GC to ignore this thing, it's absolutely pointless to traverse it! |
| 2024-04-30 21:51:15 +0200 | <EvanR> | rewrite it in rust |
| 2024-04-30 21:51:41 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 240 seconds) |
| 2024-04-30 21:51:57 +0200 | <tomsmeding> | my problem is, this is a reference implementation for a paper |
| 2024-04-30 21:52:04 +0200 | <mauke> | https://marcopeg.com/content/images/size/w2000/2021/11/everything-not-saved-will-be-lost.png |
| 2024-04-30 21:52:24 +0200 | <EvanR> | lol |
| 2024-04-30 21:52:26 +0200 | <tomsmeding> | the last optimisation step for the algorithm in the paper is to make the whole thing imperative, which for the implementation would mean that this big data structure just becomes a huge unboxable array |
| 2024-04-30 21:52:37 +0200 | <tomsmeding> | destroying all problems in one fell swoop |
| 2024-04-30 21:52:57 +0200 | <tomsmeding> | but I don't want to implement that version because then, in context of the paper, the implementation is completely uninteresting because it's something that already exists |
| 2024-04-30 21:53:05 +0200 | <tomsmeding> | but >.< |
| 2024-04-30 21:53:29 +0200 | benjaminl | (~benjaminl@user/benjaminl) |
| 2024-04-30 21:53:35 +0200 | <mauke> | by which I mean that under a copying collector, anything not traversed (and copied) will be collected implicitly |
| 2024-04-30 21:54:24 +0200 | <tomsmeding> | mauke: that's a neat quote for that |
| 2024-04-30 21:54:41 +0200 | <EvanR> | worrying about the performance of adding to a compact region seems like, |
| 2024-04-30 21:54:58 +0200 | <tomsmeding> | my structure doesn't even have any cycles, you could reference count GC it and all would be good! |
| 2024-04-30 21:55:00 +0200 | <EvanR> | you already know that's 1. the slow part and 2. going to be too slow |
| 2024-04-30 21:55:03 +0200 | <monochrom> | Um ideally a paper is not supposed to contrive things just for the sake of "interesting" and "new". At least, one can hope... |
| 2024-04-30 21:55:32 +0200 | <tomsmeding> | monochrom: the point of the paper is that it optimises a really crappy algorithm from theory to a known fast thing |
| 2024-04-30 21:55:53 +0200 | <tomsmeding> | the reference implementation is there to show that the essence of the algorithm that we get halfway is not nonsense |
| 2024-04-30 21:56:09 +0200 | <tomsmeding> | I could also just not write the implementation and the paper would not be much weaker |
| 2024-04-30 21:56:28 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-04-30 21:56:31 +0200 | <monochrom> | OK, but the reference implementation is allowed to be slow. :) |
| 2024-04-30 21:56:32 +0200 | <tomsmeding> | it would just make it harder to believe that the claims we're making about how the algorithms work actually work in practice |
| 2024-04-30 21:56:36 +0200 | <int-e> | does -G 3 ever help with this kind of repeated GC? |
| 2024-04-30 21:56:53 +0200 | <int-e> | (RTS option to set the number of generations) |
| 2024-04-30 21:58:12 +0200 | <mauke> | https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-options-to-cont… |
| 2024-04-30 21:59:14 +0200 | <tomsmeding> | int-e: at least for the program in question, -G3 doesn't help |
| 2024-04-30 22:00:11 +0200 | <int-e> | Increasing -F is also a possibility I guess, but it feels like a rather blunt tool. |
| 2024-04-30 22:07:59 +0200 | <mauke> | > 2024 `div` 88 |
| 2024-04-30 22:08:00 +0200 | <lambdabot> | 23 |
| 2024-04-30 22:15:17 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-04-30 22:17:15 +0200 | mwnaylor | (~user@2601:5cf:837e:2bb0::f472) |
| 2024-04-30 22:18:04 +0200 | <tomsmeding> | > 23 * 88 |
| 2024-04-30 22:18:05 +0200 | <lambdabot> | 2024 |
| 2024-04-30 22:20:07 +0200 | <EvanR> | > 17 & 119 |
| 2024-04-30 22:20:08 +0200 | <lambdabot> | error: |
| 2024-04-30 22:20:08 +0200 | <lambdabot> | • Could not deduce (Num a0) |
| 2024-04-30 22:20:08 +0200 | <lambdabot> | from the context: (Num a, Num (a -> b)) |
| 2024-04-30 22:20:12 +0200 | <EvanR> | > 17 * 119 |
| 2024-04-30 22:20:14 +0200 | <lambdabot> | 2023 |
| 2024-04-30 22:20:22 +0200 | <EvanR> | must be hotter than I thought outside today |
| 2024-04-30 22:20:42 +0200 | tomsmeding | is confused |
| 2024-04-30 22:21:38 +0200 | <EvanR> | I thought we were doing prime factors of calendar years |
| 2024-04-30 22:22:02 +0200 | <tomsmeding> | 1. 88 is not prime, 2. what does the temperature have to do with prime factors |
| 2024-04-30 22:22:26 +0200 | <EvanR> | 23... 17... which are also reasonable temperatures C |
| 2024-04-30 22:23:13 +0200 | <mauke> | > 17 .&. 119 |
| 2024-04-30 22:23:14 +0200 | <lambdabot> | 17 |
| 2024-04-30 22:23:34 +0200 | <tomsmeding> | if the other number was supposed to be fahrenheit then 88 is also kind of on the hot side :p |
| 2024-04-30 22:23:58 +0200 | <EvanR> | 23 C times 88 F equals |
| 2024-04-30 22:24:09 +0200 | <EvanR> | 2024 CF |
| 2024-04-30 22:24:29 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 22:24:44 +0200 | philopsos | (~caecilius@user/philopsos) (Ping timeout: 252 seconds) |
| 2024-04-30 22:24:52 +0200 | <mauke> | we did it. we solved coldfusion |
| 2024-04-30 22:25:35 +0200 | <EvanR> | that would be cool |
| 2024-04-30 22:26:11 +0200 | <monochrom> | cool fusion |
| 2024-04-30 22:26:34 +0200 | <tomsmeding> | > factor 2024 |
| 2024-04-30 22:26:35 +0200 | <lambdabot> | [2,2,2,11,23] |
| 2024-04-30 22:27:12 +0200 | <EvanR> | :t factor |
| 2024-04-30 22:27:13 +0200 | <lambdabot> | Integral a => a -> [a] |
| 2024-04-30 22:27:29 +0200 | mreh | (~matthew@host86-160-168-68.range86-160.btcentralplus.com) (Ping timeout: 252 seconds) |
| 2024-04-30 22:29:09 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 252 seconds) |
| 2024-04-30 22:31:11 +0200 | <ncf> | is there a factoring :: Iso' a [a] |
| 2024-04-30 22:32:09 +0200 | <ncf> | or Integral a => Iso' a (Set a) |
| 2024-04-30 22:32:27 +0200 | <ncf> | well, still needs type level primes |
| 2024-04-30 22:33:01 +0200 | <mwnaylor> | ghc.SlackBuild fails during document phase. https://pastebin.com/n6HLzFwa |
| 2024-04-30 22:36:57 +0200 | <int-e> | > let c n 0 = 1; c n k = c (n-1) (k-1) * n `div` k in c 24 3 |
| 2024-04-30 22:36:58 +0200 | <lambdabot> | 2024 |
| 2024-04-30 22:44:05 +0200 | <xerox> | > let f n = n*(n+1)*(n+2)`div`6 in f 22 |
| 2024-04-30 22:44:07 +0200 | <lambdabot> | 2024 |
| 2024-04-30 22:44:15 +0200 | <dminuoso> | I am so tempted to take Haxl and write a mail spam classification engine with it... |
| 2024-04-30 22:44:45 +0200 | <monochrom> | I think that's the right thing to do :) |
| 2024-04-30 22:45:11 +0200 | <ncf> | @let fromP p = withPrism (\f g -> iso (fromRight undefined . g) f) |
| 2024-04-30 22:45:12 +0200 | <lambdabot> | /sandbox/tmp/.L.hs:165:22: error: |
| 2024-04-30 22:45:12 +0200 | <lambdabot> | • Couldn't match expected type ‘Control.Lens.Internal.Prism.Market |
| 2024-04-30 22:45:12 +0200 | <lambdabot> | a b s (Identity t)’ |
| 2024-04-30 22:45:13 +0200 | <dminuoso> | Now is it. It occurs to me, that if I really wanted this to succeed, I would eventually want people to contribute. |
| 2024-04-30 22:45:27 +0200 | <dminuoso> | The overlap between mail operators and Haskell is small enough as it is. |
| 2024-04-30 22:45:40 +0200 | <dminuoso> | Facebook gets away with this by just having money to hire people. |
| 2024-04-30 22:45:41 +0200 | <ncf> | @let fromP p = withPrism p (\f g -> iso (fromRight undefined . g) f) |
| 2024-04-30 22:45:42 +0200 | <lambdabot> | Defined. |
| 2024-04-30 22:45:51 +0200 | <monochrom> | Right, I was ignoring who-has-time. |
| 2024-04-30 22:45:57 +0200 | <ncf> | > 2024 & fromP _Show %~ reverse |
| 2024-04-30 22:45:58 +0200 | <lambdabot> | error: |
| 2024-04-30 22:45:58 +0200 | <lambdabot> | • No instance for (Num String) arising from the literal ‘2024’ |
| 2024-04-30 22:45:58 +0200 | <lambdabot> | • In the first argument of ‘(&)’, namely ‘2024’ |
| 2024-04-30 22:46:17 +0200 | <monochrom> | Generally, no one has time to do the right things anyway. :) |
| 2024-04-30 22:46:30 +0200 | <dminuoso> | Does that make them "the right things", then? |
| 2024-04-30 22:46:38 +0200 | <dminuoso> | Or are they just ill-conveiced notions of "right things"? |
| 2024-04-30 22:46:45 +0200 | <tomsmeding> | if you have enough money you can hire a phd to do the right things |
| 2024-04-30 22:47:07 +0200 | <dminuoso> | Oh I do have ideas for that. |
| 2024-04-30 22:47:17 +0200 | <dminuoso> | A Haskell-to-P4 compiler, that would be awesome! |
| 2024-04-30 22:47:25 +0200 | <dminuoso> | tomsmeding: Got any plans? :-) |
| 2024-04-30 22:47:25 +0200 | <monochrom> | Naw I don't believe "no one has time => right thing". |
| 2024-04-30 22:47:31 +0200 | <ncf> | oh god damnit why are the arguments flipped |
| 2024-04-30 22:47:46 +0200 | <ncf> | @let fromP p = withPrism p (\f g -> iso f (fromRight undefined . g)) |
| 2024-04-30 22:47:47 +0200 | <lambdabot> | /sandbox/tmp/.L.hs:166:1: error: [-Woverlapping-patterns, -Werror=overlappin... |
| 2024-04-30 22:47:47 +0200 | <lambdabot> | Pattern match is redundant |
| 2024-04-30 22:47:47 +0200 | <lambdabot> | In an equation for ‘fromP’: fromP p = ... |
| 2024-04-30 22:47:54 +0200 | <monochrom> | Sorry, what is P4? |
| 2024-04-30 22:47:54 +0200 | <ncf> | @unlet fromP |
| 2024-04-30 22:47:54 +0200 | <lambdabot> | Parse failed: TemplateHaskell language extension is not enabled. Please add ... |
| 2024-04-30 22:47:55 +0200 | <tomsmeding> | dminuoso: I'm already in a phd program, one typically cannot do a phd in the same field twice |
| 2024-04-30 22:48:02 +0200 | <ncf> | @undefine fromP |
| 2024-04-30 22:48:02 +0200 | <lambdabot> | There's currently no way to undefine just one thing. Say @undefine (with no extra words) to undefine everything. |
| 2024-04-30 22:48:09 +0200 | <ncf> | fjldmjfmsdlj |
| 2024-04-30 22:48:10 +0200 | <tomsmeding> | monochrom: DSL for writing software for networking machines |
| 2024-04-30 22:48:13 +0200 | <ncf> | @let fromP' p = withPrism p (\f g -> iso f (fromRight undefined . g)) |
| 2024-04-30 22:48:14 +0200 | <lambdabot> | Defined. |
| 2024-04-30 22:48:20 +0200 | xerox | hugs ncf |
| 2024-04-30 22:48:20 +0200 | <ncf> | > 2024 & fromP' _Show %~ reverse |
| 2024-04-30 22:48:22 +0200 | <lambdabot> | 4202 |
| 2024-04-30 22:48:24 +0200 | <ncf> | hurray |
| 2024-04-30 22:48:37 +0200 | <dminuoso> | monochrom: It is a domain specific language for controlling dataplanes in networking ASICs. |
| 2024-04-30 22:48:51 +0200 | <dminuoso> | Roughly it is to networking ASICs as VHDL/Verilog is to FPGAs. |
| 2024-04-30 22:49:02 +0200 | <monochrom> | dminuoso: Try again with "tomsmeding: Got any postdoc plans?" >:) |
| 2024-04-30 22:49:02 +0200 | <tomsmeding> | but higher level than VHDL, right? |
| 2024-04-30 22:49:14 +0200 | <tomsmeding> | not yet >:D |
| 2024-04-30 22:49:34 +0200 | <dminuoso> | tomsmeding: Not quite higher than VHDL, no. |
