| 2023-10-02 00:03:35 +0200 | vglfr | (~vglfr@88.155.18.75) (Ping timeout: 240 seconds) |
| 2023-10-02 00:06:17 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-10-02 00:11:52 +0200 | Square2 | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2023-10-02 00:14:16 +0200 | <ghoulguy> | madnight: probably not without you downloading a bunch of stuff or using a search engine |
| 2023-10-02 00:15:49 +0200 | <geekosaur> | I was surprised to find hoogle didn't support that |
| 2023-10-02 00:18:33 +0200 | captnemo | (~captnemo@193.32.127.239) (Quit: WeeChat 4.0.4) |
| 2023-10-02 00:18:50 +0200 | captnemo | (~captnemo@193.32.127.239) |
| 2023-10-02 00:27:46 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-10-02 00:27:46 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-02 00:30:39 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection) |
| 2023-10-02 00:32:15 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-10-02 00:34:49 +0200 | bilegeek | (~bilegeek@2600:1008:b0aa:d121:12f8:f5f4:a6fd:d8ea) |
| 2023-10-02 00:36:33 +0200 | bgamari_ | (~bgamari@64.223.173.10) |
| 2023-10-02 00:36:44 +0200 | bgamari | (~bgamari@70.16.98.14) (Ping timeout: 245 seconds) |
| 2023-10-02 00:46:12 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-10-02 00:52:05 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) |
| 2023-10-02 01:00:36 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-10-02 01:00:36 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-10-02 01:00:36 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-02 01:01:53 +0200 | wroathe | (~wroathe@user/wroathe) (Client Quit) |
| 2023-10-02 01:02:06 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-10-02 01:02:07 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-10-02 01:02:07 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-02 01:20:39 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds) |
| 2023-10-02 01:21:52 +0200 | NinjaTrappeur | (~ninja@about/aquilenet/vodoo/NinjaTrappeur) (Ping timeout: 252 seconds) |
| 2023-10-02 01:22:35 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection) |
| 2023-10-02 01:22:57 +0200 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2023-10-02 01:23:13 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) |
| 2023-10-02 01:26:57 +0200 | NinjaTrappeur | (~ninja@about/aquilenet/vodoo/NinjaTrappeur) |
| 2023-10-02 01:45:28 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-02 02:00:11 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 255 seconds) |
| 2023-10-02 02:05:58 +0200 | spacenautx | (~spacenaut@user/spacenautx) (Quit: WeeChat 4.0.5) |
| 2023-10-02 02:15:13 +0200 | arahael | (~arahael@1.145.14.170) |
| 2023-10-02 02:26:49 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection) |
| 2023-10-02 02:32:16 +0200 | danza_ | (~francesco@151.47.126.103) |
| 2023-10-02 02:35:11 +0200 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-10-02 02:41:57 +0200 | dolio | (~dolio@130.44.134.54) |
| 2023-10-02 02:45:51 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 258 seconds) |
| 2023-10-02 02:46:00 +0200 | czy | (~user@121.231.44.109) |
| 2023-10-02 02:47:26 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-02 02:47:43 +0200 | danza_ | (~francesco@151.47.126.103) (Ping timeout: 264 seconds) |
| 2023-10-02 02:48:21 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-10-02 02:48:59 +0200 | arahael | (~arahael@1.145.14.170) (Quit: "Gotta run!") |
| 2023-10-02 02:49:41 +0200 | czy | (~user@121.231.44.109) (Remote host closed the connection) |
| 2023-10-02 02:59:28 +0200 | czy | (~user@121.231.44.109) |
| 2023-10-02 03:04:43 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) |
| 2023-10-02 03:06:01 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 2023-10-02 03:11:29 +0200 | cifrlltb^ | (~cd@76.145.193.217) (Remote host closed the connection) |
| 2023-10-02 03:24:07 +0200 | captnemo | (~captnemo@193.32.127.239) (Quit: WeeChat 4.0.4) |
| 2023-10-02 03:31:53 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-10-02 03:32:28 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection) |
| 2023-10-02 03:32:43 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) |
| 2023-10-02 03:33:28 +0200 | otto_s | (~user@p5de2facb.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-10-02 03:34:58 +0200 | otto_s | (~user@p5b0445cd.dip0.t-ipconnect.de) |
| 2023-10-02 03:41:55 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving) |
| 2023-10-02 03:42:07 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2023-10-02 04:06:05 +0200 | td_ | (~td@i5387090d.versanet.de) (Ping timeout: 272 seconds) |
| 2023-10-02 04:07:12 +0200 | td_ | (~td@i5387092A.versanet.de) |
| 2023-10-02 04:07:40 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds) |
| 2023-10-02 04:17:32 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-10-02 04:17:32 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-10-02 04:17:32 +0200 | finn_elija | FinnElija |
| 2023-10-02 04:30:48 +0200 | vglfr | (~vglfr@88.154.40.15) |
| 2023-10-02 04:35:07 +0200 | vglfr | (~vglfr@88.154.40.15) (Ping timeout: 255 seconds) |
| 2023-10-02 05:03:51 +0200 | td_ | (~td@i5387092A.versanet.de) (Ping timeout: 260 seconds) |
| 2023-10-02 05:05:17 +0200 | td_ | (~td@i5387090C.versanet.de) |
| 2023-10-02 05:12:19 +0200 | asivitz | (uid178348@id-178348.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-02 05:21:05 +0200 | bilegeek | (~bilegeek@2600:1008:b0aa:d121:12f8:f5f4:a6fd:d8ea) (Remote host closed the connection) |
| 2023-10-02 05:22:04 +0200 | Warr | (~Admin1@47.200.75.232) |
| 2023-10-02 05:23:52 +0200 | srk | (~sorki@user/srk) (Remote host closed the connection) |
| 2023-10-02 05:24:11 +0200 | srk | (~sorki@user/srk) |
| 2023-10-02 05:24:51 +0200 | Warr | (~Admin1@47.200.75.232) (Remote host closed the connection) |
| 2023-10-02 05:31:43 +0200 | cptaffe | (~cptaffe@user/cptaffe) (Remote host closed the connection) |
| 2023-10-02 05:32:03 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 05:34:22 +0200 | cptaffe | (~cptaffe@user/cptaffe) |
| 2023-10-02 05:36:32 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 255 seconds) |
| 2023-10-02 05:37:50 +0200 | vglfr | (~vglfr@88.155.145.28) |
| 2023-10-02 05:41:02 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds) |
| 2023-10-02 05:54:58 +0200 | aforemny_ | (~aforemny@2001:9e8:6cea:5700:875:b49a:e016:4759) |
| 2023-10-02 05:56:21 +0200 | aforemny | (~aforemny@2001:9e8:6cc3:2d00:4daa:999d:f37:1162) (Ping timeout: 260 seconds) |
| 2023-10-02 05:58:55 +0200 | sabino | (~sabino@user/sabino) (Quit: Lambda _ -> x) |
| 2023-10-02 06:00:04 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 272 seconds) |
| 2023-10-02 06:01:32 +0200 | actioninja | (~actioninj@user/actioninja) |
| 2023-10-02 06:05:26 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (Ping timeout: 255 seconds) |
| 2023-10-02 06:06:26 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 06:07:52 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-10-02 06:10:33 +0200 | krei-se | (~krei-se@p50874770.dip0.t-ipconnect.de) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-10-02 06:11:10 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 252 seconds) |
| 2023-10-02 06:12:11 +0200 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2023-10-02 06:16:16 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 06:18:16 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2023-10-02 06:20:04 +0200 | _xor | (~xor@ip-50-5-233-250.dynamic.fuse.net) (Quit: Ping timeout (120 seconds)) |
| 2023-10-02 06:20:39 +0200 | _xor | (~xor@ip-50-5-233-250.dynamic.fuse.net) |
| 2023-10-02 06:25:48 +0200 | cptaffe | (~cptaffe@user/cptaffe) (Remote host closed the connection) |
| 2023-10-02 06:27:31 +0200 | cptaffe | (~cptaffe@user/cptaffe) |
| 2023-10-02 06:29:29 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-02 06:34:20 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 248 seconds) |
| 2023-10-02 06:35:44 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2023-10-02 06:37:31 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-10-02 06:37:44 +0200 | michalz | (~michalz@185.246.204.125) |
| 2023-10-02 06:52:54 +0200 | qqq | (~qqq@92.43.167.61) |
| 2023-10-02 06:53:38 +0200 | xff0x | (~xff0x@2405:6580:b080:900:b248:55c0:81a8:90d4) (Remote host closed the connection) |
| 2023-10-02 06:53:57 +0200 | xff0x | (~xff0x@2405:6580:b080:900:2499:90fc:2915:781d) |
| 2023-10-02 06:59:43 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 07:04:13 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 258 seconds) |
| 2023-10-02 07:12:09 +0200 | Jackneill | (~Jackneill@20014C4E1E13B20020A43670487A9903.dsl.pool.telekom.hu) |
| 2023-10-02 07:17:49 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-10-02 07:24:40 +0200 | chomwitt | (~chomwitt@2a02:587:7a24:b000:1ac0:4dff:fedb:a3f1) |
| 2023-10-02 07:29:39 +0200 | krei-se | (~krei-se@p50874770.dip0.t-ipconnect.de) |
| 2023-10-02 07:33:09 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 07:37:48 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 248 seconds) |
| 2023-10-02 07:39:23 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2023-10-02 07:43:24 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-10-02 07:48:09 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 252 seconds) |
| 2023-10-02 07:57:56 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-10-02 07:58:22 +0200 | vglfr | (~vglfr@88.155.145.28) (Ping timeout: 260 seconds) |
| 2023-10-02 08:00:42 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 08:01:37 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-10-02 08:04:03 +0200 | lockywolf | (~lockywolf@public.lockywolf.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-10-02 08:05:01 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 252 seconds) |
| 2023-10-02 08:05:39 +0200 | lockywolf | (~lockywolf@public.lockywolf.net) |
| 2023-10-02 08:06:05 +0200 | vglfr | (~vglfr@88.155.249.83) |
| 2023-10-02 08:06:41 +0200 | vglfr | (~vglfr@88.155.249.83) (Remote host closed the connection) |
| 2023-10-02 08:08:16 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 08:09:39 +0200 | vglfr | (~vglfr@88.155.249.83) |
| 2023-10-02 08:12:52 +0200 | raym | (~ray@user/raym) |
| 2023-10-02 08:17:58 +0200 | <haskellbridge> | <tewuzij> What is Hoogle? |
| 2023-10-02 08:20:08 +0200 | <haskellbridge> | <jade> a search engine for haskell functions in packages indexed on hackage |
| 2023-10-02 08:20:51 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 08:22:25 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds) |
| 2023-10-02 08:25:22 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 252 seconds) |
| 2023-10-02 08:28:23 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 08:29:07 +0200 | <haskellbridge> | <sm> @where hoogle |
| 2023-10-02 08:32:24 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2023-10-02 08:32:47 +0200 | marinelli | (~weechat@gateway/tor-sasl/marinelli) |
| 2023-10-02 08:33:48 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-10-02 08:38:55 +0200 | simendsjo | (~user@84.211.91.241) |
| 2023-10-02 08:39:39 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:2aaa:42ea:b9cc:3d82) |
| 2023-10-02 08:40:04 +0200 | simendsjo | (~user@84.211.91.241) (Remote host closed the connection) |
| 2023-10-02 08:44:38 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2023-10-02 08:45:00 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-10-02 08:48:58 +0200 | simendsjo | (~user@84.211.91.241) |
| 2023-10-02 08:51:10 +0200 | euleritian | (~euleritia@185.238.219.110) (Ping timeout: 255 seconds) |
| 2023-10-02 08:53:13 +0200 | euleritian | (~euleritia@185.238.219.66) |
| 2023-10-02 08:55:04 +0200 | Guest5851 | (~Guest58@ext-1-173.eduroam.chalmers.se) |
| 2023-10-02 08:56:41 +0200 | <Guest5851> | Hi! The documentations for rewrite rules state that if more than one rule has a matching LHS, GHC will pick a rule arbitrarily to apply. I just want to verify that this means that if I have the two rules `f True = False` and `forall b . f b = b`, I can not be sure that `f True` will be rewritten to `False`? I should not consider these LHS's as I |
| 2023-10-02 08:56:42 +0200 | <Guest5851> | would have my pattern matches? |
| 2023-10-02 08:56:52 +0200 | <Guest5851> | A bit of a contrived example, but I think it makes my question clear |
| 2023-10-02 09:03:28 +0200 | vglfr | (~vglfr@88.155.249.83) (Ping timeout: 255 seconds) |
| 2023-10-02 09:03:39 +0200 | <probie> | Yes. However, like inlining, you can explicitly specify which phase the rule is allowed to fire in, effectively giving precedence. |
| 2023-10-02 09:08:16 +0200 | <dminuoso> | Guest5851: Also checkout CONLIKE, which gives further indirect control. |
| 2023-10-02 09:12:02 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-10-02 09:12:06 +0200 | CiaoSen | (~Jura@2a05:5800:2a3:5900:664b:f0ff:fe37:9ef) |
| 2023-10-02 09:13:48 +0200 | <tomsmeding> | sm: lambdabot doesn't pick that up because your message starts with "<sm>" here :p |
| 2023-10-02 09:15:08 +0200 | <haskellbridge> | <sm> I figured.. I'm hoping it will trigger a humanbot to complete the request 🤖😀 |
| 2023-10-02 09:15:25 +0200 | <tomsmeding> | @where hoogle |
| 2023-10-02 09:15:25 +0200 | <lambdabot> | https://hoogle.haskell.org |
| 2023-10-02 09:16:10 +0200 | <tomsmeding> | % putStr "@where hoogle" -- sm |
| 2023-10-02 09:16:10 +0200 | <yahb2> | @where hoogle |
| 2023-10-02 09:16:10 +0200 | <lambdabot> | https://hoogle.haskell.org |
| 2023-10-02 09:17:26 +0200 | <haskellbridge> | <sm> > Hoogle is a Haskell API search engine, which allows you to search the Haskell libraries on Stackage by either function name, or by approximate type signature. |
| 2023-10-02 09:32:14 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds) |
| 2023-10-02 09:39:43 +0200 | kuribas | (~user@2a02:1808:4:8d81:4e29:dcbe:5b1e:d8a2) |
| 2023-10-02 09:40:24 +0200 | <kuribas> | Is it possible to turn multithreading off for accellerate-native? |
| 2023-10-02 09:40:29 +0200 | <kuribas> | I mean without turning it off globally, so I could still use multiple threads elsewhere. |
| 2023-10-02 09:42:07 +0200 | <tomsmeding> | kuribas: before I think about whether you can, _why_ :p |
| 2023-10-02 09:44:09 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 09:44:23 +0200 | <tomsmeding> | kuribas: if you're okay with pinning the accelerate-llvm-native thread to a single core, check out createTarget and run*With |
| 2023-10-02 09:45:26 +0200 | <tomsmeding> | kuribas: read the module documentation block https://hackage.haskell.org/package/accelerate-llvm-native-1.3.0.0/docs/Data-Array-Accelerate-LLVM… |
| 2023-10-02 09:45:28 +0200 | <tomsmeding> | RTFM ;) |
| 2023-10-02 09:47:10 +0200 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-10-02 09:47:43 +0200 | Guest5851 | (~Guest58@ext-1-173.eduroam.chalmers.se) (Quit: Connection closed) |
| 2023-10-02 09:49:44 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-10-02 09:52:33 +0200 | <kuribas> | tomsmeding: ah right, runNWith should do the trick. |
| 2023-10-02 09:52:47 +0200 | <tomsmeding> | kuribas: check the env var |
| 2023-10-02 09:53:31 +0200 | danse-nr3 | (~francesco@ge-19-121-23.service.infuturo.it) |
| 2023-10-02 09:53:33 +0200 | <tomsmeding> | that's without core pinning |
| 2023-10-02 09:54:36 +0200 | rgw | (~R@2605:a601:a0df:5600:11bb:2f6e:7e71:f82c) (Read error: Connection reset by peer) |
| 2023-10-02 09:54:46 +0200 | <kuribas> | tomsmeding: the reason I want to do this is because I want to run it on streams of relatively small blocks. |
| 2023-10-02 09:54:54 +0200 | <tomsmeding> | ah |
| 2023-10-02 09:54:59 +0200 | <kuribas> | And keep the cores ready for other paralellism. |
| 2023-10-02 09:55:21 +0200 | <kuribas> | I don't think multiple threads makes much sense for small blocks (a few kbs). |
| 2023-10-02 09:55:32 +0200 | <tomsmeding> | I mean, always benchmark |
| 2023-10-02 09:55:36 +0200 | <tomsmeding> | but sounds reasonable |
| 2023-10-02 09:55:56 +0200 | <kuribas> | true, maybe I am premature optimizing... |
| 2023-10-02 09:55:58 +0200 | <tomsmeding> | depends on what you are doing with those small blocks :) |
| 2023-10-02 09:56:45 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-10-02 09:57:13 +0200 | <kuribas> | mostly downsampling aggregations. |
| 2023-10-02 09:57:27 +0200 | <kuribas> | like adding, averaging, removing or interpolating NaNs... |
| 2023-10-02 09:57:45 +0200 | <tomsmeding> | doesn't sound terribly expensive |
| 2023-10-02 09:59:35 +0200 | <kuribas> | it isn't, but I am hoping the SIMD vectorization still gives a speedup. |
| 2023-10-02 09:59:36 +0200 | euleritian | (~euleritia@185.238.219.66) (Ping timeout: 260 seconds) |
| 2023-10-02 10:00:03 +0200 | <kuribas> | Mostly by removing multiple loops, for example when applying some scale on the data. |
| 2023-10-02 10:00:14 +0200 | <tomsmeding> | right, that it should do at the very least |
| 2023-10-02 10:00:21 +0200 | <tomsmeding> | after that it's up to LLVM to do smart SIMD things |
| 2023-10-02 10:00:34 +0200 | <tomsmeding> | i.e. not very different from having written decent C code for this |
| 2023-10-02 10:00:53 +0200 | <kuribas> | Indeed, that is the goal, but dynamically at runtime. |
| 2023-10-02 10:05:49 +0200 | <kuribas> | So I can write a query on timeseries, and it will be compiled and cached at runtime. |
| 2023-10-02 10:06:06 +0200 | <kuribas> | Without the need to recompile and restart the whole application |
| 2023-10-02 10:06:07 +0200 | yahb2 | (~yahb2@static.56.27.47.78.clients.your-server.de) (Remote host closed the connection) |
| 2023-10-02 10:06:19 +0200 | yahb2 | (~yahb2@2a01:4f8:c0c:5c7b::2) |
| 2023-10-02 10:06:24 +0200 | <tomsmeding> | neat |
| 2023-10-02 10:06:26 +0200 | euleritian | (~euleritia@185.238.219.3) |
| 2023-10-02 10:06:57 +0200 | <kuribas> | I saw the polars library in rust, which does optimizations, but it cannot do loop fusion (at least in Python), because it doesn't do JIT compilation. |
| 2023-10-02 10:07:29 +0200 | <tomsmeding> | ... is that a rust or a python lib? I'm confused |
| 2023-10-02 10:07:37 +0200 | <kuribas> | both :) |
| 2023-10-02 10:07:42 +0200 | <kuribas> | But the core is written in rust. |
| 2023-10-02 10:07:54 +0200 | <tomsmeding> | I see |
| 2023-10-02 10:09:08 +0200 | <kuribas> | I am making a small static typed scheme like language, which then can be compiled to accelerate. |
| 2023-10-02 10:09:14 +0200 | <nullie> | I think SIMD is not about removing loops, it just utilizes computation units better |
| 2023-10-02 10:09:36 +0200 | <kuribas> | nullie: sure, python dataframe languages also use SIMD. |
| 2023-10-02 10:09:54 +0200 | <kuribas> | But each primitive operation is a loop over the data. |
| 2023-10-02 10:10:22 +0200 | <tomsmeding> | kuribas: do you `run` the in-flight computation whenever you get something that you can't encode in AcC? |
| 2023-10-02 10:10:24 +0200 | <tomsmeding> | *Acc |
| 2023-10-02 10:10:56 +0200 | <tomsmeding> | then the individual computations had better be large, because compiling an accelerate program is pretty expensive |
| 2023-10-02 10:11:06 +0200 | <tomsmeding> | sure, things are cached |
| 2023-10-02 10:11:12 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-02 10:11:15 +0200 | <tomsmeding> | but that also takes up a bunch of disk space :p |
| 2023-10-02 10:11:30 +0200 | euleritian | (~euleritia@185.238.219.3) (Ping timeout: 272 seconds) |
| 2023-10-02 10:12:00 +0200 | <kuribas> | tomsmeding: what do you mean? |
| 2023-10-02 10:12:13 +0200 | <kuribas> | Are these llvm compiled functions large? |
| 2023-10-02 10:12:26 +0200 | <tomsmeding> | not particularly |
| 2023-10-02 10:12:51 +0200 | <tomsmeding> | but if you run lots of slightly different programs, at some point it'll add up |
| 2023-10-02 10:13:06 +0200 | <tomsmeding> | ~/.cache/accelerate |
| 2023-10-02 10:13:40 +0200 | euleritian | (~euleritia@185.238.219.47) |
| 2023-10-02 10:14:32 +0200 | <kuribas> | well, the goal to have a set of stored procedures which are parametrised. |
| 2023-10-02 10:14:41 +0200 | <kuribas> | So not every query is a new program. |
| 2023-10-02 10:14:45 +0200 | <tomsmeding> | sure |
| 2023-10-02 10:14:58 +0200 | danse-nr3_ | (~francesco@151.37.123.134) |
| 2023-10-02 10:15:15 +0200 | <kuribas> | Does it read those programs from disk every time, or are they also cached in RAM? |
| 2023-10-02 10:15:18 +0200 | <tomsmeding> | I think the compiled accelerate programs do not even include `use` arrays, so you can change those and still hit the cache |
| 2023-10-02 10:15:20 +0200 | danse-nr3 | (~francesco@ge-19-121-23.service.infuturo.it) (Read error: Connection reset by peer) |
| 2023-10-02 10:15:31 +0200 | <tomsmeding> | kuribas: I think it reads from disk each time, but disk caches are a thing, so it'll be RAM anyway |
| 2023-10-02 10:15:52 +0200 | <kuribas> | hmm, true |
| 2023-10-02 10:16:01 +0200 | <tomsmeding> | especially for small files like these |
| 2023-10-02 10:16:34 +0200 | <kuribas> | And are they compiled each time? |
| 2023-10-02 10:16:47 +0200 | <kuribas> | Or are they stored in native machine code? |
| 2023-10-02 10:16:48 +0200 | <Hecate> | morning folks |
| 2023-10-02 10:16:55 +0200 | <kuribas> | Morning! |
| 2023-10-02 10:17:04 +0200 | <winny> | good morning, make sure to eat well :) |
| 2023-10-02 10:20:02 +0200 | <kuribas> | tomsmeding: actually, reading those files for *each* small array computation will like completely swamp any performance benifit I would get from SIMD. |
| 2023-10-02 10:20:06 +0200 | <kuribas> | even cached in memory. |
| 2023-10-02 10:20:35 +0200 | <tomsmeding> | kuribas: I'm reasonably sure (after checking some source) that when compiling an accelerate program, it will first do fusion and simplification within `accelerate`, then hash the resulting AST and check the cache |
| 2023-10-02 10:20:51 +0200 | <tomsmeding> | the cache is (optimised accelerate program) -> (optimised LLVM-compiled binary) |
| 2023-10-02 10:21:01 +0200 | <tomsmeding> | so you're paying for fusion etc each time anyway |
| 2023-10-02 10:21:14 +0200 | <tomsmeding> | as well as linking the .so in |
| 2023-10-02 10:21:27 +0200 | <tomsmeding> | I'm not sure this is the right trade-off |
| 2023-10-02 10:21:44 +0200 | <kuribas> | Each time of adding a new function, or each time of calling it? |
| 2023-10-02 10:21:53 +0200 | <tomsmeding> | each time invoking `run` |
| 2023-10-02 10:22:02 +0200 | <tomsmeding> | if you `runN` once and call the resulting Afunction multiple times, that's cheap |
| 2023-10-02 10:22:21 +0200 | <tomsmeding> | (and that's the intended use-case) |
| 2023-10-02 10:22:52 +0200 | <tomsmeding> | (er, AfunctionR) |
| 2023-10-02 10:23:10 +0200 | <kuribas> | "This function can be used to improve performance in cases where the array program is constant between invocations, because it enables us to bypass front-end conversion stages and move directly to the execution phase. If you have a computation applied repeatedly to different input data, use this, specifying any changing aspects of the computation via the input parameters. If the function is only evaluated once, this is equivalent to |
| 2023-10-02 10:23:10 +0200 | <kuribas> | run." |
| 2023-10-02 10:23:24 +0200 | <tomsmeding> | yes |
| 2023-10-02 10:23:30 +0200 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-10-02 10:23:50 +0200 | <kuribas> | SO this doesn't go through the disk cache? |
| 2023-10-02 10:24:07 +0200 | <tomsmeding> | calling that AfunctionR multiple times should do very little except running the compiled code |
| 2023-10-02 10:24:20 +0200 | <tomsmeding> | it's calling runN another time that is expensive |
| 2023-10-02 10:24:46 +0200 | <tomsmeding> | (laziness is done correctly so that seq'ing (runN f) does all the compilation) |
| 2023-10-02 10:25:03 +0200 | <tomsmeding> | (strictness, rather) |
| 2023-10-02 10:26:39 +0200 | <tomsmeding> | JITing is expensive :p |
| 2023-10-02 10:26:58 +0200 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-10-02 10:27:11 +0200 | <tomsmeding> | there's a reason JS interpreters, which are way more optimised still than Acc, only JIT-compile after they've determined it's worth it |
| 2023-10-02 10:28:12 +0200 | kuribas | (~user@2a02:1808:4:8d81:4e29:dcbe:5b1e:d8a2) (Ping timeout: 240 seconds) |
| 2023-10-02 10:29:01 +0200 | mmhat | (~mmh@p200300f1c74e6fafee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-10-02 10:30:02 +0200 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2023-10-02 10:30:02 +0200 | mmhat | (~mmh@p200300f1c74e6fafee086bfffe095315.dip0.t-ipconnect.de) (Client Quit) |
| 2023-10-02 10:30:05 +0200 | <kuribas`> | True, I could start with just unfused compile time loops, then see if JIT optimizing the loops gives an effect |
| 2023-10-02 10:30:19 +0200 | euleritian | (~euleritia@185.238.219.47) (Ping timeout: 264 seconds) |
| 2023-10-02 10:30:52 +0200 | euleritian | (~euleritia@185.238.219.30) |
| 2023-10-02 10:31:01 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 10:31:27 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-02 10:32:14 +0200 | <kuribas`> | tomsmeding: OTOH, jit compilers are made for generic code, in this case I just want to optimize low level calculations in a tight loop. |
| 2023-10-02 10:32:40 +0200 | <tomsmeding> | true |
| 2023-10-02 10:33:05 +0200 | vglfr | (vglfr@gateway/vpn/protonvpn/vglfr) |
| 2023-10-02 10:33:13 +0200 | <tomsmeding> | but even for accelerate code, it can get reasonably generic as well; if you fuse a bunch of things, the scalar expressions can get more complex |
| 2023-10-02 10:33:37 +0200 | <kuribas`> | And slower? |
| 2023-10-02 10:33:47 +0200 | <tomsmeding> | hm? |
| 2023-10-02 10:33:55 +0200 | <tomsmeding> | it's passed through LLVM which will do a good job, presumably |
| 2023-10-02 10:34:01 +0200 | <tomsmeding> | but compilation will be slower, yes |
| 2023-10-02 10:34:12 +0200 | <tomsmeding> | accelerate's compilation pipeline itself is not particularly optimised |
| 2023-10-02 10:34:17 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.5) |
| 2023-10-02 10:34:25 +0200 | <tomsmeding> | (in fact, for certain kinds of programs, it can be downright slow) |
| 2023-10-02 10:34:28 +0200 | <kuribas`> | Well, my plan was to use compilation for stored procedures, and interpretation for one off queries. |
| 2023-10-02 10:34:52 +0200 | <kuribas`> | I don't mind, as long is it doesn't cause long GC pauses for the rest of the program. |
| 2023-10-02 10:34:59 +0200 | <tomsmeding> | then you should probably compile a procedure to accelerate _once_ per invocation of the interpreter |
| 2023-10-02 10:35:22 +0200 | <tomsmeding> | i.e. keep a closure around for the compiled version of the stored procedure, that retains the AfunctionR's obtained from runN |
| 2023-10-02 10:35:30 +0200 | <tomsmeding> | then it should be good |
| 2023-10-02 10:35:48 +0200 | <kuribas`> | yeah that. |
| 2023-10-02 10:35:56 +0200 | <tomsmeding> | kuribas`: it's the _running_ of the accelerate program that could give you long GC pauses |
| 2023-10-02 10:35:56 +0200 | <kuribas`> | Or even use another library (Massive?) |
| 2023-10-02 10:35:59 +0200 | <tomsmeding> | compilation won't |
| 2023-10-02 10:36:06 +0200 | <tomsmeding> | massiv, also check out repa |
| 2023-10-02 10:36:17 +0200 | <tomsmeding> | they don't do JITing AFAIU |
| 2023-10-02 10:36:22 +0200 | <kuribas`> | Yeah, sadly I cannot preallocate arrays using accelerate. |
| 2023-10-02 10:36:35 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-10-02 10:36:47 +0200 | <tomsmeding> | in what sense? |
| 2023-10-02 10:36:56 +0200 | <tomsmeding> | A.fromList will do some allocation that's suitable for the native backend |
| 2023-10-02 10:37:32 +0200 | euleritian | (~euleritia@185.238.219.30) (Ping timeout: 248 seconds) |
| 2023-10-02 10:37:36 +0200 | <kuribas`> | In the sense of keeping a collection of preallocated blocks for intermediate calculations. |
| 2023-10-02 10:37:48 +0200 | <tomsmeding> | ah |
| 2023-10-02 10:37:48 +0200 | <tomsmeding> | no |
| 2023-10-02 10:37:51 +0200 | <kuribas`> | That don't need to use malloc. |
| 2023-10-02 10:37:58 +0200 | <tomsmeding> | but malloc is not the bottleneck |
| 2023-10-02 10:38:03 +0200 | <tomsmeding> | typically |
| 2023-10-02 10:38:15 +0200 | <kuribas`> | right |
| 2023-10-02 10:39:36 +0200 | <tomsmeding> | if malloc needs to request new pages from the OS it might be more expensive, but especially if you're reusing memory anyway, that won't be happening |
| 2023-10-02 10:41:51 +0200 | <kuribas`> | right |
| 2023-10-02 10:48:19 +0200 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2023-10-02 10:48:49 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 10:48:53 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 10:49:31 +0200 | xff0x | (~xff0x@2405:6580:b080:900:2499:90fc:2915:781d) (Ping timeout: 264 seconds) |
| 2023-10-02 10:49:34 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 10:50:11 +0200 | <haskellbridge> | <Inst> ... |
| 2023-10-02 10:50:20 +0200 | vglfr | (vglfr@gateway/vpn/protonvpn/vglfr) (Ping timeout: 248 seconds) |
| 2023-10-02 10:51:19 +0200 | xff0x | (~xff0x@2405:6580:b080:900:bb62:225f:513:94b7) |
| 2023-10-02 10:52:13 +0200 | <haskellbridge> | <Inst> Just an errant question, but has there ever been an attempt to define a database via typeclasses, i.e, you have properties of database objects via generics / typeclasses, you declare a particular database object via a datatype declaration |
| 2023-10-02 10:52:29 +0200 | <haskellbridge> | <Inst> and you assign it its properties based on a deriving clause? |
| 2023-10-02 10:52:58 +0200 | poscat | (~poscat@user/poscat) (Client Quit) |
| 2023-10-02 10:53:20 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 10:54:38 +0200 | poscat | (~poscat@user/poscat) (Remote host closed the connection) |
| 2023-10-02 10:54:59 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 11:02:45 +0200 | poscat | (~poscat@user/poscat) (Quit: Bye) |
| 2023-10-02 11:03:16 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 11:03:23 +0200 | migas | (~migas@astra4961.startdedicated.net) |
| 2023-10-02 11:07:10 +0200 | poscat | (~poscat@user/poscat) (Client Quit) |
| 2023-10-02 11:07:30 +0200 | poscat | (~poscat@user/poscat) |
| 2023-10-02 11:07:48 +0200 | aforemny_ | aforemny |
| 2023-10-02 11:11:27 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection) |
| 2023-10-02 11:14:26 +0200 | poscat0x04 | (~poscat@user/poscat) |
| 2023-10-02 11:16:01 +0200 | poscat | (~poscat@user/poscat) (Ping timeout: 260 seconds) |
| 2023-10-02 11:20:16 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 252 seconds) |
| 2023-10-02 11:23:55 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-10-02 11:27:03 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-02 11:31:14 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 11:31:51 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 11:33:19 +0200 | shryke | (~shryke@2a00:4b00:13c:cc:b27b:25ff:fe18:efd) (Quit: WeeChat 4.0.4) |
| 2023-10-02 11:34:33 +0200 | Inst | (~Inst@120.244.192.250) |
| 2023-10-02 11:34:48 +0200 | Inst | (~Inst@120.244.192.250) (Leaving) |
| 2023-10-02 11:34:51 +0200 | shryke | (~shryke@2a00:4b00:13c:cc:b27b:25ff:fe18:efd) |
| 2023-10-02 11:39:03 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds) |
| 2023-10-02 11:40:58 +0200 | Square3 | (~Square4@user/square) |
| 2023-10-02 11:40:59 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-10-02 11:45:56 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) |
| 2023-10-02 11:50:55 +0200 | masaeedu | (~masaeedu@modemcable068.99-80-70.mc.videotron.ca) |
| 2023-10-02 11:51:15 +0200 | <masaeedu> | Hello folks |
| 2023-10-02 11:51:57 +0200 | <masaeedu> | Was reading through this thread: https://groups.google.com/g/haskell-pipes/c/JFfyquj5HAg/m/Lxz7p50JOh4J |
| 2023-10-02 11:52:44 +0200 | <masaeedu> | There's some pretty great ideas in there on how to interface with child processes asynchronously |
| 2023-10-02 11:53:56 +0200 | <masaeedu> | Do you folks have any recommendations on libraries in this vein (async child process interaction) that have worked well for you? |
| 2023-10-02 11:54:01 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 11:54:04 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 11:54:24 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 11:58:12 +0200 | <haskellbridge> | <sm> masaeedu: the async package certainly |
| 2023-10-02 11:59:45 +0200 | <haskellbridge> | <sm> and maybe typed-process or something in the conduit packages ? |
| 2023-10-02 12:11:42 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 12:12:01 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 12:13:46 +0200 | lg188 | (~lg188@82.18.98.230) (Ping timeout: 260 seconds) |
| 2023-10-02 12:15:01 +0200 | <masaeedu> | cool, thanks. i looked at typed-process earlier, but AFAICS it didn't have a way to deal with terminal-interactive child processes (e.g. vim), and it didn't seem to have any abstraction over the actual I/O streams. |
| 2023-10-02 12:16:18 +0200 | <masaeedu> | iow it's a type-safe way to set up the child process and get at its I/O streams, but the streams are just `Handle`s in the end, so the task of dealing with those appropriately using low level async primitives is still left to the user |
| 2023-10-02 12:16:45 +0200 | <masaeedu> | i could be misreading thouhg |
| 2023-10-02 12:17:56 +0200 | <haskellbridge> | <sm> for terminal stuff, https://hackage.haskell.org/package/concurrent-output is a cool one |
| 2023-10-02 12:22:32 +0200 | <masaeedu> | that looks really neat. unfortunately it seems like the dual of what i need: it helps a haskell process produce the sort of data on its output stream that i need to consume from a child process |
| 2023-10-02 12:22:54 +0200 | <masaeedu> | could be useful for testing though |
| 2023-10-02 12:23:52 +0200 | jjhoo | (~jahakala@user/jjhoo) (Ping timeout: 272 seconds) |
| 2023-10-02 12:27:44 +0200 | <kuribas`> | tomsmeding: I also suppose arrays only have a single pointer, so they don't contribute a lot to GC time. |
| 2023-10-02 12:28:21 +0200 | danse-nr3_ | (~francesco@151.37.123.134) (Ping timeout: 260 seconds) |
| 2023-10-02 12:35:03 +0200 | vglfr | (~vglfr@88.155.142.130) |
| 2023-10-02 12:35:54 +0200 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2023-10-02 12:44:07 +0200 | <haskellbridge> | <mauke> Terminal stuff is more complicated; for that, you have to implement a pseudo-terminal |
| 2023-10-02 12:44:16 +0200 | vglfr | (~vglfr@88.155.142.130) (Ping timeout: 255 seconds) |
| 2023-10-02 12:45:29 +0200 | <masaeedu> | that makes sense, i'm essentially looking for primitives to implement a pseudo terminal, or at least simulate one to the satisfaction of the child process so that i can exercise it and record the relevant information |
| 2023-10-02 12:52:32 +0200 | vglfr | (~vglfr@88.155.142.130) |
| 2023-10-02 12:53:00 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds) |
| 2023-10-02 12:55:37 +0200 | danse-nr3 | (~francesco@151.37.123.134) |
| 2023-10-02 12:56:44 +0200 | vglfr | (~vglfr@88.155.142.130) (Ping timeout: 248 seconds) |
| 2023-10-02 12:58:38 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Read error: Connection reset by peer) |
| 2023-10-02 12:58:41 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-10-02 12:59:14 +0200 | CiaoSen | (~Jura@2a05:5800:2a3:5900:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds) |
| 2023-10-02 13:00:28 +0200 | sm | (~sm@plaintextaccounting/sm) (Quit: sm) |
| 2023-10-02 13:00:48 +0200 | jargon | (~jargon@184.101.67.95) (Remote host closed the connection) |
| 2023-10-02 13:01:28 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2023-10-02 13:04:13 +0200 | hiyori | (~hiyori@user/hiyori) |
| 2023-10-02 13:05:58 +0200 | sm | (~sm@plaintextaccounting/sm) (Client Quit) |
| 2023-10-02 13:06:32 +0200 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) (Quit: WeeChat 4.0.4) |
| 2023-10-02 13:06:48 +0200 | m1dnight | (~christoph@78-22-4-67.access.telenet.be) |
| 2023-10-02 13:07:13 +0200 | danse-nr3 | (~francesco@151.37.123.134) (Ping timeout: 255 seconds) |
| 2023-10-02 13:16:20 +0200 | lg188 | (~lg188@82.18.98.230) |
| 2023-10-02 13:26:54 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 13:27:05 +0200 | stites | (~stites@130.44.147.204) (Ping timeout: 240 seconds) |
| 2023-10-02 13:28:29 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 13:28:48 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 13:29:41 +0200 | stites | (~stites@2607:fb90:ad62:9844:b792:bda4:37c7:7710) |
| 2023-10-02 13:42:50 +0200 | masaeedu | (~masaeedu@modemcable068.99-80-70.mc.videotron.ca) (Quit: WeeChat 4.0.2) |
| 2023-10-02 13:47:46 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 13:48:04 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 13:50:53 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-10-02 13:52:51 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-10-02 13:54:36 +0200 | Feuermagier_ | (~Feuermagi@user/feuermagier) |
| 2023-10-02 13:54:36 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Killed (calcium.libera.chat (Nickname regained by services))) |
| 2023-10-02 13:54:36 +0200 | Feuermagier_ | Feuermagier |
| 2023-10-02 13:59:54 +0200 | Guest5529 | (~Guest55@ext-1-173.eduroam.chalmers.se) |
| 2023-10-02 14:00:50 +0200 | <Guest5529> | I am trying to write template haskell code that emits some rewrite rules, but they are rejected because they contain redundant parenthesis. |
| 2023-10-02 14:00:50 +0200 | <Guest5529> | The LHS of my rule has the form of `f a b`, but TH emits `(f a) b`, which is not legal as a LHS for a rewrite rule. Does anyone know of a way of omiting such parenthesis in TH-generated code? |
| 2023-10-02 14:01:49 +0200 | <dminuoso> | Guest5529: What are you using to pretty print the code with, exactly? |
| 2023-10-02 14:02:36 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds) |
| 2023-10-02 14:03:12 +0200 | michalz | (~michalz@185.246.204.125) (Ping timeout: 258 seconds) |
| 2023-10-02 14:05:35 +0200 | <Guest5529> | The code I am seeing is shown in a GHC error message |
| 2023-10-02 14:05:41 +0200 | <Guest5529> | So whatever is the default, I guess? |
| 2023-10-02 14:05:45 +0200 | michalz | (~michalz@185.246.204.126) |
| 2023-10-02 14:06:10 +0200 | <Guest5529> | My error is identical to the one listed in this old SO question: https://stackoverflow.com/questions/57598262/how-to-emit-rewrite-rules-from-template-haskell |
| 2023-10-02 14:06:39 +0200 | <haskellbridge> | <mauke> I see a package called posix-pty on hackage |
| 2023-10-02 14:06:49 +0200 | <dminuoso> | Guest5529: What do you mean by "default". Can you show your template haskell code? |
| 2023-10-02 14:07:08 +0200 | <Guest5529> | How would you like me to share it? I don't mind |
| 2023-10-02 14:07:37 +0200 | <dminuoso> | Use a paste website of your choosing. Our channel topic has one, but you can also use gist.github.com or any other similar service you like. |
| 2023-10-02 14:07:48 +0200 | <dminuoso> | https://paste.tomsmeding.com |
| 2023-10-02 14:10:34 +0200 | <Guest5529> | Does this work? https://paste.tomsmeding.com/GkTmNkdF |
| 2023-10-02 14:12:33 +0200 | <Guest5529> | I tried a dirty hack where `locallyLHS endpoint = AppE $ mkName $ concat ["locally ", endpoint, " f"]`, but it didn't work as it (correctly) is not parsed as a variable |
| 2023-10-02 14:12:45 +0200 | <Guest5529> | sorry, the AppE above should be VarE |
| 2023-10-02 14:12:54 +0200 | <dminuoso> | Guest5529: No worry, its enough for me to get the idea. |
| 2023-10-02 14:13:06 +0200 | <Guest5529> | Thanks, I would appreciate any help |
| 2023-10-02 14:13:15 +0200 | <Guest5529> | I am open for hacks, regardless of how greasy they are |
| 2023-10-02 14:13:26 +0200 | <dminuoso> | I would say, try to make a simple testcase and file it as a bug report on ghc itself. |
| 2023-10-02 14:13:43 +0200 | <dminuoso> | If you're directly splicing a rule, and GHC is choking like that, I have a hard time seeing how this is not a bug. |
| 2023-10-02 14:14:08 +0200 | <Guest5529> | If I manually copy the rule the error is presenting, and only removes the parenthesis around `locally server`, the rule is accepted |
| 2023-10-02 14:14:18 +0200 | <dminuoso> | The ADT shouldnt even let you admit specifying some AST that is invalid syntax. |
| 2023-10-02 14:15:17 +0200 | <Guest5529> | Sigh, so maybe this is not a quick fix |
| 2023-10-02 14:15:21 +0200 | <Guest5529> | I will open an issue |
| 2023-10-02 14:15:55 +0200 | <int-e> | compare https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/ThToHs.hs#L1044-1046 |
| 2023-10-02 14:16:23 +0200 | <int-e> | (That's where the "extra" parentheses come from) |
| 2023-10-02 14:16:58 +0200 | hiyori | (~hiyori@user/hiyori) (Quit: Client closed) |
| 2023-10-02 14:17:10 +0200 | <dminuoso> | int-e: Im curious, what is this output of cvtl exactly? |
| 2023-10-02 14:17:25 +0200 | <dminuoso> | Arent parenthesis lexical information already? How does that fit into a TH splice? |
| 2023-10-02 14:17:52 +0200 | <dminuoso> | Or does TH quite literally splice lexical chunks in place? |
| 2023-10-02 14:18:23 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 14:19:05 +0200 | <tomsmeding> | I'm on a system that doesn't have GMP globally installed. I've built it locally and installed it in a prefix (I don't have root on this system). Is there a way to tell cabal/ghc to use _this_ gmp? extra-lib-dirs does nothing. |
| 2023-10-02 14:19:20 +0200 | <Guest5529> | Hm I managed to find a hack just now, by trying a different syntax |
| 2023-10-02 14:19:43 +0200 | <dminuoso> | Which are you using instead? |
| 2023-10-02 14:19:54 +0200 | <Guest5529> | `locallyLHS endpoint = UInfixE (VarE $ mkName endpoint) (VarE $ mkName "locally") ((VarE $ mkName "f"))` will render as `server `locally` f`, which is accepted |
| 2023-10-02 14:20:05 +0200 | <dminuoso> | Heh. |
| 2023-10-02 14:20:09 +0200 | <Guest5529> | It works because I have a 2-ary function |
| 2023-10-02 14:20:10 +0200 | <int-e> | dminuoso: It's an AST but for some reason, presumably pretty-printing (maybe infix operators) it preserves parentheses. |
| 2023-10-02 14:20:11 +0200 | <Guest5529> | Greasy |
| 2023-10-02 14:20:29 +0200 | <dminuoso> | Guest5529: Nice to see you have a workaround. But do please file a bug report regardless. |
| 2023-10-02 14:20:39 +0200 | <Guest5529> | The rule still seems to fire even if the program I am compiling contains `local server f` |
| 2023-10-02 14:20:45 +0200 | <int-e> | Oh in fact that same type may be used before and after fixity resolution? No clue, really. |
| 2023-10-02 14:20:47 +0200 | <Guest5529> | So that is nice |
| 2023-10-02 14:21:04 +0200 | <int-e> | Guest5529: lol |
| 2023-10-02 14:21:08 +0200 | <Guest5529> | Amazing |
| 2023-10-02 14:21:26 +0200 | <int-e> | (it'll stop working if you have more than two arguments, but it is a clever hack) |
| 2023-10-02 14:21:53 +0200 | <Guest5529> | I am fortunate, I need to add some optimizations for three different functions but they are all 2-ary |
| 2023-10-02 14:22:27 +0200 | <int-e> | dminuoso: So I guess the right fix will have to relax that check for RULES. Or declare TH-generated RULES illegal I guess. |
| 2023-10-02 14:23:03 +0200 | <Guest5529> | I was amazed that I could even emit rules with TH |
| 2023-10-02 14:23:07 +0200 | <Guest5529> | I like it |
| 2023-10-02 14:23:08 +0200 | <dminuoso> | What I dont quite get is why this generates redundant parenthesis at all |
| 2023-10-02 14:23:08 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds) |
| 2023-10-02 14:23:18 +0200 | <dminuoso> | parenthesizeHsExpr seems to accept precedence parameters |
| 2023-10-02 14:23:31 +0200 | <dminuoso> | It feels like TH should be smart enough to not do this. |
| 2023-10-02 14:23:41 +0200 | <int-e> | maybe |
| 2023-10-02 14:23:50 +0200 | <int-e> | open a ticket, leave it to the devs :) |
| 2023-10-02 14:24:11 +0200 | <Guest5529> | Opening it as we speak, preparing the issue |
| 2023-10-02 14:25:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2023-10-02 14:26:57 +0200 | <int-e> | dminuoso: Why... because it (mostly, as evidenced above) works; why would you bother with omitting redundant parentheses in code that people hardly ever see... it's easy to miss this corner case where the parentheses actually hurt because of similar, but incompatible laziness in another part of a compiler. |
| 2023-10-02 14:29:20 +0200 | <dminuoso> | int-e: For one, it would make dumped splices a bit more pleasing to read, which can be useful for flows where you manually splice (say to avoid cross compilation issues) |
| 2023-10-02 14:30:27 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f61505e043ab51d70dd.dip0.t-ipconnect.de) |
| 2023-10-02 14:32:58 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-02 14:35:34 +0200 | todi | (~todi@p5dca5e79.dip0.t-ipconnect.de) (Ping timeout: 255 seconds) |
| 2023-10-02 14:38:15 +0200 | todi | (~todi@p5dca5e79.dip0.t-ipconnect.de) |
| 2023-10-02 14:38:28 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 258 seconds) |
| 2023-10-02 14:38:37 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 14:41:02 +0200 | czy | (~user@121.231.44.109) (Remote host closed the connection) |
| 2023-10-02 14:41:46 +0200 | danse-nr3 | (~francesco@151.35.117.238) |
| 2023-10-02 14:41:49 +0200 | <Guest5529> | https://gitlab.haskell.org/ghc/ghc/-/issues/24046 |
| 2023-10-02 14:43:40 +0200 | czy | (~user@121.231.44.109) |
| 2023-10-02 14:44:56 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f61505e043ab51d70dd.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-10-02 14:45:26 +0200 | ubert | (~Thunderbi@178.115.46.96.wireless.dyn.drei.com) (Ping timeout: 260 seconds) |
| 2023-10-02 14:45:31 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) |
| 2023-10-02 14:49:25 +0200 | qqq | (~qqq@92.43.167.61) |
| 2023-10-02 14:49:28 +0200 | AlexZenon | (~alzenon@178.34.161.162) (Quit: ;-) |
| 2023-10-02 14:49:50 +0200 | Alex_test | (~al_test@178.34.161.162) (Quit: ;-) |
| 2023-10-02 14:50:13 +0200 | AlexNoo | (~AlexNoo@178.34.161.162) (Quit: Leaving) |
| 2023-10-02 14:56:11 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-10-02 14:57:35 +0200 | <Guest5529> | Apparently my TH problem is patched in 9.6, which is great dminuoso |
| 2023-10-02 14:59:02 +0200 | <int-e> | oh, great timing |
| 2023-10-02 15:01:49 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Quit: Leaving) |
| 2023-10-02 15:05:44 +0200 | stites | (~stites@2607:fb90:ad62:9844:b792:bda4:37c7:7710) (Read error: Connection reset by peer) |
| 2023-10-02 15:06:03 +0200 | stites | (~stites@130.44.147.204) |
| 2023-10-02 15:12:38 +0200 | AlexNoo | (~AlexNoo@178.34.161.162) |
| 2023-10-02 15:13:27 +0200 | sabino | (~sabino@user/sabino) |
| 2023-10-02 15:13:36 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-10-02 15:14:16 +0200 | <kuribas`> | Does native ghc support simd? Will massiv compile to vectorised code, or just on LLVM? |
| 2023-10-02 15:15:24 +0200 | <dminuoso> | kuribas`: Yes and no. |
| 2023-10-02 15:15:41 +0200 | <dminuoso> | GHC has vector primops available, but you have to explicitly select them. |
| 2023-10-02 15:16:09 +0200 | <dminuoso> | There is no builtin auto vectorization (there were a few attempts at this, but they have gone stale) |
| 2023-10-02 15:16:38 +0200 | <dminuoso> | So whether massiv uses vectorised code, you have to check the massiv codebase whether it (directly or indirectly) uses vectorized primops |
| 2023-10-02 15:16:46 +0200 | AlexZenon | (~alzenon@178.34.161.162) |
| 2023-10-02 15:17:22 +0200 | <kuribas`> | ok, and if it doesn't, selecting llvm can vectorize the code? |
| 2023-10-02 15:18:23 +0200 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2023-10-02 15:18:44 +0200 | EvanR | (~EvanR@user/evanr) |
| 2023-10-02 15:19:58 +0200 | <dminuoso> | I have no experience with that. In principle it seems like it could in theory, but given that our code generation is a bit more exotic I suspect the vectorization potential lis very limited. |
| 2023-10-02 15:20:55 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-10-02 15:22:03 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) |
| 2023-10-02 15:22:06 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2023-10-02 15:22:28 +0200 | Alex_test | (~al_test@178.34.161.162) |
| 2023-10-02 15:22:56 +0200 | <dminuoso> | https://github.com/lehins/massiv/issues/80 |
| 2023-10-02 15:23:04 +0200 | czy` | (~user@121.231.44.109) |
| 2023-10-02 15:23:56 +0200 | czy | (~user@121.231.44.109) (Quit: ERC 5.6-git (IRC client for GNU Emacs 30.0.50)) |
| 2023-10-02 15:23:58 +0200 | czy` | (~user@121.231.44.109) (Remote host closed the connection) |
| 2023-10-02 15:24:41 +0200 | czy | (~user@121.231.44.109) |
| 2023-10-02 15:30:27 +0200 | <kuribas`> | well, that claimed a 4x performance increase :) |
| 2023-10-02 15:30:57 +0200 | <dminuoso> | Which part of that? |
| 2023-10-02 15:31:31 +0200 | ystael | (~ystael@user/ystael) |
| 2023-10-02 15:31:32 +0200 | <dminuoso> | Ah I see. |
| 2023-10-02 15:31:40 +0200 | <kuribas`> | https://github.com/lehins/massiv/issues/80#issuecomment-508237610 |
| 2023-10-02 15:32:17 +0200 | <dminuoso> | Id have to look deeper at the examples. But if LLVM vectorization works that good, then great I guess? |
| 2023-10-02 15:32:44 +0200 | <dminuoso> | However, Im not entirely sure what "native GHC SIMD (llvm)" refers to. |
| 2023-10-02 15:33:16 +0200 | <kuribas`> | I suppose LLVM backend, not native backend. |
| 2023-10-02 15:33:54 +0200 | ulysses4ever | (~artem@2601:249:4380:8950:8cb8:b1ce:18cd:1b77) |
| 2023-10-02 15:35:00 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-10-02 15:35:29 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-10-02 15:35:30 +0200 | <dminuoso> | A-ha. https://gitlab.haskell.org/ghc/ghc/-/issues/7741 |
| 2023-10-02 15:35:38 +0200 | <dminuoso> | It seems that you have to use LLVM even for simd primops. |
| 2023-10-02 15:35:40 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-10-02 15:36:26 +0200 | <kuribas`> | I remember there was once SIMD support that was later removed. |
| 2023-10-02 15:36:53 +0200 | <dminuoso> | Well, SIMD support for NCG. |
| 2023-10-02 15:41:49 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2023-10-02 15:42:33 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) |
| 2023-10-02 15:45:00 +0200 | gatekempt | (~gatekempt@user/gatekempt) |
| 2023-10-02 15:45:19 +0200 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 264 seconds) |
| 2023-10-02 15:46:42 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-10-02 15:46:42 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-10-02 15:46:42 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-10-02 15:53:48 +0200 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) |
| 2023-10-02 15:55:39 +0200 | xff0x | (~xff0x@2405:6580:b080:900:bb62:225f:513:94b7) (Read error: Connection reset by peer) |
| 2023-10-02 15:56:46 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 15:57:05 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 16:00:13 +0200 | xff0x | (~xff0x@2405:6580:b080:900:2382:d87:4dd6:d990) |
| 2023-10-02 16:02:52 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 248 seconds) |
| 2023-10-02 16:07:49 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 16:07:53 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 255 seconds) |
| 2023-10-02 16:08:34 +0200 | Guest5529 | (~Guest55@ext-1-173.eduroam.chalmers.se) (Quit: Connection closed) |
| 2023-10-02 16:25:10 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds) |
| 2023-10-02 16:37:32 +0200 | danse-nr3 | (~francesco@151.35.117.238) (Ping timeout: 248 seconds) |
| 2023-10-02 16:38:09 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 16:40:33 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Ping timeout: 245 seconds) |
| 2023-10-02 16:42:07 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-10-02 16:45:45 +0200 | Guest30 | (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9) |
| 2023-10-02 16:47:21 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 260 seconds) |
| 2023-10-02 16:48:32 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) |
| 2023-10-02 16:51:52 +0200 | danse-nr3 | (~francesco@151.35.117.238) |
| 2023-10-02 16:54:07 +0200 | waleee | (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 252 seconds) |
| 2023-10-02 16:54:09 +0200 | Guest|20 | (~Guest|20@145.108.66.99) |
| 2023-10-02 16:54:22 +0200 | Guest|20 | (~Guest|20@145.108.66.99) (Client Quit) |
| 2023-10-02 16:56:10 +0200 | captnemo | (~captnemo@193.32.127.239) |
| 2023-10-02 16:58:11 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-10-02 17:01:23 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 17:05:14 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:2aaa:42ea:b9cc:3d82) (Quit: WeeChat 2.8) |
| 2023-10-02 17:09:43 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Quit: segfaultfizzbuzz) |
| 2023-10-02 17:14:13 +0200 | Guest|40 | (~Guest|40@138-38-227-107.wireless.bath.ac.uk) |
| 2023-10-02 17:14:58 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-10-02 17:19:50 +0200 | rickbonavigo | (~rickbonav@2a00:6d43:500:801:978b:c04c:d728:3c46) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-10-02 17:21:10 +0200 | Guest|40 | (~Guest|40@138-38-227-107.wireless.bath.ac.uk) (Quit: Connection closed) |
| 2023-10-02 17:21:10 +0200 | rickbonavigo | (~rickbonav@ip185-157-107-176.pool-bba.aruba.it) |
| 2023-10-02 17:23:28 +0200 | Guest30 | (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9) (Quit: Client closed) |
| 2023-10-02 17:25:48 +0200 | jabuxas | (~jabuxas@user/jabuxas) |
| 2023-10-02 17:27:40 +0200 | rickbonavigo | (~rickbonav@ip185-157-107-176.pool-bba.aruba.it) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-10-02 17:32:12 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-10-02 17:35:14 +0200 | Guest30 | (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9) |
| 2023-10-02 17:35:46 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds) |
| 2023-10-02 17:36:51 +0200 | <haskellbridge> | <rickbonavigo> !nick |
| 2023-10-02 17:39:03 +0200 | doyougnu- | (~doyougnu@45.46.170.68) (Ping timeout: 240 seconds) |
| 2023-10-02 17:39:39 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2023-10-02 17:40:00 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 17:40:43 +0200 | vglfr | (~vglfr@88.155.254.210) |
| 2023-10-02 17:40:49 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 17:41:09 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) |
| 2023-10-02 17:42:28 +0200 | Pozyomka | (~pyon@user/pyon) (Quit: Pozyomka, my beloved: https://i.imgur.com/BMmVfTq.png) |
| 2023-10-02 17:42:50 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) (Remote host closed the connection) |
| 2023-10-02 17:43:06 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-10-02 17:47:34 +0200 | vglfr | (~vglfr@88.155.254.210) (Ping timeout: 255 seconds) |
| 2023-10-02 17:48:33 +0200 | captnemo | (~captnemo@193.32.127.239) (Quit: WeeChat 4.0.4) |
| 2023-10-02 17:50:19 +0200 | <EvanR> | <rickbonavigo> |
| 2023-10-02 17:50:57 +0200 | Guest30 | (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9) (Quit: Client closed) |
| 2023-10-02 17:55:10 +0200 | jabuxas | (~jabuxas@user/jabuxas) (Quit: Leaving.) |
| 2023-10-02 17:55:57 +0200 | vglfr | (~vglfr@88.155.254.210) |
| 2023-10-02 17:58:14 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-10-02 18:10:46 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds) |
| 2023-10-02 18:11:44 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds) |
| 2023-10-02 18:17:26 +0200 | vglfr | (~vglfr@88.155.254.210) (Remote host closed the connection) |
| 2023-10-02 18:19:35 +0200 | vglfr | (~vglfr@88.155.254.210) |
| 2023-10-02 18:22:13 +0200 | danse-nr3 | (~francesco@151.35.117.238) (Ping timeout: 255 seconds) |
| 2023-10-02 18:22:45 +0200 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2023-10-02 18:23:07 +0200 | Square3 | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2023-10-02 18:26:26 +0200 | cpressey | (~cpressey@host-2-102-82-207.as13285.net) |
| 2023-10-02 18:28:54 +0200 | kuribas` | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-10-02 18:29:48 +0200 | danse-nr3 | (~francesco@ge-19-120-4.service.infuturo.it) |
| 2023-10-02 18:32:21 +0200 | <cpressey> | Something interesting I stumbled across recently, hadn't encountered before, might be of interest here: Augmenting a finite automaton with a single memory cell that holds an element of a given monoid or group: https://arxiv.org/abs/math/0601061v2 |
| 2023-10-02 18:32:38 +0200 | jjhoo | (~jahakala@user/jjhoo) |
| 2023-10-02 18:34:45 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-02 18:39:18 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Ping timeout: 245 seconds) |
| 2023-10-02 18:39:56 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-10-02 18:41:19 +0200 | <EvanR> | 1 memory cell should be enough for anybody |
| 2023-10-02 18:41:43 +0200 | geekosaur | wonders how this relates to differentiation of types |
| 2023-10-02 18:42:53 +0200 | <geekosaur> | (that is, does this constitute a one-hole context?) |
| 2023-10-02 18:45:34 +0200 | EvanR | (~EvanR@user/evanr) (Quit: Leaving) |
| 2023-10-02 18:46:07 +0200 | <ncf> | isn't a DFA basically just a monoid already, with initial and final states? |
| 2023-10-02 18:47:46 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 18:48:44 +0200 | <ncf> | well, a finite monoid i guess |
| 2023-10-02 18:51:55 +0200 | euleritian | (~euleritia@2001:bc8:3f13:ffc2:90bc:54bf:aeae:e7ab) |
| 2023-10-02 18:52:37 +0200 | Square | (~Square@user/square) |
| 2023-10-02 18:52:51 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds) |
| 2023-10-02 18:56:27 +0200 | euleritian | (~euleritia@2001:bc8:3f13:ffc2:90bc:54bf:aeae:e7ab) (Ping timeout: 258 seconds) |
| 2023-10-02 18:59:46 +0200 | acidjnk_new | (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-10-02 18:59:53 +0200 | cpressey | (~cpressey@host-2-102-82-207.as13285.net) (Quit: Client closed) |
| 2023-10-02 19:00:51 +0200 | ski | (~ski@88.131.7.247) |
| 2023-10-02 19:01:22 +0200 | <dminuoso> | Is there something akin to -Wmissing-fields with a sum type that assures that for each possible constructor, there exists a branch that could produce it? |
| 2023-10-02 19:02:02 +0200 | <dminuoso> | Specifically Im producing a big sum type as part of a parser, and I would like some guarantees I didnt forget any constructor |
| 2023-10-02 19:02:07 +0200 | <tomsmeding> | that would have way too many false positives if enabled for every sum type |
| 2023-10-02 19:02:34 +0200 | <tomsmeding> | it would need to be a pragma on one function for one sum type |
| 2023-10-02 19:02:37 +0200 | nckhexen | (nckx@libera/staff/owl/nckx) (Quit: Updating my Guix System <https://guix.gnu.org>) |
| 2023-10-02 19:02:44 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 19:04:20 +0200 | AlexNoo_ | (~AlexNoo@94.233.241.182) |
| 2023-10-02 19:04:29 +0200 | <ski> | (i guess you're looking for a (kind of) surjectivity check, as opposed to a (kind of) totality check (checking for missing fields) ..) |
| 2023-10-02 19:05:15 +0200 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2023-10-02 19:06:01 +0200 | cpressey | (~cpressey@host-2-102-82-207.as13285.net) |
| 2023-10-02 19:06:11 +0200 | AlexZenon | (~alzenon@178.34.161.162) (Ping timeout: 255 seconds) |
| 2023-10-02 19:07:02 +0200 | <ski> | (.. in a logic programming language with static mode checking, one could in general attempt to declare a mode to the effect of the converse relation "being total" aka the relation itself being surjective. however, i'm not sure that would work, with the parsing effects intervening) |
| 2023-10-02 19:07:27 +0200 | AlexNoo | (~AlexNoo@178.34.161.162) (Ping timeout: 240 seconds) |
| 2023-10-02 19:07:34 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds) |
| 2023-10-02 19:07:47 +0200 | acidjnk | (~acidjnk@p200300d6e7072f6198c60cc392982534.dip0.t-ipconnect.de) |
| 2023-10-02 19:07:57 +0200 | Alex_test | (~al_test@178.34.161.162) (Ping timeout: 258 seconds) |
| 2023-10-02 19:08:21 +0200 | cpressey | (~cpressey@host-2-102-82-207.as13285.net) (Client Quit) |
| 2023-10-02 19:09:29 +0200 | <ski> | (mode checking can be seen as a generalization (both declarative, and also sometimes procedural) of checks akin to functional dependencies and injectivity constraints (on type families) .. except that they'd be applied to the expression/term level here, not on the type level) |
| 2023-10-02 19:12:07 +0200 | AlexZenon | (~alzenon@94.233.241.182) |
| 2023-10-02 19:14:07 +0200 | Alex_test | (~al_test@94.233.241.182) |
| 2023-10-02 19:17:12 +0200 | billchenchina | (~billchenc@2a0c:b641:7a2:320:ee3e:47ca:6070:d71a) |
| 2023-10-02 19:17:55 +0200 | cpressey | (~cpressey@host-89-240-119-146.as13285.net) |
| 2023-10-02 19:19:32 +0200 | <cpressey> | (Ha, the link I posted earlier I actually didn't mean to post in here. Sorry about that. Still, hopefully it wasn't *vastly* off-topic.) |
| 2023-10-02 19:20:56 +0200 | hugo- | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 19:26:35 +0200 | stites | (~stites@130.44.147.204) (Ping timeout: 240 seconds) |
| 2023-10-02 19:27:29 +0200 | stites | (~stites@2607:fb91:dc1:c8a5:8789:bf98:6bc7:9cd4) |
| 2023-10-02 19:31:24 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) |
| 2023-10-02 19:38:58 +0200 | hugo- | (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds) |
| 2023-10-02 19:45:12 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2023-10-02 19:45:36 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2023-10-02 19:47:27 +0200 | Pozyomka | (~pyon@user/pyon) |
| 2023-10-02 19:50:25 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-10-02 19:52:25 +0200 | doyougnu | (~doyougnu@45.46.170.68) |
| 2023-10-02 19:53:34 +0200 | Square | (~Square@user/square) (Ping timeout: 255 seconds) |
| 2023-10-02 19:59:40 +0200 | stites | (~stites@2607:fb91:dc1:c8a5:8789:bf98:6bc7:9cd4) (Read error: Connection reset by peer) |
| 2023-10-02 20:00:00 +0200 | stites | (~stites@130.44.147.204) |
| 2023-10-02 20:01:19 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2023-10-02 20:03:28 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2023-10-02 20:05:24 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-10-02 20:06:44 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-10-02 20:07:23 +0200 | simendsjo | (~user@84.211.91.241) (Ping timeout: 255 seconds) |
| 2023-10-02 20:08:20 +0200 | Square | (~Square@user/square) |
| 2023-10-02 20:10:33 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 20:13:25 +0200 | infinity0_ | (~infinity0@pwned.gg) |
| 2023-10-02 20:13:25 +0200 | infinity0 | (~infinity0@pwned.gg) (Killed (mercury.libera.chat (Nickname regained by services))) |
| 2023-10-02 20:13:25 +0200 | infinity0_ | infinity0 |
| 2023-10-02 20:17:21 +0200 | danse-nr3 | (~francesco@ge-19-120-4.service.infuturo.it) (Ping timeout: 260 seconds) |
| 2023-10-02 20:22:22 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-10-02 20:24:04 +0200 | rw | (~rw@136.226.101.20) |
| 2023-10-02 20:26:24 +0200 | <rw> | I have embedded haskell FFI code into a rust project and am noticing a race condition between hs_exit() and when a haskell stable ptr is destroyed. Given this is running inside an application, what happens if I dont call hs_exit() and just let the program terminate? |
| 2023-10-02 20:27:45 +0200 | <rw> | I have registered `hs_exit()` to run via ::libc::atexit(hs_exit), however the race condition appears to be related to how rust is calling destructors and when `libc::atexit(hs_exit)` is actually executed. |
| 2023-10-02 20:32:54 +0200 | <monochrom> | Possibly no consequence except not flushing buffers of Handles. |
| 2023-10-02 20:34:14 +0200 | eggplantade | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2023-10-02 20:34:18 +0200 | cpressey | (~cpressey@host-89-240-119-146.as13285.net) (Ping timeout: 245 seconds) |
| 2023-10-02 20:35:21 +0200 | <monochrom> | Normally I don't even use atexit(), I write library constructors and destructors for hs_init() and hs_exit(). http://www.vex.net/~trebla/haskell/so.xhtml |
| 2023-10-02 20:39:39 +0200 | rw | (~rw@136.226.101.20) (Quit: Client closed) |
| 2023-10-02 20:42:30 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 20:44:21 +0200 | cpressey | (~cpressey@host-89-240-119-146.as13285.net) |
| 2023-10-02 20:48:29 +0200 | acidjnk | (~acidjnk@p200300d6e7072f6198c60cc392982534.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-10-02 20:50:44 +0200 | acidjnk | (~acidjnk@p200300d6e7072f61e1adf3a14c9d7e70.dip0.t-ipconnect.de) |
| 2023-10-02 20:54:04 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2023-10-02 20:58:05 +0200 | rw | (~rw@136.226.101.20) |
| 2023-10-02 20:58:10 +0200 | <rw> | what happens if I never call hs_exit(), but terminate my program (say it ends or I kill it) |
| 2023-10-02 20:59:37 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 20:59:57 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) |
| 2023-10-02 21:00:33 +0200 | rgw | (~R@2605:a601:a0df:5600:7d17:3b99:a896:2e62) |
| 2023-10-02 21:01:27 +0200 | jabuxas | (~jabuxas@user/jabuxas) |
| 2023-10-02 21:02:53 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-10-02 21:08:00 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) |
| 2023-10-02 21:10:46 +0200 | <monochrom> | <monochrom> Possibly no consequence except not flushing buffers of Handles. |
| 2023-10-02 21:12:12 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) (Ping timeout: 248 seconds) |
| 2023-10-02 21:15:46 +0200 | danza_ | (~francesco@151.43.118.113) |
| 2023-10-02 21:15:58 +0200 | cpressey | (~cpressey@host-89-240-119-146.as13285.net) (Ping timeout: 245 seconds) |
| 2023-10-02 21:16:43 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:fd5:bf9:bc86:68dc) |
| 2023-10-02 21:22:51 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:fd5:bf9:bc86:68dc) (Quit: WeeChat 2.8) |
| 2023-10-02 21:24:39 +0200 | cpressey | (~cpressey@host-89-240-119-146.as13285.net) |
| 2023-10-02 21:28:29 +0200 | acidjnk | (~acidjnk@p200300d6e7072f61e1adf3a14c9d7e70.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-10-02 21:34:12 +0200 | acidjnk | (~acidjnk@p200300d6e7072f6150a540857548904b.dip0.t-ipconnect.de) |
| 2023-10-02 21:35:19 +0200 | bilegeek | (~bilegeek@2600:1008:b026:1a87:2ee8:e964:d4e2:13c1) |
| 2023-10-02 21:36:56 +0200 | ski | (~ski@88.131.7.247) (Ping timeout: 255 seconds) |
| 2023-10-02 21:38:12 +0200 | AlexNoo_ | AlexNoo |
| 2023-10-02 21:42:28 +0200 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 255 seconds) |
| 2023-10-02 21:43:10 +0200 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-10-02 21:45:19 +0200 | danza_ | (~francesco@151.43.118.113) (Ping timeout: 264 seconds) |
| 2023-10-02 21:45:26 +0200 | ubert | (~Thunderbi@91.141.57.144.wireless.dyn.drei.com) |
| 2023-10-02 21:55:03 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) |
| 2023-10-02 21:57:49 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-10-02 22:09:06 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-10-02 22:12:20 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-10-02 22:19:14 +0200 | euleritian | (~euleritia@185.238.219.28) |
| 2023-10-02 22:25:48 +0200 | artem | (~artem@73.145.240.174) |
| 2023-10-02 22:29:11 +0200 | ulysses4ever | (~artem@2601:249:4380:8950:8cb8:b1ce:18cd:1b77) (Ping timeout: 260 seconds) |
| 2023-10-02 22:31:28 +0200 | EvanR | (~EvanR@user/evanr) |
| 2023-10-02 22:32:09 +0200 | pavonia | (~user@user/siracusa) |
| 2023-10-02 22:32:25 +0200 | artem | (~artem@73.145.240.174) (Ping timeout: 255 seconds) |
| 2023-10-02 22:36:14 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-10-02 22:37:36 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-10-02 22:37:37 +0200 | ulysses4ever | (~artem@73.145.240.174) |
| 2023-10-02 22:39:52 +0200 | bilegeek | (~bilegeek@2600:1008:b026:1a87:2ee8:e964:d4e2:13c1) (Quit: Leaving) |
| 2023-10-02 22:41:32 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-10-02 22:44:02 +0200 | rw | (~rw@136.226.101.20) (Quit: Client closed) |
| 2023-10-02 22:45:57 +0200 | jabuxas | (~jabuxas@user/jabuxas) (Remote host closed the connection) |
| 2023-10-02 22:46:25 +0200 | jabuxas | (~jabuxas@user/jabuxas) |
| 2023-10-02 22:49:34 +0200 | artem | (~artem@c-73-103-90-145.hsd1.in.comcast.net) |
| 2023-10-02 22:51:46 +0200 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.5) |
| 2023-10-02 22:51:55 +0200 | ulysses4ever | (~artem@73.145.240.174) (Read error: Connection reset by peer) |
| 2023-10-02 22:54:23 +0200 | cpressey | (~cpressey@host-89-240-119-146.as13285.net) (Quit: Client closed) |
| 2023-10-02 23:00:06 +0200 | Square3 | (~Square4@user/square) |
| 2023-10-02 23:03:21 +0200 | zer0bitz_ | (~zer0bitz@user/zer0bitz) |
| 2023-10-02 23:03:32 +0200 | Square | (~Square@user/square) (Ping timeout: 272 seconds) |
| 2023-10-02 23:05:32 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex) |
| 2023-10-02 23:06:23 +0200 | jabuxas | (~jabuxas@user/jabuxas) (Remote host closed the connection) |
| 2023-10-02 23:06:46 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 258 seconds) |
| 2023-10-02 23:07:05 +0200 | stites | (~stites@130.44.147.204) (Ping timeout: 240 seconds) |
| 2023-10-02 23:07:57 +0200 | stites | (~stites@2607:fb90:ad61:8dda:f76b:db35:422d:4ab8) |
| 2023-10-02 23:14:46 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2023-10-02 23:15:36 +0200 | <tomsmeding> | https://ircbrowse.tomsmeding.com/day/lchaskell/2023/10/02?id=1097074#trid1097074 |
| 2023-10-02 23:21:03 +0200 | jabuxas | (~jabuxas@user/jabuxas) |
| 2023-10-02 23:25:23 +0200 | michalz | (~michalz@185.246.204.126) (Remote host closed the connection) |
| 2023-10-02 23:28:05 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds) |
| 2023-10-02 23:36:56 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-10-02 23:41:05 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) (Remote host closed the connection) |
| 2023-10-02 23:41:24 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) |
| 2023-10-02 23:44:19 +0200 | johnw | (~johnw@69.62.242.138) (Quit: ZNC - http://znc.in) |
| 2023-10-02 23:44:47 +0200 | johnw | (~johnw@69.62.242.138) |
| 2023-10-02 23:50:07 +0200 | chomwitt | (~chomwitt@2a02:587:7a24:b000:1ac0:4dff:fedb:a3f1) (Ping timeout: 264 seconds) |
| 2023-10-02 23:51:32 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-10-02 23:52:37 +0200 | hippoid | (~hippoid@user/hippoid) |
| 2023-10-02 23:53:49 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-10-02 23:54:49 +0200 | stites | (~stites@2607:fb90:ad61:8dda:f76b:db35:422d:4ab8) (Read error: Connection reset by peer) |
| 2023-10-02 23:55:09 +0200 | stites | (~stites@130.44.147.204) |
| 2023-10-02 23:59:06 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-10-02 23:59:08 +0200 | <hippoid> | can someone explain to me what is happening on line 34? I think it's a section with traverse and bind, but can't make sense of it. I tried getting very explicit about the types, but still line 34 is baffling: https://gist.github.com/idrisr/700d4263f876360b862ce404ee1455b5 |
