| 2024-03-24 00:02:22 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-24 00:04:37 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-24 00:11:58 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) (Remote host closed the connection) |
| 2024-03-24 00:12:45 +0100 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-03-24 00:16:21 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:32fc:1140:12f0:2672) (Remote host closed the connection) |
| 2024-03-24 00:18:53 +0100 | TonyStone | (~TonyStone@074-076-057-186.res.spectrum.com) |
| 2024-03-24 00:19:15 +0100 | destituion | (~destituio@2001:4644:c37:0:6086:64f4:a213:b80d) (Ping timeout: 256 seconds) |
| 2024-03-24 00:19:26 +0100 | destituion | (~destituio@2a02:2121:655:c95b:3078:92e:b911:97ff) |
| 2024-03-24 00:21:01 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-03-24 00:21:09 +0100 | euleritian | (~euleritia@dynamic-046-114-095-014.46.114.pool.telefonica.de) |
| 2024-03-24 00:21:55 +0100 | euleritian | (~euleritia@dynamic-046-114-095-014.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-24 00:22:12 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-24 00:34:50 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-03-24 00:34:56 +0100 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 245 seconds) |
| 2024-03-24 00:35:28 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-03-24 00:44:45 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2024-03-24 00:50:06 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 255 seconds) |
| 2024-03-24 00:51:57 +0100 | mechap | (~mechap@user/mechap) (Quit: WeeChat 4.2.1) |
| 2024-03-24 00:54:17 +0100 | mechap | (~mechap@user/mechap) |
| 2024-03-24 00:55:57 +0100 | acidjnk | (~acidjnk@p200300d6e70d3f39710acbcd8de4867e.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-03-24 01:03:43 +0100 | bilegeek | (~bilegeek@2600:1008:b019:e8f5:2f79:4b0:5511:ae46) |
| 2024-03-24 01:11:24 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-03-24 01:16:20 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-03-24 01:16:48 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-24 01:17:02 +0100 | <Inst> | monochrom: honestly, different paradigms seem to work better for different texts; it's all von neumann machines / harvard architecture underneath at the end |
| 2024-03-24 01:17:08 +0100 | <Inst> | we still can't escape procedural for IO |
| 2024-03-24 01:17:34 +0100 | sadie_ | (~sadie@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-03-24 01:17:48 +0100 | <Inst> | pure, lazy, FP just seems a reasonable default for non-effecting calculations |
| 2024-03-24 01:18:43 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-24 01:23:21 +0100 | myxos | (~myxos@065-028-251-121.inf.spectrum.com) (Remote host closed the connection) |
| 2024-03-24 01:24:04 +0100 | myxos | (~myxos@065-028-251-121.inf.spectrum.com) |
| 2024-03-24 01:24:26 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in) |
| 2024-03-24 01:24:40 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-03-24 01:25:03 +0100 | lbseale | (~quassel@user/ep1ctetus) (Remote host closed the connection) |
| 2024-03-24 01:26:18 +0100 | lbseale | (~quassel@user/ep1ctetus) |
| 2024-03-24 01:27:37 +0100 | <Inst> | still, haskell has a role as an experimental and research language; part of the point is to see how far pure FP can go, and see if the pursuit of pure FP can deliver interesting techniques or concepts |
| 2024-03-24 01:32:17 +0100 | sadie_ | (~sadie@c-76-155-235-153.hsd1.co.comcast.net) (Remote host closed the connection) |
| 2024-03-24 01:41:35 +0100 | y04nn | (~username@2a03:1b20:4:f011::999e) |
| 2024-03-24 01:54:20 +0100 | Benzi-Junior | (~BenziJuni@232-148-209-31.dynamic.hringdu.is) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-03-24 01:57:01 +0100 | Benzi-Junior | (~BenziJuni@232-148-209-31.dynamic.hringdu.is) |
| 2024-03-24 01:58:25 +0100 | lvdv | (~lvdv@203.7.118.37) |
| 2024-03-24 01:59:41 +0100 | y04nn | (~username@2a03:1b20:4:f011::999e) (Ping timeout: 268 seconds) |
| 2024-03-24 02:00:34 +0100 | iris_67 | (~iris_67@2804:d45:9cea:6100:226b:ab6e:4303:eab1) |
| 2024-03-24 02:01:31 +0100 | zer0bitz_ | (~zer0bitz@user/zer0bitz) |
| 2024-03-24 02:04:38 +0100 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 264 seconds) |
| 2024-03-24 02:05:04 +0100 | iris_67 | (~iris_67@2804:d45:9cea:6100:226b:ab6e:4303:eab1) (Client Quit) |
| 2024-03-24 02:05:20 +0100 | iris_67 | (~iris_67@2804:d45:9cea:6100:226b:ab6e:4303:eab1) |
| 2024-03-24 02:06:21 +0100 | iris_67 | (~iris_67@2804:d45:9cea:6100:226b:ab6e:4303:eab1) (Client Quit) |
| 2024-03-24 02:12:18 +0100 | dsrt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-03-24 02:12:27 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2024-03-24 02:14:09 +0100 | euleritian | (~euleritia@dynamic-046-114-095-014.46.114.pool.telefonica.de) |
| 2024-03-24 02:26:18 +0100 | euleritian | (~euleritia@dynamic-046-114-095-014.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-24 02:26:36 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-03-24 02:29:59 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 264 seconds) |
| 2024-03-24 02:39:46 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-03-24 02:59:05 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2024-03-24 02:59:36 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) |
| 2024-03-24 03:01:59 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2024-03-24 03:02:38 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2024-03-24 03:04:42 +0100 | <EvanR> | I think there's been plenty of stuff experiment past the point of haskell since haskell came out |
| 2024-03-24 03:04:49 +0100 | <EvanR> | experimenting |
| 2024-03-24 03:07:00 +0100 | <EvanR> | though ghc is still a grand experiment in compiling |
| 2024-03-24 03:08:16 +0100 | mima | (~mmh@aftr-62-216-211-106.dynamic.mnet-online.de) (Ping timeout: 255 seconds) |
| 2024-03-24 03:09:10 +0100 | <geekosaur> | ghc is a grand experiment in… something |
| 2024-03-24 03:09:21 +0100 | <geekosaur> | not sure it's an experiment in haskell any more |
| 2024-03-24 03:09:47 +0100 | <geekosaur> | apparently I'm not the only one… https://github.com/augustss/MicroHs |
| 2024-03-24 03:10:09 +0100 | <geekosaur> | the great reboot? |
| 2024-03-24 03:11:25 +0100 | <Clint> | extended subset |
| 2024-03-24 03:16:07 +0100 | Daxson | (~Daxson@176.254.244.83) (Quit: Connection error?!) |
| 2024-03-24 03:19:18 +0100 | migas97 | (~migas@static.140.65.63.178.clients.your-server.de) (Quit: The Lounge - https://thelounge.github.io) |
| 2024-03-24 03:20:04 +0100 | migas97 | (~migas@static.140.65.63.178.clients.your-server.de) |
| 2024-03-24 03:25:51 +0100 | otto_s | (~user@p5b04451e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-03-24 03:27:30 +0100 | otto_s | (~user@p5de2f3cc.dip0.t-ipconnect.de) |
| 2024-03-24 03:38:54 +0100 | pavonia | (~user@user/siracusa) |
| 2024-03-24 03:43:21 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-03-24 04:05:03 +0100 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2024-03-24 04:05:31 +0100 | sgarcia | (sgarcia@swarm.znchost.com) (Quit: Hosted by www.ZNCHost.com) |
| 2024-03-24 04:05:33 +0100 | op_4 | (~tslil@user/op-4/x-9116473) |
| 2024-03-24 04:08:48 +0100 | crook1389 | (uid581388@id-581388.ilkley.irccloud.com) |
| 2024-03-24 04:10:30 +0100 | motherfsck | (~motherfsc@user/motherfsck) |
| 2024-03-24 04:14:24 +0100 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2024-03-24 04:17:08 +0100 | sgarcia | (sgarcia@swarm.znchost.com) |
| 2024-03-24 04:26:06 +0100 | mulk | (~mulk@p5b2dc71d.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2024-03-24 04:27:38 +0100 | mulk | (~mulk@p5b2dc2aa.dip0.t-ipconnect.de) |
| 2024-03-24 04:34:28 +0100 | Rodney_ | (~Rodney@176.254.244.83) |
| 2024-03-24 04:42:26 +0100 | td_ | (~td@i53870906.versanet.de) (Ping timeout: 245 seconds) |
| 2024-03-24 04:42:58 +0100 | Guest92 | (~Guest92@97-120-7-219.ptld.qwest.net) |
| 2024-03-24 04:44:26 +0100 | td_ | (~td@i53870928.versanet.de) |
| 2024-03-24 04:58:19 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-03-24 04:58:45 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-03-24 04:59:10 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-03-24 05:01:59 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3441-13b3-f842-e4eb-f5b3-2e87.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-24 05:03:12 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3441-13b3-98ea-4818-341c-534e.rev.sfr.net) |
| 2024-03-24 05:06:28 +0100 | aforemny | (~aforemny@2001:9e8:6cef:a200:5c66:7868:1cde:e3b5) |
| 2024-03-24 05:06:42 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3441-13b3-98ea-4818-341c-534e.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-24 05:07:47 +0100 | aforemny_ | (~aforemny@i59F516EB.versanet.de) (Ping timeout: 264 seconds) |
| 2024-03-24 05:12:28 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-24 05:40:50 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-03-24 05:43:30 +0100 | sadie_ | (~sadie@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-03-24 05:43:32 +0100 | lvdv | (~lvdv@203.7.118.37) (Ping timeout: 268 seconds) |
| 2024-03-24 05:55:07 +0100 | statusbot5 | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) (Remote host closed the connection) |
| 2024-03-24 05:55:22 +0100 | statusbot | (~statusbot@ec2-34-198-122-184.compute-1.amazonaws.com) |
| 2024-03-24 06:08:59 +0100 | Square | (~Square@user/square) (Ping timeout: 264 seconds) |
| 2024-03-24 06:10:14 +0100 | Guest92 | (~Guest92@97-120-7-219.ptld.qwest.net) (Ping timeout: 250 seconds) |
| 2024-03-24 06:17:38 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) (Quit: WeeChat 4.2.1) |
| 2024-03-24 06:24:51 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 268 seconds) |
| 2024-03-24 06:32:02 +0100 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.1) |
| 2024-03-24 06:38:27 +0100 | falafel | (~falafel@2607:fb91:8aa:877b:2df1:c884:ed4e:30d9) |
| 2024-03-24 06:39:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 06:40:15 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2024-03-24 06:58:49 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-03-24 06:58:55 +0100 | califax_ | (~califax@user/califx) |
| 2024-03-24 07:00:10 +0100 | califax_ | califax |
| 2024-03-24 07:04:24 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-03-24 07:06:53 +0100 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Remote host closed the connection) |
| 2024-03-24 07:11:33 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-03-24 07:12:11 +0100 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2024-03-24 07:20:58 +0100 | Guest52 | (~Guest52@185.57.29.142) (Quit: Ping timeout (120 seconds)) |
| 2024-03-24 07:25:21 +0100 | falafel | (~falafel@2607:fb91:8aa:877b:2df1:c884:ed4e:30d9) (Ping timeout: 245 seconds) |
| 2024-03-24 07:56:14 +0100 | Guest52 | (~Guest52@185.57.29.142) |
| 2024-03-24 07:56:16 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-03-24 07:59:05 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-03-24 08:00:07 +0100 | tt1231 | (~tt1231@075-185-104-199.res.spectrum.com) (Quit: The Lounge - https://thelounge.chat) |
| 2024-03-24 08:00:37 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-24 08:02:30 +0100 | tt12310 | (~tt1231@2603-6010-8700-4a81-219f-50d3-618a-a6ee.res6.spectrum.com) |
| 2024-03-24 08:08:58 +0100 | Guest52 | (~Guest52@185.57.29.142) (Ping timeout: 250 seconds) |
| 2024-03-24 08:14:26 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-03-24 08:36:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 08:37:44 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-03-24 08:46:39 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-03-24 08:47:41 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 256 seconds) |
| 2024-03-24 08:49:02 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-03-24 08:52:06 +0100 | acidjnk | (~acidjnk@p200300d6e72b6a8560cb954dffdecc30.dip0.t-ipconnect.de) |
| 2024-03-24 08:56:17 +0100 | berberman | (~berberman@user/berberman) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-03-24 08:56:41 +0100 | berberman | (~berberman@user/berberman) |
| 2024-03-24 08:57:19 +0100 | berberman | (~berberman@user/berberman) (Remote host closed the connection) |
| 2024-03-24 08:58:14 +0100 | berberman | (~berberman@user/berberman) |
| 2024-03-24 09:05:41 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-24 09:07:48 +0100 | bilegeek | (~bilegeek@2600:1008:b019:e8f5:2f79:4b0:5511:ae46) (Quit: Leaving) |
| 2024-03-24 09:11:42 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 09:15:40 +0100 | Rodney_ | (~Rodney@176.254.244.83) (Ping timeout: 268 seconds) |
| 2024-03-24 09:16:06 +0100 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-03-24 09:21:22 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-03-24 09:27:36 +0100 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 255 seconds) |
| 2024-03-24 09:31:27 +0100 | Rodney_ | (~Rodney@176.254.244.83) |
| 2024-03-24 09:32:51 +0100 | haskell_ | (~haskell@75-164-217-161.ptld.qwest.net) |
| 2024-03-24 09:38:57 +0100 | haskell_ | (~haskell@75-164-217-161.ptld.qwest.net) (Remote host closed the connection) |
| 2024-03-24 09:50:41 +0100 | <tomsmeding> | > with the notable exception that Foldable and Traversable are not part of the Prelude. |
| 2024-03-24 09:50:45 +0100 | <tomsmeding> | sounds like someone had an opinion |
| 2024-03-24 10:02:53 +0100 | <sadie_> | where's that from? |
| 2024-03-24 10:06:29 +0100 | <tomsmeding> | sadie_: the MicroHs link that geekosaur shared |
| 2024-03-24 10:06:44 +0100 | <tomsmeding> | https://ircbrowse.tomsmeding.com/browse/lchaskell?id=1238213#trid1238213 |
| 2024-03-24 10:28:18 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Ping timeout: 260 seconds) |
| 2024-03-24 10:29:00 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) |
| 2024-03-24 10:31:29 +0100 | <sadie_> | aha |
| 2024-03-24 10:35:24 +0100 | kuribas | (~user@ptr-17d51eofujeriaat5yx.18120a2.ip6.access.telenet.be) |
| 2024-03-24 10:36:29 +0100 | sprout | (~quassel@84-80-106-227.fixed.kpn.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-03-24 10:37:21 +0100 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2024-03-24 10:46:30 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-03-24 10:47:09 +0100 | sprout | (~quassel@2a02-a448-3a80-0-355e-e5b2-f32d-a9c5.fixed6.kpn.net) |
| 2024-03-24 10:49:02 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-03-24 10:49:19 +0100 | sayola | (~sayola@ip-109-42-242-200.web.vodafone.de) |
| 2024-03-24 10:50:59 +0100 | sayola1 | (~sayola@ip-109-42-242-92.web.vodafone.de) (Ping timeout: 252 seconds) |
| 2024-03-24 10:53:44 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 252 seconds) |
| 2024-03-24 11:00:44 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) |
| 2024-03-24 11:00:50 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) (Remote host closed the connection) |
| 2024-03-24 11:01:18 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) |
| 2024-03-24 11:01:59 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-03-24 11:05:57 +0100 | wagle | (~wagle@quassel.wagle.io) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-03-24 11:06:13 +0100 | wagle | (~wagle@quassel.wagle.io) |
| 2024-03-24 11:06:21 +0100 | wagle | (~wagle@quassel.wagle.io) (Client Quit) |
| 2024-03-24 11:07:10 +0100 | wagle | (~wagle@quassel.wagle.io) |
| 2024-03-24 11:15:49 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-03-24 11:19:42 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-03-24 11:22:39 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2024-03-24 11:23:04 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-03-24 11:23:14 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
| 2024-03-24 11:23:16 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-03-24 11:24:25 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2024-03-24 11:33:30 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-03-24 11:46:57 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-03-24 11:47:15 +0100 | <tomsmeding> | why oh why does the package that fixes the Monoid instance of Map (monoidal-containers) depend on aeson |
| 2024-03-24 11:47:22 +0100 | <tomsmeding> | oh _and lens_! |
| 2024-03-24 11:47:30 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-03-24 11:47:58 +0100 | mima | (~mmh@aftr-62-216-211-109.dynamic.mnet-online.de) |
| 2024-03-24 11:48:46 +0100 | <tomsmeding> | why must I increase the transitive dependency set by like a factor 20 or so just to have a Map with an accumulative Monoid instance |
| 2024-03-24 11:49:03 +0100 | tomsmeding | will reimplement the thing myself |
| 2024-03-24 11:52:33 +0100 | <probie> | probably to avoid orphan instances from things like ToJSON/FromJSON and At/Ixed |
| 2024-03-24 11:52:42 +0100 | <tomsmeding> | oh for sure |
| 2024-03-24 11:52:56 +0100 | <tomsmeding> | it's a pity "we" haven't found a proper solution for that yet |
| 2024-03-24 12:01:01 +0100 | mrmr155334 | (~mrmr@user/mrmr) (Quit: Bye, See ya later!) |
| 2024-03-24 12:05:54 +0100 | mrmr155334 | (~mrmr@user/mrmr) |
| 2024-03-24 12:09:52 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) (Ping timeout: 246 seconds) |
| 2024-03-24 12:12:34 +0100 | <kuribas> | Why does a web library like spock include database parameters? |
| 2024-03-24 12:13:03 +0100 | <kuribas> | Should databases be part of the application state, and no concern of the web library? |
| 2024-03-24 12:16:11 +0100 | <Rembane> | If they go full on Rails it needs everything, but Spock is just web right? If so, then they shouldn't care about databases. |
| 2024-03-24 12:16:15 +0100 | <Rembane> | ...IMHO. |
| 2024-03-24 12:19:07 +0100 | <kuribas> | oh, maybe it is for session management... |
| 2024-03-24 12:19:26 +0100 | <kuribas> | It would need a DB for storing the session. |
| 2024-03-24 12:19:54 +0100 | sayola | (~sayola@ip-109-42-242-200.web.vodafone.de) (Quit: Leaving.) |
| 2024-03-24 12:19:56 +0100 | <tomsmeding> | can websites please not track sessions? |
| 2024-03-24 12:19:57 +0100 | <kuribas> | Though I think using sessions is outdated. |
| 2024-03-24 12:20:05 +0100 | <kuribas> | tomsmeding: yeah :) |
| 2024-03-24 12:20:15 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) |
| 2024-03-24 12:20:53 +0100 | <tomsmeding> | it has all the properties I don't want |
| 2024-03-24 12:21:24 +0100 | <Rembane> | tomsmeding: What's your biggest gripe with sessions? |
| 2024-03-24 12:21:42 +0100 | <tomsmeding> | they're gone when you close the tab |
| 2024-03-24 12:22:05 +0100 | <tomsmeding> | a session, in my mind, outlives a single browser tab, and furthermore can be shared over multiple browser tabs |
| 2024-03-24 12:22:23 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in) |
| 2024-03-24 12:22:31 +0100 | <tomsmeding> | if you want session tracking without an account system, use LocalStorage or a cookie |
| 2024-03-24 12:22:52 +0100 | <Rembane> | Got it! I think I have mixed up the idea of cookies and sessions. I blame PHP! |
| 2024-03-24 12:23:12 +0100 | <tomsmeding> | I mean, sessions are typically _implemented_ using cookies that expire when you close the tab, I think |
| 2024-03-24 12:23:16 +0100 | <kuribas> | Or add user management. |
| 2024-03-24 12:23:25 +0100 | CiaoSen | (~Jura@2a05:5800:2bf:a100:e6b9:7aff:fe80:3d03) |
| 2024-03-24 12:23:27 +0100 | <tomsmeding> | > without an account system |
| 2024-03-24 12:23:48 +0100 | <tomsmeding> | of course if it makes sense to have an account system, then do that and store the state there so that a user can even migrate to another device |
| 2024-03-24 12:24:39 +0100 | <tomsmeding> | php-style sessions are kind of like using http basic auth for authentication |
| 2024-03-24 12:24:55 +0100 | <tomsmeding> | it kinda works if you're lazy enough to not care for a better solution, but only if the user is in on it |
| 2024-03-24 12:25:18 +0100 | tomsmeding | uses http basic auth on stuff where I'm the only user |
| 2024-03-24 12:26:19 +0100 | <Rembane> | We've used it at work for way too long. |
| 2024-03-24 12:27:03 +0100 | <tomsmeding> | maybe http basic auth is the less-bad one, because if you really want you can even automate it using a password manager |
| 2024-03-24 12:27:06 +0100 | <mauke> | <tomsmeding> they're gone when you close the tab <- ??? |
| 2024-03-24 12:27:07 +0100 | <tomsmeding> | and then it works fine |
| 2024-03-24 12:27:27 +0100 | <tomsmeding> | mauke: am I remembering sessions wrong? |
| 2024-03-24 12:27:32 +0100 | <mauke> | yes |
| 2024-03-24 12:27:39 +0100 | <tomsmeding> | enlighten me |
| 2024-03-24 12:27:50 +0100 | <mauke> | you can set an arbitrary expiration date on your cookies |
| 2024-03-24 12:27:56 +0100 | <tomsmeding> | I know _that_ |
| 2024-03-24 12:28:12 +0100 | <tomsmeding> | but is that also how sessions work in php / web frameworks that copied php |
| 2024-03-24 12:28:27 +0100 | <mauke> | lol who cares about php |
| 2024-03-24 12:28:46 +0100 | <tomsmeding> | well Spock, apparently, if I'm to believe kuribas that it does something with a thing called "sessions" |
| 2024-03-24 12:28:57 +0100 | <Hecate> | Rembane: yeah tell me about it… |
| 2024-03-24 12:29:00 +0100 | <mauke> | wat |
| 2024-03-24 12:29:27 +0100 | <tomsmeding> | disclaimer I have opened 0 documentation while ranting here |
| 2024-03-24 12:29:28 +0100 | <kuribas> | tomsmeding: https://hackage.haskell.org/package/Spock-0.14.0.0/docs/Web-Spock-SessionActions.html |
| 2024-03-24 12:29:36 +0100 | <mauke> | sessions are just server-side state with a client-stored identifier/key |
| 2024-03-24 12:29:39 +0100 | <Rembane> | Hecate: It's way too powerful and quick |
| 2024-03-24 12:30:08 +0100 | <Rembane> | Hecate: And it's just to put the encrypted keys in the git repo |
| 2024-03-24 12:30:09 +0100 | <mauke> | sessions go away when the server destroys its state or when the client loses the key |
| 2024-03-24 12:31:03 +0100 | <tomsmeding> | ah so this does less than php does (php also did the cookie stuff for you) |
| 2024-03-24 12:31:15 +0100 | <mauke> | so if you don't delete your state and don't use cookies that go away when the browser is closed, your session should remain forever |
| 2024-03-24 12:31:17 +0100 | <tomsmeding> | meaning that this is just supporting functionality for an account system, basically |
| 2024-03-24 12:32:29 +0100 | <tomsmeding> | mauke: the context was "why does spock want to know database info" |
| 2024-03-24 12:32:38 +0100 | <tomsmeding> | seems it's _not_ sessions? |
| 2024-03-24 12:33:58 +0100 | <tomsmeding> | kuribas: maybe it's just that it handles database connection pooling for you, because "you always need a DB when writing a web app, right?" |
| 2024-03-24 12:34:23 +0100 | <tomsmeding> | Rembane: turns out spock sessions != php sessions |
| 2024-03-24 12:35:19 +0100 | <mauke> | https://hackage.haskell.org/package/Spock-0.14.0.0/docs/Web-Spock-Config.html#t:SessionCfg |
| 2024-03-24 12:35:36 +0100 | <Rembane> | tomsmeding: Good stuff! |
| 2024-03-24 12:35:39 +0100 | <mauke> | it does manage session cookies automatically |
| 2024-03-24 12:36:33 +0100 | <tomsmeding> | I see |
| 2024-03-24 12:36:50 +0100 | <mauke> | hah, https://hackage.haskell.org/package/Spock-core-0.14.0.0/docs/Web-Spock-Internal-Cookies.html#t:Coo… is a bit misleading |
| 2024-03-24 12:36:58 +0100 | <tomsmeding> | well unless you newStmSessionStore |
| 2024-03-24 12:37:06 +0100 | fedorafan | (~fedorafan@user/fedorafan) (Quit: Textual IRC Client: www.textualapp.com) |
| 2024-03-24 12:37:21 +0100 | <tomsmeding> | what does "browser session" mean |
| 2024-03-24 12:37:25 +0100 | <mauke> | defaultCookieSettings has CookieValidForSession, but defaultSessionCfg does not use defaultCookieSettings |
| 2024-03-24 12:38:04 +0100 | <mauke> | depends on how your HTTP client implements the Web Cookie spec |
| 2024-03-24 12:38:14 +0100 | <mauke> | but IIRC browsers treat it as "until the application is closed" |
| 2024-03-24 12:38:33 +0100 | <tomsmeding> | okay that's slightly better than "just one tab" |
| 2024-03-24 12:38:38 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-03-24 12:38:49 +0100 | <tomsmeding> | but seems that that's the thing I was remembering |
| 2024-03-24 12:39:00 +0100 | <tomsmeding> | why should my state be gone if my browser crashes? |
| 2024-03-24 12:39:05 +0100 | <tomsmeding> | or if my battery dies? |
| 2024-03-24 12:39:13 +0100 | <tomsmeding> | use a normal cookie or whatever |
| 2024-03-24 12:39:20 +0100 | <mauke> | because the typical flow used to be "oh, I need information from the WWW -> open web browser -> browse pages -> close browser" |
| 2024-03-24 12:39:29 +0100 | <probie> | remember that most of this behaviour was originally defined in the days before browsers had tabs |
| 2024-03-24 12:39:30 +0100 | <mauke> | before we had tabs and stuff |
| 2024-03-24 12:39:39 +0100 | <mauke> | and always-open browser windows |
| 2024-03-24 12:39:58 +0100 | <tomsmeding> | saying "this is of before tabs" just removes my point that this is _better_ than I thought lol |
| 2024-03-24 12:40:04 +0100 | mei | (~mei@user/mei) |
| 2024-03-24 12:40:15 +0100 | fedorafan | (~fedorafan@user/fedorafan) |
| 2024-03-24 12:40:39 +0100 | <tomsmeding> | anyway I guess my point reduces to "please don't use CookieValidForSession, I think it's annoying" |
| 2024-03-24 12:40:49 +0100 | <mauke> | also, IIRC "web cookies" were a netscape invention |
| 2024-03-24 12:41:01 +0100 | <mauke> | the original HTTP spec didn't have this kind of state |
| 2024-03-24 12:42:04 +0100 | <tomsmeding> | I'm not complaining about the design decisions for exactly how those features work -- I'm talking about the experience of using websites today with a modern browser :) |
| 2024-03-24 12:42:05 +0100 | <Rembane> | Then they got some RFCs, where RFC 6265 is the latest which I suppose means they are for real now. |
| 2024-03-24 12:42:17 +0100 | <mauke> | https://en.wikipedia.org/wiki/Magic_cookie |
| 2024-03-24 12:42:28 +0100 | <tomsmeding> | I would have made far more mistakes in designing all this if I was there a few decades ago (I wasn't) |
| 2024-03-24 12:42:38 +0100 | <tomsmeding> | but that doesn't mean that we can now decide to not use certain things |
| 2024-03-24 12:42:43 +0100 | <tomsmeding> | *can't |
| 2024-03-24 12:42:48 +0100 | <tomsmeding> | sorry for the triple negative |
| 2024-03-24 12:43:00 +0100 | <mauke> | yeah, I don't think I use any current website that uses "session cookies" for its user sessions |
| 2024-03-24 12:43:07 +0100 | <tomsmeding> | fortunately |
| 2024-03-24 12:43:48 +0100 | <mauke> | it's always "[x] remember me on this device" and then you get an expiration date that's months or years in the future |
| 2024-03-24 12:43:53 +0100 | <tomsmeding> | mauke: I like how that "Usage" section has a ratio of 0.75 [citation needed] labels per sentence |
| 2024-03-24 12:44:51 +0100 | <mauke> | a special shoutout to google.com, which even in 2001 silently set tracking cookies with an epiration date of January 2038 |
| 2024-03-24 12:45:27 +0100 | <tomsmeding> | lol |
| 2024-03-24 12:50:30 +0100 | <int-e> | mauke: and then when you delete cookies they say nonsense like "log in from a new device/location" |
| 2024-03-24 12:51:11 +0100 | <tomsmeding> | that's actually a security benefit for the majority of people |
| 2024-03-24 12:52:49 +0100 | <int-e> | thee must be a better way to phrase this |
| 2024-03-24 12:52:53 +0100 | <int-e> | +r |
| 2024-03-24 12:53:21 +0100 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2024-03-24 12:58:38 +0100 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-03-24 13:01:42 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2024-03-24 13:07:05 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-03-24 13:08:00 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-03-24 13:12:09 +0100 | sadie_ | (~sadie@c-76-155-235-153.hsd1.co.comcast.net) (Remote host closed the connection) |
| 2024-03-24 13:17:14 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 260 seconds) |
| 2024-03-24 13:17:20 +0100 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-03-24 13:18:12 +0100 | euleritian | (~euleritia@77.22.252.56) |
| 2024-03-24 13:20:00 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-03-24 13:22:02 +0100 | <Inst> | wait, curious |
| 2024-03-24 13:22:25 +0100 | <Inst> | can i use lenses to compensate for the fact that set, hashmaps, etc aren't functors? |
| 2024-03-24 13:24:24 +0100 | <Inst> | "That feel when you realize that Haskell isn't complete without some rinky-dink Lens or Optics library" |
| 2024-03-24 13:24:26 +0100 | Inst | sighs |
| 2024-03-24 13:26:33 +0100 | <int-e> | You can bundle together a container type like Set a with a function a -> b to encode what would be a Set b, but there's a cost: You don't get cheap membership test. |
| 2024-03-24 13:27:01 +0100 | <int-e> | (heck, b may not even have an Eq instance at all) |
| 2024-03-24 13:27:51 +0100 | infinity0 | Guest1172 |
| 2024-03-24 13:27:51 +0100 | Guest1172 | (~infinity0@pwned.gg) (Killed (iridium.libera.chat (Nickname regained by services))) |
| 2024-03-24 13:28:00 +0100 | infinity0 | (~infinity0@pwned.gg) |
| 2024-03-24 13:29:52 +0100 | <kuribas> | Inst: just use the included map function? |
| 2024-03-24 13:38:59 +0100 | ht_ | (~Thunderbi@194.110.115.57) |
| 2024-03-24 13:39:02 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) |
| 2024-03-24 13:40:23 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Ping timeout: 252 seconds) |
| 2024-03-24 13:40:24 +0100 | ht_ | _ht |
| 2024-03-24 13:43:02 +0100 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 264 seconds) |
| 2024-03-24 13:44:09 +0100 | euleritian | (~euleritia@dynamic-046-114-094-041.46.114.pool.telefonica.de) |
| 2024-03-24 13:46:27 +0100 | <Inst> | no, but you lose the polymorphism |
| 2024-03-24 13:46:57 +0100 | <Rembane> | Why do you need the polymorphism? |
| 2024-03-24 13:47:20 +0100 | <Inst> | why do you need typeclasses? |
| 2024-03-24 13:47:25 +0100 | <kuribas> | https://hackage.haskell.org/package/unordered-containers-0.2.20/docs/Data-HashSet.html#v:map |
| 2024-03-24 13:47:30 +0100 | <kuribas> | Looks polymorphic to me. |
| 2024-03-24 13:48:57 +0100 | <[exa]> | Inst: set and hash structure functionality imposes constraints that are not compatible with requirements on functoriality. We could go YOLO there (and you're welcome to do so in your code) but rule of least surprise applies. |
| 2024-03-24 13:51:19 +0100 | <Inst> | yeah i'm aware that set and derivatives of sets aren't functors |
| 2024-03-24 13:51:26 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-03-24 13:51:38 +0100 | <Inst> | i was thinking pseudomap or mappable as a typeclass for a while, then i realized, you can just go to lens and forget about it all |
| 2024-03-24 13:51:52 +0100 | <Inst> | except: |
| 2024-03-24 13:51:53 +0100 | <Inst> | foo :: Set Int |
| 2024-03-24 13:51:53 +0100 | <Inst> | ghci| foo = fromList [1,2,3,4,0] |
| 2024-03-24 13:52:05 +0100 | <Inst> | ghci> foo ^. at 1 |
| 2024-03-24 13:52:05 +0100 | <Inst> | Just () |
| 2024-03-24 13:54:06 +0100 | <ncf> | Set is a functor, but not an (endo)Functor. those are sometimes called exofunctors |
| 2024-03-24 13:54:27 +0100 | <[exa]> | there was a class for that btw, something near Witherable but not exactly that |
| 2024-03-24 13:54:35 +0100 | <Inst> | iirc, from category of Eq to Eq |
| 2024-03-24 13:54:55 +0100 | <Inst> | this sucks, why am I getting Just ()? |
| 2024-03-24 13:55:03 +0100 | <ncf> | what did you expect? |
| 2024-03-24 13:55:35 +0100 | <ncf> | remember Set a ≃ Map a () |
| 2024-03-24 13:57:22 +0100 | <Inst> | so how do I use map operations... oh crap, I need to figure out which lens operator gets keys |
| 2024-03-24 13:58:10 +0100 | <ncf> | are you looking for setmapped? https://hackage.haskell.org/package/lens-5.2.3/docs/Data-Set-Lens.html |
| 2024-03-24 13:58:16 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) (Remote host closed the connection) |
| 2024-03-24 13:58:34 +0100 | <ncf> | note this is just `setting Set.map` |
| 2024-03-24 14:00:46 +0100 | mechap | (~mechap@user/mechap) |
| 2024-03-24 14:07:19 +0100 | <Inst> | thanks ;_; |
| 2024-03-24 14:07:58 +0100 | CiaoSen | (~Jura@2a05:5800:2bf:a100:e6b9:7aff:fe80:3d03) (Ping timeout: 268 seconds) |
| 2024-03-24 14:09:33 +0100 | tomku|two | (~tomku@user/tomku) (Ping timeout: 252 seconds) |
| 2024-03-24 14:10:08 +0100 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.1) |
| 2024-03-24 14:14:30 +0100 | dsrt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2024-03-24 14:20:29 +0100 | harveypwca | (~harveypwc@2601:246:c200:2740:15b6:f225:14ff:9821) (Quit: Leaving) |
| 2024-03-24 14:21:53 +0100 | <Inst> | actually, here's an issue with traverse, i think |
| 2024-03-24 14:21:57 +0100 | <Inst> | traverse can't break, foldr can |
| 2024-03-24 14:22:01 +0100 | <Inst> | well, at least on lazy lists |
| 2024-03-24 14:22:11 +0100 | <janus> | i've gotten an tcp echo server running on microHs :D |
| 2024-03-24 14:23:30 +0100 | <janus> | i've heard people say one of the the greatest things about ghc is the runtime |
| 2024-03-24 14:23:39 +0100 | oo_miguel | (~Thunderbi@78-11-181-16.static.ip.netia.com.pl) |
| 2024-03-24 14:23:49 +0100 | <janus> | but people always talk about the type system, and it seems that most research is also about type systems |
| 2024-03-24 14:23:56 +0100 | <janus> | would be cool if the runtime was standardized too |
| 2024-03-24 14:25:39 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2024-03-24 14:27:59 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-03-24 14:29:02 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-03-24 14:29:05 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) |
| 2024-03-24 14:31:52 +0100 | CiaoSen | (~Jura@2a05:5800:2bf:a100:e6b9:7aff:fe80:3d03) |
| 2024-03-24 14:36:53 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-03-24 14:41:05 +0100 | zetef | (~quassel@2a02:2f00:500b:ce00:aba1:3782:4e7c:41a) (Remote host closed the connection) |
| 2024-03-24 14:42:38 +0100 | <Inst> | congrats on great work with MicroHS |
| 2024-03-24 14:57:19 +0100 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-03-24 14:57:46 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3140-66f9-3d68-2bb9-a4a5-c3c4.rev.sfr.net) |
| 2024-03-24 15:04:11 +0100 | wkdiwks | (~wkdiwiks2@123.63.203.210) |
| 2024-03-24 15:12:06 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2024-03-24 15:13:41 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-03-24 15:21:11 +0100 | dsrt^ | (~cd@c-98-242-74-66.hsd1.ga.comcast.net) |
| 2024-03-24 15:23:02 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-03-24 15:27:10 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) (Quit: WeeChat 4.2.1) |
| 2024-03-24 15:31:49 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3140-66f9-3d68-2bb9-a4a5-c3c4.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-24 15:32:11 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3140-66f9-3d68-2bb9-a4a5-c3c4.rev.sfr.net) |
| 2024-03-24 15:32:40 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3140-66f9-3d68-2bb9-a4a5-c3c4.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-24 15:33:45 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3140-66f9-3d68-2bb9-a4a5-c3c4.rev.sfr.net) |
| 2024-03-24 15:38:32 +0100 | wkdiwks3r | (~wkdiwiks2@212-8-253-140.hosted-by-worldstream.net) |
| 2024-03-24 15:42:00 +0100 | wkdiwks | (~wkdiwiks2@123.63.203.210) (Ping timeout: 255 seconds) |
| 2024-03-24 15:46:38 +0100 | wkdiwks3r | (~wkdiwiks2@212-8-253-140.hosted-by-worldstream.net) (Ping timeout: 268 seconds) |
| 2024-03-24 15:49:36 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-03-24 15:52:05 +0100 | AlexNoo_ | (~AlexNoo@94.233.241.36) |
| 2024-03-24 15:53:59 +0100 | AlexZenon | (~alzenon@178.34.161.9) (Ping timeout: 264 seconds) |
| 2024-03-24 15:54:02 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-03-24 15:55:38 +0100 | AlexNoo | (~AlexNoo@178.34.161.9) (Ping timeout: 264 seconds) |
| 2024-03-24 15:58:36 +0100 | AlexZenon | (~alzenon@94.233.241.36) |
| 2024-03-24 16:06:11 +0100 | tomku | (~tomku@user/tomku) |
| 2024-03-24 16:10:27 +0100 | wkdiwks3r | (~wkdiwiks2@212-8-253-140.hosted-by-worldstream.net) |
| 2024-03-24 16:12:42 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-03-24 16:13:52 +0100 | trev | (~trev@user/trev) (Quit: trev) |
| 2024-03-24 16:14:10 +0100 | trev | (~trev@user/trev) |
| 2024-03-24 16:18:45 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-03-24 16:19:43 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-03-24 16:26:37 +0100 | AlexNoo | (~AlexNoo@178.34.163.255) |
| 2024-03-24 16:28:16 +0100 | AlexZenon | (~alzenon@94.233.241.36) (Ping timeout: 268 seconds) |
| 2024-03-24 16:29:14 +0100 | AlexNoo_ | (~AlexNoo@94.233.241.36) (Ping timeout: 264 seconds) |
| 2024-03-24 16:36:15 +0100 | wkdiwks3r | (~wkdiwiks2@212-8-253-140.hosted-by-worldstream.net) (Quit: Leaving) |
| 2024-03-24 16:38:15 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) |
| 2024-03-24 16:43:05 +0100 | Square2 | (~Square4@user/square) |
| 2024-03-24 16:43:26 +0100 | euleritian | (~euleritia@dynamic-046-114-094-041.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-24 16:43:44 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-24 16:44:32 +0100 | CiaoSen | (~Jura@2a05:5800:2bf:a100:e6b9:7aff:fe80:3d03) (Ping timeout: 260 seconds) |
| 2024-03-24 16:46:54 +0100 | Square2 | (~Square4@user/square) (Remote host closed the connection) |
| 2024-03-24 16:52:06 +0100 | Square | (~Square@user/square) |
| 2024-03-24 17:02:51 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-03-24 17:02:59 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-03-24 17:03:08 +0100 | euleritian | (~euleritia@dynamic-046-114-094-041.46.114.pool.telefonica.de) |
| 2024-03-24 17:08:29 +0100 | crook1389 | (uid581388@id-581388.ilkley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-24 17:09:07 +0100 | euleritian | (~euleritia@dynamic-046-114-094-041.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-03-24 17:09:23 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-03-24 17:10:05 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-03-24 17:21:57 +0100 | AlexZenon | (~alzenon@178.34.163.255) |
| 2024-03-24 17:25:51 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2024-03-24 17:28:42 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-24 17:33:44 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 17:36:06 +0100 | leon_on9527 | (~yoyofreem@38.180.62.249) |
| 2024-03-24 17:36:15 +0100 | leon_on9527 | (~yoyofreem@38.180.62.249) (Max SendQ exceeded) |
| 2024-03-24 17:36:59 +0100 | leon_on9527 | (~yoyofreem@38.180.62.249) |
| 2024-03-24 17:39:39 +0100 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.1) |
| 2024-03-24 17:52:41 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3140-66f9-3d68-2bb9-a4a5-c3c4.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-24 18:01:13 +0100 | tzh | (~tzh@c-73-164-206-160.hsd1.or.comcast.net) |
| 2024-03-24 18:01:55 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-03-24 18:03:10 +0100 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) |
| 2024-03-24 18:03:50 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2024-03-24 18:08:00 +0100 | falafel | (~falafel@2607:fb91:8aa:877b:6056:2f11:46f2:4ba2) |
| 2024-03-24 18:09:19 +0100 | fmd | (~fmd@user/framend) |
| 2024-03-24 18:16:02 +0100 | ht_ | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-03-24 18:17:35 +0100 | _ht | (~Thunderbi@194.110.115.57) (Ping timeout: 252 seconds) |
| 2024-03-24 18:17:36 +0100 | ht_ | _ht |
| 2024-03-24 18:19:18 +0100 | <Inst> | huh, Data.Vector.foldr acts as though it's lazy? I guess it stream fuses Vecs |
| 2024-03-24 18:19:58 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-03-24 18:22:17 +0100 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Quit: Leaving) |
| 2024-03-24 18:25:38 +0100 | kuribas | (~user@ptr-17d51eofujeriaat5yx.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2024-03-24 18:36:34 +0100 | leon_on9527 | (~yoyofreem@38.180.62.249) (Leaving) |
| 2024-03-24 18:36:50 +0100 | falafel | (~falafel@2607:fb91:8aa:877b:6056:2f11:46f2:4ba2) (Ping timeout: 268 seconds) |
| 2024-03-24 18:45:42 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3141-4956-88db-6233-762e-794e.rev.sfr.net) |
| 2024-03-24 18:46:50 +0100 | YoungFrog | (~youngfrog@2a02:a03f:c9db:fc00:f708:1cd6:a732:30b) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in) |
| 2024-03-24 18:47:11 +0100 | YoungFrog | (~youngfrog@2a02:a03f:c9db:fc00:dc64:8456:22b9:2c5f) |
| 2024-03-24 18:48:02 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3141-4956-88db-6233-762e-794e.rev.sfr.net) (Remote host closed the connection) |
| 2024-03-24 18:48:08 +0100 | kuribas | (~user@ptr-17d51eofujeriaat5yx.18120a2.ip6.access.telenet.be) |
| 2024-03-24 18:48:25 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3141-4956-88db-6233-762e-794e.rev.sfr.net) |
| 2024-03-24 18:54:30 +0100 | ystael_ | (~ystael@user/ystael) (Ping timeout: 256 seconds) |
| 2024-03-24 18:54:50 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-24 18:55:41 +0100 | <kuribas> | I get an error about dependencies in flycheck, even though they are installed using cabal. I am using haskell-ghc checker, not stack. |
| 2024-03-24 18:56:12 +0100 | <geekosaur> | did you use cabal exec to run it, so it has access to the store? |
| 2024-03-24 18:56:31 +0100 | <geekosaur> | oh, that might be hard for flycheck, whoops |
| 2024-03-24 18:56:50 +0100 | <kuribas> | I ran cabal build |
| 2024-03-24 18:58:50 +0100 | <kuribas> | hmm, my flycheck version is rather old. |
| 2024-03-24 18:59:12 +0100 | kuribas | (~user@ptr-17d51eofujeriaat5yx.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2024-03-24 18:59:18 +0100 | <geekosaur> | "cabal build" doesn't matter. if flycheck is not run with … dammit |
| 2024-03-24 18:59:35 +0100 | kuribas | (~user@ptr-17d51eofujeriaat5yx.18120a2.ip6.access.telenet.be) |
| 2024-03-24 19:02:28 +0100 | TonyStone | (~TonyStone@074-076-057-186.res.spectrum.com) (Read error: Connection reset by peer) |
| 2024-03-24 19:02:34 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-03-24 19:02:46 +0100 | TonyStone | (~TonyStone@074-076-057-186.res.spectrum.com) |
| 2024-03-24 19:07:12 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 255 seconds) |
| 2024-03-24 19:13:46 +0100 | sadie_ | (~sadie@c-76-155-235-153.hsd1.co.comcast.net) |
| 2024-03-24 19:14:16 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2024-03-24 19:18:23 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli) |
| 2024-03-24 19:18:49 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-03-24 19:21:40 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 19:29:38 +0100 | Silver_X | (~Silver_X@182.178.250.244) |
| 2024-03-24 19:32:07 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) |
| 2024-03-24 19:33:16 +0100 | robobub | (uid248673@id-248673.uxbridge.irccloud.com) |
| 2024-03-24 19:33:53 +0100 | rvalue- | (~rvalue@user/rvalue) |
| 2024-03-24 19:34:48 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 268 seconds) |
| 2024-03-24 19:35:33 +0100 | kuribas | (~user@ptr-17d51eofujeriaat5yx.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2024-03-24 19:37:48 +0100 | rvalue- | rvalue |
| 2024-03-24 19:39:15 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection) |
| 2024-03-24 19:41:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-24 19:44:53 +0100 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2024-03-24 19:45:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 20:08:01 +0100 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-03-24 20:10:11 +0100 | hammond_ | (proscan@user/hammond2) |
| 2024-03-24 20:10:24 +0100 | <hammond_> | how do I get ghc to recompile all the files? |
| 2024-03-24 20:10:35 +0100 | <hammond_> | instead of the ones it thinks are updated. |
| 2024-03-24 20:10:52 +0100 | <geekosaur> | -fforce-recomp |
| 2024-03-24 20:12:36 +0100 | <hammond_> | ok thx |
| 2024-03-24 20:15:00 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) (Ping timeout: 260 seconds) |
| 2024-03-24 20:22:23 +0100 | <janus> | hammond_: if you upgrade to ghc 9.4 the check gets more reliable |
| 2024-03-24 20:32:21 +0100 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-03-24 20:41:34 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-03-24 20:42:58 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-03-24 20:44:12 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-03-24 20:47:04 +0100 | Silver_X | (~Silver_X@182.178.250.244) (Quit: Leaving) |
| 2024-03-24 20:56:17 +0100 | Guest52 | (~Guest52@185.57.29.142) |
| 2024-03-24 20:57:43 +0100 | imdoor | (~imdoor@balticom-142-78-50.balticom.lv) |
| 2024-03-24 20:59:04 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-03-24 21:00:09 +0100 | <imdoor> | heya, ghc docs on unboxed types say that "You cannot bind a variable with an unboxed type in a top-level binding." what is a top-level binding exactlyu |
| 2024-03-24 21:00:55 +0100 | <geekosaur> | anything outside a function |
| 2024-03-24 21:01:36 +0100 | <imdoor> | ok, so this doesn't apply to anything within a function (where ..., let ...) right? |
| 2024-03-24 21:01:47 +0100 | <geekosaur> | right |
| 2024-03-24 21:02:03 +0100 | <geekosaur> | https://github.com/geekosaur/xmonad.hs/blob/hilfy-2023/xmonad.hs#L62-L82 these are top level bindings |
| 2024-03-24 21:04:03 +0100 | <imdoor> | ty. i was trying to figure out why ghc gives me "You can't mix polymorphic and unlifted bindings" and thought that it might be related to that sentence in the docs, but aparently it's not the case :/ do you by any chance also know what that error means? |
| 2024-03-24 21:06:12 +0100 | <geekosaur> | an unlifted binding is a value, as opposed to a pointer to a value. in particular, it has a particular size and behavior, so it can only be described by a single type |
| 2024-03-24 21:06:26 +0100 | <geekosaur> | polymorphism requires pointers, since they're always the same size |
| 2024-03-24 21:10:41 +0100 | <geekosaur> | (if you care about the internals, see https://hackage.haskell.org/package/ghc-prim-0.11.0/docs/GHC-Types.html#t:RuntimeRep) |
| 2024-03-24 21:12:13 +0100 | <imdoor> | hmm, by what you're saying I can infer that you can't pass unlifted stuff to polymorphic functions. is the error saying that that's what I'm doing or is it something more intricate? |
| 2024-03-24 21:12:46 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-03-24 21:12:53 +0100 | <tomsmeding> | a normal type variable 'a' cannot be instantiated to an unlifted type |
| 2024-03-24 21:13:18 +0100 | <geekosaur> | ^ |
| 2024-03-24 21:13:24 +0100 | <tomsmeding> | because it is of kind Type, a.k.a. *, i.e. TYPE LiftedRep |
| 2024-03-24 21:13:50 +0100 | <tomsmeding> | whereas unlifted types are of kind TYPE UnliftedRep, if I'm not mistaken |
| 2024-03-24 21:13:53 +0100 | <tomsmeding> | hence it doesn't kind-check |
| 2024-03-24 21:14:12 +0100 | <tomsmeding> | (just like '1 :: Maybe' doesn't even get to type-checking because it doesn't even kind-check) |
| 2024-03-24 21:14:43 +0100 | <tomsmeding> | but if this was the problem I'd expect GHC to just report that the kinds do not match, not to give a user-friendly error like that |
| 2024-03-24 21:15:00 +0100 | <geekosaur> | @where paste |
| 2024-03-24 21:15:00 +0100 | <lambdabot> | Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com |
| 2024-03-24 21:15:06 +0100 | tomsmeding | was going to say just that |
| 2024-03-24 21:15:12 +0100 | <geekosaur> | can you show us the code it's complaining about? |
| 2024-03-24 21:15:21 +0100 | <tomsmeding> | if you post the entire error we can be more concrete |
| 2024-03-24 21:15:45 +0100 | <tomsmeding> | geekosaur: aren't you confusing liftedness with boxedness, though? |
| 2024-03-24 21:15:46 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-03-24 21:16:09 +0100 | <tomsmeding> | seeing as: |
| 2024-03-24 21:16:14 +0100 | <tomsmeding> | % :i GHC.Exts.UnliftedRep |
| 2024-03-24 21:16:14 +0100 | <yahb2> | type GHC.Types.UnliftedRep :: GHC.Types.RuntimeRep ; type GHC.Types.UnliftedRep = ; 'GHC.Types.BoxedRep 'GHC.Types.Unlifted :: GHC.Types.RuntimeRep ; -- Defined in ‘GHC.Types’ |
| 2024-03-24 21:16:19 +0100 | <tomsmeding> | unlifted types are boxed |
| 2024-03-24 21:17:11 +0100 | <tomsmeding> | iirc boxedness was about whether it's a pointer or a plain value, and liftedness was about whether it admitted bottoms or not -- but I may well misremember |
| 2024-03-24 21:17:17 +0100 | <geekosaur> | mm, aren't unboxed types also necessarily unlifted, and there's only one case where a type is both boxed and unlifted? |
| 2024-03-24 21:17:36 +0100 | <tomsmeding> | unboxed would imply unlifted, yes |
| 2024-03-24 21:17:38 +0100 | <geekosaur> | (one of the primitive array types iirc) |
| 2024-03-24 21:18:18 +0100 | <tomsmeding> | geekosaur: https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/primitives.html#extension-UnliftedD… |
| 2024-03-24 21:18:28 +0100 | <geekosaur> | which means UnliftedRep is something of a lie, because e.g. IntRep is also an unlifted rep |
| 2024-03-24 21:19:05 +0100 | <geekosaur> | whereas UnliftedRep is BoxedRep 'Unlifted |
| 2024-03-24 21:19:45 +0100 | <tomsmeding> | isn't the idea that all `RuntimeRep`s are unboxed except BoxedRep? |
| 2024-03-24 21:19:59 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-24 21:20:01 +0100 | <tomsmeding> | and unboxed => unlifted, but boxed =/=> lifted |
| 2024-03-24 21:20:19 +0100 | tomsmeding | is yolo'ing on half-knowledge here, apologies if I'm way off |
| 2024-03-24 21:20:44 +0100 | <tomsmeding> | % :i GHC.Exts.RuntimeRep |
| 2024-03-24 21:20:44 +0100 | <yahb2> | type GHC.Types.RuntimeRep :: * ; data GHC.Types.RuntimeRep ; = GHC.Types.VecRep GHC.Types.VecCount GHC.Types.VecElem ; | GHC.Types.TupleRep [GHC.Types.RuntimeRep] ; | GHC.Types.SumRep [GHC.Ty... |
| 2024-03-24 21:20:48 +0100 | <tomsmeding> | meh |
| 2024-03-24 21:20:55 +0100 | <tomsmeding> | % import GHC.Exts |
| 2024-03-24 21:20:55 +0100 | <yahb2> | <no output> |
| 2024-03-24 21:20:57 +0100 | <tomsmeding> | % :i RuntimeRep |
| 2024-03-24 21:20:58 +0100 | <yahb2> | type RuntimeRep :: * ; data RuntimeRep ; = VecRep VecCount VecElem ; | TupleRep [RuntimeRep] ; | SumRep [RuntimeRep] ; | BoxedRep Levity ; | IntRep ; | Int8Rep ; | Int16Rep ; | Int3... |
| 2024-03-24 21:21:25 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-03-24 21:22:50 +0100 | <imdoor> | geekosaur: here's the code https://paste.tomsmeding.com/5grR9p9V but the erorrs below are what HLS is showing me. cabal build gives me only a single error "Couldn't match expected type ‘p1’ ..." |
| 2024-03-24 21:23:23 +0100 | <tomsmeding> | you can probably make ghc give the same errors as HLS by passing -fdefer-type-errors |
| 2024-03-24 21:25:53 +0100 | <imdoor> | yup, that gave me the same errors |
| 2024-03-24 21:26:08 +0100 | <tomsmeding> | what is unST, is that `unST (ST f) = f`? |
| 2024-03-24 21:26:54 +0100 | <imdoor> | unST is defined on line 34 – unST (GHCST.ST f) = f |
| 2024-03-24 21:27:03 +0100 | tomsmeding | is blind |
| 2024-03-24 21:27:09 +0100 | <tomsmeding> | thx |
| 2024-03-24 21:27:42 +0100 | <tomsmeding> | what happens if you rewrite f in sealST2 to read `f env = case unST action env of (# env', Stream step state #) -> ...` |
| 2024-03-24 21:27:59 +0100 | <geekosaur> | right, you have an unboxed tuple with a forall-ed type variable "a" in its type (I assume ScopedTypeVariables is in play or that has even bigger problems), and similarly for "r" in the second one |
| 2024-03-24 21:28:11 +0100 | <tomsmeding> | you'll need to put step' in a let binding inside that case clause or give it 'step' as an additional parameter |
| 2024-03-24 21:28:24 +0100 | <imdoor> | scoped type variables are indeed enabled |
| 2024-03-24 21:30:02 +0100 | <tomsmeding> | I like the borked formatting of that "No skolem info" error |
| 2024-03-24 21:31:56 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800:a348:5b9b:d1d8:430e) |
| 2024-03-24 21:32:28 +0100 | <tomsmeding> | geekosaur: I'm wondering why that would be a problem, if that's it |
| 2024-03-24 21:33:02 +0100 | <ph88> | When i have a function like newtype Foo a = Foo {getFoo :: ((Boolean GHC.Generics.:+: Integer) a)} what does that mean with the :+: ? |
| 2024-03-24 21:33:23 +0100 | <geekosaur> | Actually I was wondering wouldn't that imply boxed and therefore pointers |
| 2024-03-24 21:33:36 +0100 | <geekosaur> | So yeah I'm kind of confused too |
| 2024-03-24 21:33:56 +0100 | <tomsmeding> | ph88: data (f :+: g) p = L1 (f p) | R1 (g p) |
| 2024-03-24 21:33:59 +0100 | <geekosaur> | But I'm not noticing anything else that would trigger it |
| 2024-03-24 21:34:10 +0100 | <tomsmeding> | it's the same as Data.Functor.Sum.Sum |
| 2024-03-24 21:34:38 +0100 | <imdoor> | oh, wow, that `f env = case unST action ...` worked, thanks! now i only have to wrap my head around why |
| 2024-03-24 21:34:50 +0100 | <imdoor> | it compiles now without issue |
| 2024-03-24 21:34:55 +0100 | <tomsmeding> | geekosaur: exactly, but even more, Stream is a normal data type (presumably) and is itself hence a pointer |
| 2024-03-24 21:34:56 +0100 | zetef | (~quassel@5.2.182.98) |
| 2024-03-24 21:35:07 +0100 | <tomsmeding> | so the 'a' is inside a heap-allocated thing to which the unboxed tuple only contains a pointer! |
| 2024-03-24 21:35:14 +0100 | <tomsmeding> | why would it care about what's in there? |
| 2024-03-24 21:35:24 +0100 | <tomsmeding> | imdoor: nice! |
| 2024-03-24 21:35:25 +0100 | <ph88> | tomsmeding, what is this used for? or what is Data.Functor.Sum.Sum used for? when do you want to use such code ? |
| 2024-03-24 21:36:10 +0100 | <tomsmeding> | imdoor: I'm not sure either, but experience tells me that in general, if you're dealing with "special" things (i.e. not normal boxed-lifted things, but unlifted things, or unboxed things, etc.), 'case' works as expected and let/where are sometimes weird |
| 2024-03-24 21:36:36 +0100 | <tomsmeding> | the same holds for LinearTypes, but there I have something of an idea of why |
| 2024-03-24 21:36:47 +0100 | JackM | (~JackM@2601:203:4301:ef30:b53d:4e54:709a:73cb) |
| 2024-03-24 21:37:09 +0100 | <tomsmeding> | ph88: when you want Either but of things that take another type parameter :p |
| 2024-03-24 21:37:21 +0100 | <tomsmeding> | and for some reason you don't want to just create a small data type for it |
| 2024-03-24 21:37:57 +0100 | <tomsmeding> | the use in GHC.Generics is weird, see the docs, I'm not sure the p parameter is ever even used |
| 2024-03-24 21:38:13 +0100 | <tomsmeding> | but in general Sum (also Data.Functor.Product.Product) can be helpful |
| 2024-03-24 21:38:45 +0100 | <tomsmeding> | it's most useful when you need to pass something of kind (* -> *) as a type argument to something else |
| 2024-03-24 21:39:18 +0100 | <tomsmeding> | but you want that thing to be a sum of two other things, and you can't write `\t -> Either (F t) (G t)` because type-level lambdas aren't a thing in haskell |
| 2024-03-24 21:39:22 +0100 | <tomsmeding> | but `Sum F G` is |
| 2024-03-24 21:40:38 +0100 | zetef | (~quassel@5.2.182.98) (Ping timeout: 264 seconds) |
| 2024-03-24 21:40:41 +0100 | son0p | (~ff@152.203.80.45) (Quit: Bye) |
| 2024-03-24 21:42:43 +0100 | <imdoor> | tomsmeding: good to know. I tend to stick to the "normal" stuff but needing to get rid of that ST s in the Stream type had me digging under the hood a bit more than usually :D |
| 2024-03-24 21:44:30 +0100 | <tomsmeding> | imdoor: in general, 'let' (/where) is lazy: it only becomes strict if you combine it with BangPatterns. That has something to do with it. 'case' is strict because it has to be; you can make it lazy using "irrefutable" patterns (using ~). |
| 2024-03-24 21:45:03 +0100 | <tomsmeding> | are you liking your #? :p |
| 2024-03-24 21:47:49 +0100 | sadie_ | (~sadie@c-76-155-235-153.hsd1.co.comcast.net) (Remote host closed the connection) |
| 2024-03-24 21:50:22 +0100 | JackM | (~JackM@2601:203:4301:ef30:b53d:4e54:709a:73cb) (Quit: Client closed) |
| 2024-03-24 21:54:24 +0100 | <janus> | are there any packages that can help me schedule continuations without using green threading? |
| 2024-03-24 22:00:24 +0100 | <dolio> | case isn't actually strict in general (unless you're talking about core). Like, evaluating `case expr of x -> 5` does not evaluate `expr`. |
| 2024-03-24 22:02:45 +0100 | <imdoor> | tomsmeding: yea, had to first google wth those # actually even mean :D |
| 2024-03-24 22:07:43 +0100 | fmd | (~fmd@user/framend) (Ping timeout: 260 seconds) |
| 2024-03-24 22:16:08 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-03-24 22:19:58 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-03-24 22:21:33 +0100 | <tomsmeding> | dolio: that's true |
| 2024-03-24 22:21:52 +0100 | <tomsmeding> | but if you `case expr of A -> 5` then that's strict in 'expr', whereas `let A = expr in 5` is not |
| 2024-03-24 22:22:18 +0100 | <tomsmeding> | I'm not sure this has very much to do with it -- it is what leads to 'case' working much better with LinearTypes |
| 2024-03-24 22:28:38 +0100 | <ph88> | tomsmeding, thanks for the explanation i'll make a note |
| 2024-03-24 22:33:34 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-03-24 22:35:52 +0100 | dcoutts_ | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2024-03-24 22:39:06 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 260 seconds) |
| 2024-03-24 22:39:47 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-03-24 22:45:30 +0100 | <edmundnoble_> | I've just noticed that setting the `--builddir` cabal option results in a rebuild unconditionally because this counts as a "configuration change" for my packages. Is there any way to circumvent that? I'm trying to implement a layer of build dir caching for a VCS. |
| 2024-03-24 22:46:04 +0100 | son0p | (~ff@152.203.80.45) |
| 2024-03-24 22:47:15 +0100 | <edmundnoble_> | Seems completely broken to me |
| 2024-03-24 22:48:54 +0100 | <tomsmeding> | edmundnoble_: isn't that the directory where the cached files ought to be put in the first place? |
| 2024-03-24 22:49:16 +0100 | <tomsmeding> | or are you saying that if you `cabal build --builddir` twice then the second time doesn't use the artifacts from the first time? |
| 2024-03-24 22:49:50 +0100 | <tomsmeding> | if so that sounds like a bug |
| 2024-03-24 22:50:54 +0100 | <c_wraith> | possibly saying that if they build packages A and B from source, and B depends on A, then changing only --builddir on A causes B to rebuild? |
| 2024-03-24 22:51:07 +0100 | <edmundnoble_> | I'm saying that if I change --builddir from the last time I ran cabal, I get a rebuild |
| 2024-03-24 22:51:15 +0100 | <c_wraith> | oh. well what else could it do? |
| 2024-03-24 22:51:18 +0100 | <edmundnoble_> | It doesn't matter if the place I've set --builddir to happens to contain cached files |
| 2024-03-24 22:51:36 +0100 | <edmundnoble_> | What I would assume is that if I already have a builddir that contains the entire built project, there would be no rebuild |
| 2024-03-24 22:51:51 +0100 | <geekosaur> | it has no way of knowing if those cached files correspond to the current sources |
| 2024-03-24 22:52:00 +0100 | tomsmeding | wonders where "the current" builddir is stored |
| 2024-03-24 22:52:07 +0100 | <edmundnoble_> | I'd assume it would check in the exact same way it checks ordinarily |
| 2024-03-24 22:52:08 +0100 | <geekosaur> | and it could only find out by rebuilding them anyway |
| 2024-03-24 22:52:23 +0100 | <edmundnoble_> | Why does it matter if I've changed --builddir? Either way cabal has to determine what to rebuild |
| 2024-03-24 22:52:24 +0100 | <tomsmeding> | doesn't cabal store hashes of source files it has compiled |
| 2024-03-24 22:52:56 +0100 | <tomsmeding> | otherwise how can it not do anything if I re-write a file without changing the content |
| 2024-03-24 22:53:52 +0100 | <edmundnoble_> | Exactly |
| 2024-03-24 22:55:40 +0100 | <geekosaur> | it does, but the hash includes the builddir |
| 2024-03-24 22:56:34 +0100 | <edmundnoble_> | It does? Why? |
| 2024-03-24 22:56:44 +0100 | <edmundnoble_> | Well that puts a wrench in my plans... |
| 2024-03-24 22:57:25 +0100 | <geekosaur> | I _think_ because there are situations (TH?) where it can end up embedded, but I'm not sure |
| 2024-03-24 22:57:32 +0100 | <geekosaur> | probably best to ask in #hackage |
| 2024-03-24 22:57:44 +0100 | <edmundnoble_> | Alright thanks, I'll check it out |
| 2024-03-24 22:58:12 +0100 | <geekosaur> | might also get involved in Pathds_ pkgname but that's a trainwreck anyway |
| 2024-03-24 22:58:25 +0100 | <geekosaur> | Paths_ pkgname |
| 2024-03-24 22:59:23 +0100 | <c_wraith> | edmundnoble_: fwiw, I can't repro |
| 2024-03-24 22:59:27 +0100 | <geekosaur> | (getting it to behave sensibly with both "cabal build"ed and installed packages is … a pain |
| 2024-03-24 22:59:41 +0100 | <edmundnoble_> | Oh fuck is this because I'm using build-type custom |
| 2024-03-24 22:59:43 +0100 | <edmundnoble_> | Rip... |
| 2024-03-24 23:01:02 +0100 | <tomsmeding> | oh, it may well be |
| 2024-03-24 23:01:40 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-03-24 23:01:49 +0100 | <c_wraith> | I'm definitely seeing that it's happy to re-use build products in different builddirs with build-type Simple |
| 2024-03-24 23:03:19 +0100 | <edmundnoble_> | Hm, that's not what I see, even if I use Simple... |
| 2024-03-24 23:03:33 +0100 | <edmundnoble_> | Hm |
| 2024-03-24 23:03:35 +0100 | <geekosaur> | what versions of cabal-install for both of you? |
| 2024-03-24 23:03:43 +0100 | <c_wraith> | 3.10.3.0 |
| 2024-03-24 23:03:55 +0100 | <edmundnoble_> | 3.10.1.0 |
| 2024-03-24 23:04:24 +0100 | <edmundnoble_> | Actually I'm mistaken. It's fine with doing that. What it's not fine with is me hardlinking all of the files in the builddir into a new builddir, and using those files |
| 2024-03-24 23:04:42 +0100 | <tomsmeding> | is it fine if you copy them instead of hardlinking? |
| 2024-03-24 23:04:43 +0100 | <edmundnoble_> | So it sounds like the hash does include the builddir as geekosaur said |
| 2024-03-24 23:04:47 +0100 | <edmundnoble_> | I can try that |
| 2024-03-24 23:04:59 +0100 | <tomsmeding> | (unlikely) |
| 2024-03-24 23:05:11 +0100 | <edmundnoble_> | Nah same thing |
| 2024-03-24 23:05:15 +0100 | <c_wraith> | hardlinking creates new metadata, right? |
| 2024-03-24 23:05:16 +0100 | <edmundnoble_> | Yeah it was a long shot |
| 2024-03-24 23:05:22 +0100 | <c_wraith> | if it's looking at modification times... |
| 2024-03-24 23:05:27 +0100 | <geekosaur> | I'm running HEAD as of yesterday, just copied dist-newstyle to dist-hack and used n--builddir=dist-hack, it's rebuilding everything with [Flags changed] |
| 2024-03-24 23:05:30 +0100 | <edmundnoble_> | It's complaining "configuration changed" |
| 2024-03-24 23:05:48 +0100 | <edmundnoble_> | Yeah it really does seem like the builddir path is in the artifacts |
| 2024-03-24 23:06:09 +0100 | <c_wraith> | It's possible you've got something more complex going on than my test case. |
| 2024-03-24 23:06:26 +0100 | <c_wraith> | are you using a Paths_ module to access data files? |
| 2024-03-24 23:06:42 +0100 | <edmundnoble_> | There is a Paths_ module yes |
| 2024-03-24 23:06:55 +0100 | <c_wraith> | that does get hardcoded to the build dir. |
| 2024-03-24 23:07:05 +0100 | <c_wraith> | (it can be overridden, but the default has to be hardcoded in) |
| 2024-03-24 23:07:36 +0100 | <edmundnoble_> | What exactly is your test again? If your test has been "switching between builddirs doesn't trigger rebuilds" then I can see that too, yes. |
| 2024-03-24 23:08:01 +0100 | <c_wraith> | yeah, I started as simple as I could |
| 2024-03-24 23:08:17 +0100 | <geekosaur> | hmmm… this isn't cabal's fault I think |
| 2024-03-24 23:08:27 +0100 | <geekosaur> | it's ghc that is complaining that things changed |
| 2024-03-24 23:08:34 +0100 | <geekosaur> | in my test |
| 2024-03-24 23:09:18 +0100 | <mauke> | hardlinking = creating new names for existing files |
| 2024-03-24 23:09:34 +0100 | <geekosaur> | although the first package is build-type Configure and that got re-run, so cabal may still be instigating it |
| 2024-03-24 23:09:49 +0100 | <mauke> | in fact, a "hard link" is just another name for a name |
| 2024-03-24 23:10:26 +0100 | <edmundnoble_> | I do see "flags changed" but only after cabal already said "configuration changed" |
| 2024-03-24 23:10:31 +0100 | <shapr> | @quote |
| 2024-03-24 23:10:32 +0100 | <lambdabot> | stepcut says: how can you possibly implement business logic without knowing about Schonfinkel!? |
| 2024-03-24 23:11:14 +0100 | <monochrom> | haha |
| 2024-03-24 23:13:00 +0100 | CiaoSen | (~Jura@2a05:5800:2bf:a100:e6b9:7aff:fe80:3d03) |
| 2024-03-24 23:14:35 +0100 | <edmundnoble_> | I'm starting to think you're right geekosaur, "configuration changed" isn't sufficient to just ignore the cached build artifacts, based on the earlier test c_wraith and I did |
| 2024-03-24 23:22:20 +0100 | mmhat | (~mmh@p200300f1c706a252ee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-03-24 23:30:34 +0100 | baghead | (~baghead@cpc91312-watf11-2-0-cust1213.15-2.cable.virginm.net) |
| 2024-03-24 23:35:03 +0100 | <edmundnoble_> | There's an -optP argument set to a location in the builddir, for cabal_macros.h, and an -I argument for the autogen dir in the builddir. Those are enough to be a problem, per the GHC docs saying that they're used to compute whether to rebuild. |
| 2024-03-24 23:35:13 +0100 | <edmundnoble_> | I see that the package-db flag is set to be in the builddir too, idk if that's an issue, less likely I think |
| 2024-03-24 23:39:53 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-03-24 23:40:44 +0100 | imdoor | (~imdoor@balticom-142-78-50.balticom.lv) (Quit: imdoor) |
| 2024-03-24 23:50:54 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-03-24 23:53:39 +0100 | <edmundnoble_> | I don't see a way to disable cabal_macros.h or the autogen folder, am I missing it? I tried build-type: Simple and build-type: Configure |
| 2024-03-24 23:53:58 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) |
| 2024-03-24 23:55:27 +0100 | <geekosaur> | it's triggered by use of autogen-modules: |
| 2024-03-24 23:56:15 +0100 | <geekosaur> | hm, cabal-macros.h may always be on though, since cabal would have to inspect all the source files for CPP to know if it's needed |
| 2024-03-24 23:57:11 +0100 | <geekosaur> | (cabal-macros.h contains the definitions of the MIN_VERSION_ package macros for all dependencies of the current package) |
| 2024-03-24 23:58:06 +0100 | <edmundnoble_> | Yeah I deleted autogen-modules and it stuck around |
| 2024-03-24 23:59:06 +0100 | <edmundnoble_> | Looks like a https://github.com/haskell/cabal/blob/23a684098e1f013ab72372f26f38ed9d298ce563/Cabal/src/Distribut… thing |
| 2024-03-24 23:59:48 +0100 | TonyStone | (~TonyStone@074-076-057-186.res.spectrum.com) (Remote host closed the connection) |