| 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. |
| 2024-04-30 22:50:05 +0200 | <dminuoso> | Or yeah, maybe. |
| 2024-04-30 22:50:22 +0200 | monochrom | is a great consultant on how to get people stuck in academia. |
| 2024-04-30 22:50:38 +0200 | <tomsmeding> | all I know about P4 is what Nate Foster talked about in his keynote at POPL'24 (and ICFP'22, actually) |
| 2024-04-30 22:50:49 +0200 | <tomsmeding> | (dunno why he did the thing twice) |
| 2024-04-30 22:50:54 +0200 | <tomsmeding> | (roughly) |
| 2024-04-30 22:51:25 +0200 | <xerox> | > 45^2 - 1 |
| 2024-04-30 22:51:26 +0200 | <lambdabot> | 2024 |
| 2024-04-30 22:51:28 +0200 | <tomsmeding> | monochrom: if it means I get to do fun things |
| 2024-04-30 22:51:31 +0200 | <dminuoso> | Or maybe a better comparison is: P4 is useful in networking for the same reason that machine code is useful in general purpose computing.b |
| 2024-04-30 22:51:42 +0200 | <dminuoso> | Being able to ship reconfigurable high performance networking equipment is great. |
| 2024-04-30 22:51:53 +0200 | <dminuoso> | And there's plenty of P4 capable targets on the market already. |
| 2024-04-30 22:52:03 +0200 | <dminuoso> | But its incredibly crude and annoying to program them directly |
| 2024-04-30 22:52:18 +0200 | <monochrom> | One time we had a great undergrad student being a great TA and we didn't want to lose them when they graduated. My colleague joked about plans to block their graduation. I was like "that's the most inefficient way. get them into our grad school instead." |
| 2024-04-30 22:52:20 +0200 | <dminuoso> | Pretty much the equivalent of having to write general purpose programs in machine code directly. |
| 2024-04-30 22:53:11 +0200 | causal | (~eric@50.35.88.207) |
| 2024-04-30 22:53:22 +0200 | <tomsmeding> | monochrom: if you have the money for it lying around :) |
| 2024-04-30 22:53:54 +0200 | <dminuoso> | tomsmeding: Oh I dont know about *your* university, but in some fields you can always just turn 100% positions into 50% positions. |
| 2024-04-30 22:54:00 +0200 | <dminuoso> | Same work, half the pay. It's brilliant. |
| 2024-04-30 22:54:15 +0200 | <dminuoso> | Germany lets universities do that. |
| 2024-04-30 22:54:16 +0200 | <tomsmeding> | as in, hire two people for the same money? |
| 2024-04-30 22:54:29 +0200 | <monochrom> | We have the money lying around, as long as the student is really great and therefore deserves it. |
| 2024-04-30 22:54:30 +0200 | <dminuoso> | as in hire two people for the cost of one. |
| 2024-04-30 22:54:44 +0200 | <tomsmeding> | that's a good trick |
| 2024-04-30 22:55:01 +0200 | <tomsmeding> | I wouldn't see that happening very quickly here |
| 2024-04-30 22:55:05 +0200 | <dminuoso> | Of course 50% position does not mean 50% work, it just means 50% pay. :-) |
| 2024-04-30 22:55:09 +0200 | <tomsmeding> | of course |
| 2024-04-30 22:55:42 +0200 | <dminuoso> | Yeah some institutes are really fighting for their livelihoods. |
| 2024-04-30 22:56:19 +0200 | <tomsmeding> | (the result being that we're don't have an abundance of funds) |
| 2024-04-30 22:56:42 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 22:57:02 +0200 | <dminuoso> | In chemistry, biology and biotech its almost the norm to get 50% PhD positions. |
| 2024-04-30 22:57:05 +0200 | <dminuoso> | In Germany. |
| 2024-04-30 22:57:12 +0200 | <tomsmeding> | that's ridiculous |
| 2024-04-30 22:57:17 +0200 | <monochrom> | :( |
| 2024-04-30 22:57:34 +0200 | <tomsmeding> | contract expected to take the same number of calendar years? |
| 2024-04-30 22:57:49 +0200 | <dminuoso> | Of course. |
| 2024-04-30 22:57:56 +0200 | <tomsmeding> | or does germany have the UK etc. model where it's indefinite instead of a fixed time period |
| 2024-04-30 22:57:56 +0200 | <monochrom> | Then again "it's not personal, it's just good business". |
| 2024-04-30 22:58:25 +0200 | <dminuoso> | tomsmeding: No, science is made intentionally harsh to sort out weak people. |
| 2024-04-30 22:58:45 +0200 | <dminuoso> | tomsmeding: So there's an upper limit to how many years you can work for a university. I think it's like 10 years total. |
| 2024-04-30 22:59:05 +0200 | <tomsmeding> | how do full professors fit into that? |
| 2024-04-30 22:59:14 +0200 | <tomsmeding> | surely they stay on longer |
| 2024-04-30 22:59:20 +0200 | <dminuoso> | Which is weird, because everywhere else, legally, you cannot be hired for 2 years before they have to extend that to an indefinite contract. |
| 2024-04-30 22:59:29 +0200 | <monochrom> | Basically the same phenomenon as: front line drug sellers and people who want to be actors and actress accept ridiculously low pay because of the prospect "there is 0.01% you will one day be a big shot, and then you will make big money". |
| 2024-04-30 22:59:51 +0200 | cashew | (~cashewsta@65.17.175.150) (Remote host closed the connection) |
| 2024-04-30 23:00:05 +0200 | <dminuoso> | tomsmeding: Oh I meant: 10 years is the limit for fixed-term work contracts (in sequence) at universities. |
| 2024-04-30 23:00:12 +0200 | <dminuoso> | 2 years for the rest of the normal world here. |
| 2024-04-30 23:00:16 +0200 | <tomsmeding> | right |
| 2024-04-30 23:00:25 +0200 | <dminuoso> | After that they would have to hire you permanently, which just doesnt happen. |
| 2024-04-30 23:00:26 +0200 | cashew | (~cashewsta@65.17.175.150) |
| 2024-04-30 23:00:54 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 255 seconds) |
| 2024-04-30 23:01:27 +0200 | <dminuoso> | And that 10 year limit really makes postdoc a difficult proposition, since your future really hangs in the balance. |
| 2024-04-30 23:01:29 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2024-04-30 23:01:29 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2024-04-30 23:01:29 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2024-04-30 23:01:55 +0200 | <tomsmeding> | aren't you supposed to do a postdoc at at different university than your phd anyway |
| 2024-04-30 23:02:15 +0200 | <dminuoso> | It's more unlikely you wont get a permanent position, and getting into the private sector becomes increasingly more difficult if you're already 35 without private sector experience |
| 2024-04-30 23:02:31 +0200 | <tomsmeding> | meaning that if you reach 10 years straight at the same uni, that basically means you're assistant professor or similar |
| 2024-04-30 23:04:31 +0200 | <dminuoso> | Not sure why time alone would grant you that position. |
| 2024-04-30 23:04:41 +0200 | <tomsmeding> | not saying that |
| 2024-04-30 23:05:05 +0200 | <tomsmeding> | rather that a phd takes ~4 years and a postdoc 1-2 years, and phds and postdocs are all at different universities typically |
| 2024-04-30 23:05:31 +0200 | <tomsmeding> | the only way you're going to amass 10 years straight at the same place is when you already have assistant professor position |
| 2024-04-30 23:05:50 +0200 | <dminuoso> | So at least in Germany, postdoc positions are usually paid for through some exterior means (rather than from university funds), say some grant or a company paying for it. |
| 2024-04-30 23:06:07 +0200 | <dminuoso> | So where you get that postdoc is really dependent on which place has those funds available. |
| 2024-04-30 23:06:32 +0200 | <dminuoso> | I think its more likely you get a postdoc position in an institute where the professor (who fought for that money) knows you |
| 2024-04-30 23:06:41 +0200 | <dminuoso> | But I dont have broad experience or knowledge to really say |
| 2024-04-30 23:06:54 +0200 | tomsmeding | thought it was somewhat frowned upon to stay in the same place for a postdoc |
| 2024-04-30 23:06:58 +0200 | <tomsmeding> | but I dunno |
| 2024-04-30 23:07:12 +0200 | <dminuoso> | Might a country-specific thing, then. |
| 2024-04-30 23:07:20 +0200 | <dminuoso> | Or maybe it differs between fields? |
| 2024-04-30 23:07:36 +0200 | <tomsmeding> | probably difference in country |
| 2024-04-30 23:07:50 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 245 seconds) |
| 2024-04-30 23:08:07 +0200 | <tomsmeding> | I hear that portugal is really strict in only hiring assistant professors who did a phd elsewhere |
| 2024-04-30 23:08:22 +0200 | <dminuoso> | tomsmeding: There's at least the notion that if you want a habilitation, that a postdoc in a different country would be a good idea. Maybe you were thinking of that? |
| 2024-04-30 23:08:25 +0200 | <tomsmeding> | and that here in NL that's not as strict, but you still need to have had experience elsewhere |
| 2024-04-30 23:08:49 +0200 | <tomsmeding> | I always forget what exactly a habilitation is, it's a German thing that we don't have |
| 2024-04-30 23:09:16 +0200 | <dminuoso> | It's an upgrade for your PhD. :-) |
| 2024-04-30 23:09:23 +0200 | <tomsmeding> | I always find it fascinating how much this stuff differs between countries |
| 2024-04-30 23:09:45 +0200 | <tomsmeding> | ostensibly we all share the same values about science or something, but we find room to differ on basically everything |
| 2024-04-30 23:09:46 +0200 | <dminuoso> | In Germany a habilitation is pretty much a requirement for becoming a professor |
| 2024-04-30 23:09:58 +0200 | <tomsmeding> | does not exist here :p |
| 2024-04-30 23:10:01 +0200 | <dminuoso> | Though the equivalent of an assistant professor (Junorprofessor) can be gained without habil. |
| 2024-04-30 23:10:08 +0200 | <tomsmeding> | I see |
| 2024-04-30 23:10:24 +0200 | <dminuoso> | Oh I missed an i (Juniorprofessor) there. |
| 2024-04-30 23:10:34 +0200 | <tomsmeding> | I thought so :) |
| 2024-04-30 23:10:38 +0200 | <haskellbridge> | <Jade> what's the german word for habilitation? |
| 2024-04-30 23:10:42 +0200 | <dminuoso> | Habilitation. |
| 2024-04-30 23:10:50 +0200 | <tomsmeding> | including the capital H, because German |
| 2024-04-30 23:11:02 +0200 | <dminuoso> | :-) |
| 2024-04-30 23:11:31 +0200 | <dminuoso> | Actually, is there a capital colon in UTF8 somewhere? |
| 2024-04-30 23:12:01 +0200 | <dminuoso> | *in Unicode |
| 2024-04-30 23:12:11 +0200 | <tomsmeding> | > toUpper ':' |
| 2024-04-30 23:12:13 +0200 | <lambdabot> | ':' |
| 2024-04-30 23:12:19 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-04-30 23:13:58 +0200 | <dminuoso> | :։܃܄࠱፡፥᛬᛬ |
| 2024-04-30 23:14:00 +0200 | juri_ | (~juri@implicitcad.org) |
| 2024-04-30 23:14:01 +0200 | <dminuoso> | So many choices |
| 2024-04-30 23:15:13 +0200 | <tomsmeding> | ⠅ |
| 2024-04-30 23:15:20 +0200 | <tomsmeding> | (caveat, depends on the font) |
| 2024-04-30 23:16:02 +0200 | <dminuoso> | tomsmeding: But yeah, for context: We Germans are quite special when it comes to positions and requirements. We have this notion of anerkannte Ausbildung which is an officially recognized qualification for a particular job. |
| 2024-04-30 23:16:23 +0200 | <dminuoso> | Which to my knowledge is not something many other countries have. |
| 2024-04-30 23:17:00 +0200 | <haskellbridge> | <Jade> ah I hadn't heard that |
| 2024-04-30 23:17:09 +0200 | <dminuoso> | A huge majority of positions that do not require a university degree will require such an anerkannte Ausbildung, and lots of career paths, retraining, etc. will require you to have one. |
| 2024-04-30 23:17:25 +0200 | <haskellbridge> | <Jade> dmniuoso: IHK :) |
| 2024-04-30 23:17:31 +0200 | <dminuoso> | Want to become a barber? Get an Ausbildung. |
| 2024-04-30 23:17:37 +0200 | <dminuoso> | Want to lay bricks? Get an Ausbildung. |
| 2024-04-30 23:17:59 +0200 | <tomsmeding> | which basically means "study it at some school"? |
| 2024-04-30 23:18:05 +0200 | <dminuoso> | Which in itself is not bad, but when the entire system is set up that it only admits people if you follow that system, its broken. |
| 2024-04-30 23:18:19 +0200 | <tomsmeding> | right |
| 2024-04-30 23:18:32 +0200 | <dminuoso> | tomsmeding: Not quite, the process is split in half. You spend half your time in some business (officially certified to train for that position), and the other in school. |
| 2024-04-30 23:19:48 +0200 | <mauke> | apprenticeship + vocational school |
| 2024-04-30 23:20:01 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-04-30 23:20:31 +0200 | pavonia | (~user@user/siracusa) |
| 2024-04-30 23:20:39 +0200 | <dminuoso> | Ah yeah, vocational/technical school is the term. |
| 2024-04-30 23:21:30 +0200 | <haskellbridge> | <Jade> you can also do it in uni if you have a duales studium |
| 2024-04-30 23:21:44 +0200 | <haskellbridge> | <Jade> uni basically replaces vocational school for me |
| 2024-04-30 23:22:01 +0200 | <haskellbridge> | <Jade> but I still do my apprenticeship |
| 2024-04-30 23:22:59 +0200 | madeleine-sydney | (~madeleine@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-04-30 23:23:01 +0200 | <dminuoso> | I guess we're living in a phase of academic inflation. |
| 2024-04-30 23:23:25 +0200 | <dminuoso> | Especially in Germany, the perception and reptutation of these recognized apprenticeships has completely gone down the drain. |
| 2024-04-30 23:24:21 +0200 | <tomsmeding> | dminuoso: what should you do instead, if those apprenticeships are not "worth" as much as they did? |
| 2024-04-30 23:24:28 +0200 | <dminuoso> | Well, you go to university. |
| 2024-04-30 23:24:39 +0200 | <dminuoso> | The entire system has been setting up to send more and more people to university. |
| 2024-04-30 23:24:44 +0200 | <tomsmeding> | and then do the exact same thing afterwards to get a job? |
| 2024-04-30 23:24:57 +0200 | <tomsmeding> | or does university count as Ausbildung for a whole legion of jobs |
| 2024-04-30 23:25:03 +0200 | <mauke> | get a CS bachelor, write some websites |
| 2024-04-30 23:25:10 +0200 | <dminuoso> | Well, a university degree is - for all intends and purposes - a "recognized completion of your job training" at least. |
| 2024-04-30 23:25:32 +0200 | <tomsmeding> | but I can't become a brick layer with a CS degree? |
| 2024-04-30 23:25:34 +0200 | <dminuoso> | So all paths in your career that requires to have some piece of paper with a certification stamp on it will let you hop on. |
| 2024-04-30 23:25:36 +0200 | <dminuoso> | tomsmeding: thats right. |
| 2024-04-30 23:25:42 +0200 | <dminuoso> | But you get an Umschulung, probably. |
| 2024-04-30 23:25:47 +0200 | <dminuoso> | Which is a way to retrain. |
| 2024-04-30 23:25:57 +0200 | <dminuoso> | Might have to look into details whether that particular path is possible. |
| 2024-04-30 23:26:01 +0200 | <tomsmeding> | :D |
| 2024-04-30 23:26:41 +0200 | <dminuoso> | tomsmeding: And the thing is, plenty of these trades that require official certification, are often very heavily regulated. |
| 2024-04-30 23:26:48 +0200 | <mauke> | Quereinsteiger :-) |
| 2024-04-30 23:27:06 +0200 | mima | (~mmh@aftr-62-216-211-165.dynamic.mnet-online.de) |
| 2024-04-30 23:27:30 +0200 | <dminuoso> | tomsmeding: Inside that - lets call it - apprenticeship path, similar to professor there is a Meister (master) advancement, and there's often lots of regulations who can even open a trade business. |
| 2024-04-30 23:27:59 +0200 | <dminuoso> | So for example you cant just open a bakery, no matter how damn good you are at baking, if you dont have that Meister (master - not in the university sense) degree. |
| 2024-04-30 23:28:01 +0200 | <yushyin> | (so many germans here oO) |
| 2024-04-30 23:28:03 +0200 | <tomsmeding> | a guild system, but operated by the government, I guess |
| 2024-04-30 23:28:10 +0200 | <dminuoso> | tomsmeding: Not operated by the goerment. |
| 2024-04-30 23:28:12 +0200 | <dminuoso> | Who dares. |
| 2024-04-30 23:28:15 +0200 | <tomsmeding> | :D |
| 2024-04-30 23:28:20 +0200 | <tomsmeding> | the federal state, excuse me |
| 2024-04-30 23:28:23 +0200 | <dminuoso> | its government sanctioned monopolistic unions. |
| 2024-04-30 23:28:28 +0200 | <tomsmeding> | oh not even |
| 2024-04-30 23:28:46 +0200 | <mauke> | apprentice -> journeyman -> master |
| 2024-04-30 23:29:44 +0200 | <dminuoso> | tomsmeding: but yeah, the guild system is very very much alive here. |
| 2024-04-30 23:29:47 +0200 | <tomsmeding> | (Quereinsteiger is a word we also have in Dutch, if you suitably substitute for synonyms) |
| 2024-04-30 23:29:50 +0200 | <tomsmeding> | cool, TIL |
| 2024-04-30 23:32:33 +0200 | <tomsmeding> | I know guild systems from fantasy novels :p |
| 2024-04-30 23:33:51 +0200 | <dminuoso> | Here's a list of exotic jobs that have that Meister requirement (and are very regulated by their guils): glass refiner, organ and harmonium retrofitter, sign and neon sign manufacturer, pavement layer |
| 2024-04-30 23:34:19 +0200 | <int-e> | what is a neon sign? :P |
| 2024-04-30 23:34:31 +0200 | <dminuoso> | But of course lots of traditional jobs like brick layers, bakers, electricials, barbers, carpenters, mechatronics engineers are similarly dealt. |
| 2024-04-30 23:34:52 +0200 | <dminuoso> | int-e: Oh I just liberally translated it. Illuminated signs is the literal translation. |
| 2024-04-30 23:35:06 +0200 | <tomsmeding> | oh is that not a thing in English? |
| 2024-04-30 23:35:10 +0200 | <mauke> | leuchtschild? |
| 2024-04-30 23:35:16 +0200 | <dminuoso> | (And yeah, we do have an officially recognized and guild protected job as a "sign and illuminated sign manufacturer") |
| 2024-04-30 23:35:28 +0200 | <int-e> | dminuoso: fair enough, I just enjoyed the anachronism |
| 2024-04-30 23:35:30 +0200 | int-e | tunes out again |
| 2024-04-30 23:35:39 +0200 | <tomsmeding> | ah right :p |
| 2024-04-30 23:36:06 +0200 | <mauke> | also, hairdressers |
| 2024-04-30 23:36:09 +0200 | <tomsmeding> | still called "neon lighting" today (when translated literally) in Dutch |
| 2024-04-30 23:36:25 +0200 | <int-e> | (I /guess/ some new neon signs are still made and some more being maintained, but most of the signs seem to be LED based these days) |
| 2024-04-30 23:37:00 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 245 seconds) |
| 2024-04-30 23:37:06 +0200 | <tomsmeding> | as in, I would have no clue what Dutch word to use if not "neon lighting" |
| 2024-04-30 23:38:45 +0200 | <geekosaur> | .oO{ and the people bowed and prayed / to the neon god they'd made } |
| 2024-04-30 23:39:06 +0200 | michalz | (~michalz@185.246.207.201) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-04-30 23:41:08 +0200 | <int-e> | When my eyes were stabbed by the flash of a neon light ...one day I'll remember those lyrics |
| 2024-04-30 23:52:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-04-30 23:57:36 +0200 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) (Ping timeout: 255 seconds) |
| 2024-04-30 23:59:19 +0200 | <shapr> | ik begrijp het niet |
| 2024-04-30 23:59:27 +0200 | <shapr> | probably because I don't speak Dutch, oh well |
