Home liberachat/#haskell: Logs Calendar

Logs on 2023-10-02 (liberachat/#haskell)

00:00:11 × Tuplanolla quits (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 255 seconds)
00:05:58 × spacenautx quits (~spacenaut@user/spacenautx) (Quit: WeeChat 4.0.5)
00:15:13 → arahael joins (~arahael@1.145.14.170)
00:26:49 × eggplantade quits (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection)
00:32:16 → danza_ joins (~francesco@151.47.126.103)
00:35:11 × dolio quits (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in)
00:41:57 → dolio joins (~dolio@130.44.134.54)
00:45:51 × Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 258 seconds)
00:46:00 → czy joins (~user@121.231.44.109)
00:47:26 × fweht quits (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
00:47:43 × danza_ quits (~francesco@151.47.126.103) (Ping timeout: 264 seconds)
00:48:21 → Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915)
00:48:59 × arahael quits (~arahael@1.145.14.170) (Quit: "Gotta run!")
00:49:41 × czy quits (~user@121.231.44.109) (Remote host closed the connection)
00:59:28 → czy joins (~user@121.231.44.109)
01:04:43 → eggplantade joins (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72)
01:06:01 × Unicorn_Princess quits (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving)
01:11:29 × cifrlltb^ quits (~cd@76.145.193.217) (Remote host closed the connection)
01:24:07 × captnemo quits (~captnemo@193.32.127.239) (Quit: WeeChat 4.0.4)
01:31:53 × machinedgod quits (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds)
01:32:28 × eggplantade quits (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection)
01:32:43 → eggplantade joins (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72)
01:33:28 × otto_s quits (~user@p5de2facb.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
01:34:58 → otto_s joins (~user@p5b0445cd.dip0.t-ipconnect.de)
01:41:55 × hsw quits (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Quit: Leaving)
01:42:07 → hsw joins (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net)
02:06:05 × td_ quits (~td@i5387090d.versanet.de) (Ping timeout: 272 seconds)
02:07:12 → td_ joins (~td@i5387092A.versanet.de)
02:07:40 × [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds)
02:17:32 × FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
02:17:32 → finn_elija joins (~finn_elij@user/finn-elija/x-0085643)
02:17:32 finn_elija is now known as FinnElija
02:30:48 → vglfr joins (~vglfr@88.154.40.15)
02:35:07 × vglfr quits (~vglfr@88.154.40.15) (Ping timeout: 255 seconds)
03:03:51 × td_ quits (~td@i5387092A.versanet.de) (Ping timeout: 260 seconds)
03:05:17 → td_ joins (~td@i5387090C.versanet.de)
03:12:19 × asivitz quits (uid178348@id-178348.tinside.irccloud.com) (Quit: Connection closed for inactivity)
03:21:05 × bilegeek quits (~bilegeek@2600:1008:b0aa:d121:12f8:f5f4:a6fd:d8ea) (Remote host closed the connection)
03:22:04 → Warr joins (~Admin1@47.200.75.232)
03:23:52 × srk quits (~sorki@user/srk) (Remote host closed the connection)
03:24:11 → srk joins (~sorki@user/srk)
03:24:51 × Warr quits (~Admin1@47.200.75.232) (Remote host closed the connection)
03:31:43 × cptaffe quits (~cptaffe@user/cptaffe) (Remote host closed the connection)
03:32:03 → sm joins (~sm@plaintextaccounting/sm)
03:34:22 → cptaffe joins (~cptaffe@user/cptaffe)
03:36:32 × sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 255 seconds)
03:37:50 → vglfr joins (~vglfr@88.155.145.28)
03:41:02 × segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 258 seconds)
03:54:58 → aforemny_ joins (~aforemny@2001:9e8:6cea:5700:875:b49a:e016:4759)
03:56:21 × aforemny quits (~aforemny@2001:9e8:6cc3:2d00:4daa:999d:f37:1162) (Ping timeout: 260 seconds)
03:58:55 × sabino quits (~sabino@user/sabino) (Quit: Lambda _ -> x)
04:00:04 × wroathe quits (~wroathe@user/wroathe) (Ping timeout: 272 seconds)
04:01:32 → actioninja joins (~actioninj@user/actioninja)
04:05:26 × CAT_S quits (apic@brezn3.muc.ccc.de) (Ping timeout: 255 seconds)
04:06:26 → sm joins (~sm@plaintextaccounting/sm)
04:07:52 → _ht joins (~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
04:10:33 × krei-se quits (~krei-se@p50874770.dip0.t-ipconnect.de) (Quit: ZNC 1.8.2 - https://znc.in)
04:11:10 × sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 252 seconds)
04:12:11 × poscat quits (~poscat@user/poscat) (Quit: Bye)
04:16:16 → poscat joins (~poscat@user/poscat)
04:18:16 → CAT_S joins (apic@brezn3.muc.ccc.de)
04:20:04 × _xor quits (~xor@ip-50-5-233-250.dynamic.fuse.net) (Quit: Ping timeout (120 seconds))
04:20:39 → _xor joins (~xor@ip-50-5-233-250.dynamic.fuse.net)
04:25:48 × cptaffe quits (~cptaffe@user/cptaffe) (Remote host closed the connection)
04:27:31 → cptaffe joins (~cptaffe@user/cptaffe)
04:29:29 → nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net)
04:34:20 × nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 248 seconds)
04:35:44 × FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
04:37:31 → FinnElija joins (~finn_elij@user/finn-elija/x-0085643)
04:37:44 → michalz joins (~michalz@185.246.204.125)
04:52:54 → qqq joins (~qqq@92.43.167.61)
04:53:38 × xff0x quits (~xff0x@2405:6580:b080:900:b248:55c0:81a8:90d4) (Remote host closed the connection)
04:53:57 → xff0x joins (~xff0x@2405:6580:b080:900:2499:90fc:2915:781d)
04:59:43 → sm joins (~sm@plaintextaccounting/sm)
05:04:13 × sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 258 seconds)
05:12:09 → Jackneill joins (~Jackneill@20014C4E1E13B20020A43670487A9903.dsl.pool.telekom.hu)
05:17:49 → takuan joins (~takuan@178-116-218-225.access.telenet.be)
05:24:40 → chomwitt joins (~chomwitt@2a02:587:7a24:b000:1ac0:4dff:fedb:a3f1)
05:29:39 → krei-se joins (~krei-se@p50874770.dip0.t-ipconnect.de)
05:33:09 → sm joins (~sm@plaintextaccounting/sm)
05:37:48 × sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 248 seconds)
05:39:23 × _ht quits (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection)
05:43:24 → idgaen joins (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
05:48:09 × azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 252 seconds)
05:57:56 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
05:58:22 × vglfr quits (~vglfr@88.155.145.28) (Ping timeout: 260 seconds)
06:00:42 → sm joins (~sm@plaintextaccounting/sm)
06:01:37 → lisbeths joins (uid135845@id-135845.lymington.irccloud.com)
06:04:03 × lockywolf quits (~lockywolf@public.lockywolf.net) (Quit: ZNC 1.8.2 - https://znc.in)
06:05:01 × sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 252 seconds)
06:05:39 → lockywolf joins (~lockywolf@public.lockywolf.net)
06:06:05 → vglfr joins (~vglfr@88.155.249.83)
06:06:41 × vglfr quits (~vglfr@88.155.249.83) (Remote host closed the connection)
06:08:16 → hugo joins (znc@verdigris.lysator.liu.se)
06:09:39 → vglfr joins (~vglfr@88.155.249.83)
06:12:52 → raym joins (~ray@user/raym)
06:17:58 <haskellbridge> <t​ewuzij> What is Hoogle?
06:20:08 <haskellbridge> <j​ade> a search engine for haskell functions in packages indexed on hackage
06:20:51 → sm joins (~sm@plaintextaccounting/sm)
06:22:25 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds)
06:25:22 × sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 252 seconds)
06:28:23 → hugo joins (znc@verdigris.lysator.liu.se)
06:29:07 <haskellbridge> <s​m> @where hoogle
06:32:24 × marinelli quits (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection)
06:32:47 → marinelli joins (~weechat@gateway/tor-sasl/marinelli)
06:33:48 → sord937 joins (~sord937@gateway/tor-sasl/sord937)
06:38:55 → simendsjo joins (~user@84.211.91.241)
06:39:39 → lortabac joins (~lortabac@2a01:e0a:541:b8f0:2aaa:42ea:b9cc:3d82)
06:40:04 × simendsjo quits (~user@84.211.91.241) (Remote host closed the connection)
06:44:38 × sord937 quits (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
06:45:00 → sord937 joins (~sord937@gateway/tor-sasl/sord937)
06:48:58 → simendsjo joins (~user@84.211.91.241)
06:51:10 × euleritian quits (~euleritia@185.238.219.110) (Ping timeout: 255 seconds)
06:53:13 → euleritian joins (~euleritia@185.238.219.66)
06:55:04 → Guest5851 joins (~Guest58@ext-1-173.eduroam.chalmers.se)
06:56:41 <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
06:56:42 <Guest5851> would have my pattern matches?
06:56:52 <Guest5851> A bit of a contrived example, but I think it makes my question clear
07:03:28 × vglfr quits (~vglfr@88.155.249.83) (Ping timeout: 255 seconds)
07:03:39 <probie> Yes. However, like inlining, you can explicitly specify which phase the rule is allowed to fire in, effectively giving precedence.
07:08:16 <dminuoso> Guest5851: Also checkout CONLIKE, which gives further indirect control.
07:12:02 → fweht joins (uid404746@id-404746.lymington.irccloud.com)
07:12:06 → CiaoSen joins (~Jura@2a05:5800:2a3:5900:664b:f0ff:fe37:9ef)
07:13:48 <tomsmeding> sm: lambdabot doesn't pick that up because your message starts with "<sm>" here :p
07:15:08 <haskellbridge> <s​m> I figured.. I'm hoping it will trigger a humanbot to complete the request 🤖😀
07:15:25 <tomsmeding> @where hoogle
07:15:25 <lambdabot> https://hoogle.haskell.org
07:16:10 <tomsmeding> % putStr "@where hoogle" -- sm
07:16:10 <yahb2> @where hoogle
07:16:10 <lambdabot> https://hoogle.haskell.org
07:17:26 <haskellbridge> <s​m> > 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.
07:32:14 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds)
07:39:43 → kuribas joins (~user@2a02:1808:4:8d81:4e29:dcbe:5b1e:d8a2)
07:40:24 <kuribas> Is it possible to turn multithreading off for accellerate-native?
07:40:29 <kuribas> I mean without turning it off globally, so I could still use multiple threads elsewhere.
07:42:07 <tomsmeding> kuribas: before I think about whether you can, _why_ :p
07:44:09 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
07:44:23 <tomsmeding> kuribas: if you're okay with pinning the accelerate-llvm-native thread to a single core, check out createTarget and run*With
07:45:26 <tomsmeding> kuribas: read the module documentation block https://hackage.haskell.org/package/accelerate-llvm-native-1.3.0.0/docs/Data-Array-Accelerate-LLVM-Native.html
07:45:28 <tomsmeding> RTFM ;)
07:47:10 → coot joins (~coot@89-69-206-216.dynamic.chello.pl)
07:47:43 × Guest5851 quits (~Guest58@ext-1-173.eduroam.chalmers.se) (Quit: Connection closed)
07:49:44 × Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer)
07:52:33 <kuribas> tomsmeding: ah right, runNWith should do the trick.
07:52:47 <tomsmeding> kuribas: check the env var
07:53:31 → danse-nr3 joins (~francesco@ge-19-121-23.service.infuturo.it)
07:53:33 <tomsmeding> that's without core pinning
07:54:36 × rgw quits (~R@2605:a601:a0df:5600:11bb:2f6e:7e71:f82c) (Read error: Connection reset by peer)
07:54:46 <kuribas> tomsmeding: the reason I want to do this is because I want to run it on streams of relatively small blocks.
07:54:54 <tomsmeding> ah
07:54:59 <kuribas> And keep the cores ready for other paralellism.
07:55:21 <kuribas> I don't think multiple threads makes much sense for small blocks (a few kbs).
07:55:32 <tomsmeding> I mean, always benchmark
07:55:36 <tomsmeding> but sounds reasonable
07:55:56 <kuribas> true, maybe I am premature optimizing...
07:55:58 <tomsmeding> depends on what you are doing with those small blocks :)
07:56:45 → machinedgod joins (~machinedg@d198-53-218-113.abhsia.telus.net)
07:57:13 <kuribas> mostly downsampling aggregations.
07:57:27 <kuribas> like adding, averaging, removing or interpolating NaNs...
07:57:45 <tomsmeding> doesn't sound terribly expensive
07:59:35 <kuribas> it isn't, but I am hoping the SIMD vectorization still gives a speedup.
07:59:36 × euleritian quits (~euleritia@185.238.219.66) (Ping timeout: 260 seconds)
08:00:03 <kuribas> Mostly by removing multiple loops, for example when applying some scale on the data.
08:00:14 <tomsmeding> right, that it should do at the very least
08:00:21 <tomsmeding> after that it's up to LLVM to do smart SIMD things
08:00:34 <tomsmeding> i.e. not very different from having written decent C code for this
08:00:53 <kuribas> Indeed, that is the goal, but dynamically at runtime.
08:05:49 <kuribas> So I can write a query on timeseries, and it will be compiled and cached at runtime.
08:06:06 <kuribas> Without the need to recompile and restart the whole application
08:06:07 × yahb2 quits (~yahb2@static.56.27.47.78.clients.your-server.de) (Remote host closed the connection)
08:06:19 → yahb2 joins (~yahb2@2a01:4f8:c0c:5c7b::2)
08:06:24 <tomsmeding> neat
08:06:26 → euleritian joins (~euleritia@185.238.219.3)
08:06:57 <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.
08:07:29 <tomsmeding> ... is that a rust or a python lib? I'm confused
08:07:37 <kuribas> both :)
08:07:42 <kuribas> But the core is written in rust.
08:07:54 <tomsmeding> I see
08:09:08 <kuribas> I am making a small static typed scheme like language, which then can be compiled to accelerate.
08:09:14 <nullie> I think SIMD is not about removing loops, it just utilizes computation units better
08:09:36 <kuribas> nullie: sure, python dataframe languages also use SIMD.
08:09:54 <kuribas> But each primitive operation is a loop over the data.
08:10:22 <tomsmeding> kuribas: do you `run` the in-flight computation whenever you get something that you can't encode in AcC?
08:10:24 <tomsmeding> *Acc
08:10:56 <tomsmeding> then the individual computations had better be large, because compiling an accelerate program is pretty expensive
08:11:06 <tomsmeding> sure, things are cached
08:11:12 × lisbeths quits (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
08:11:15 <tomsmeding> but that also takes up a bunch of disk space :p
08:11:30 × euleritian quits (~euleritia@185.238.219.3) (Ping timeout: 272 seconds)
08:12:00 <kuribas> tomsmeding: what do you mean?
08:12:13 <kuribas> Are these llvm compiled functions large?
08:12:26 <tomsmeding> not particularly
08:12:51 <tomsmeding> but if you run lots of slightly different programs, at some point it'll add up
08:13:06 <tomsmeding> ~/.cache/accelerate
08:13:40 → euleritian joins (~euleritia@185.238.219.47)
08:14:32 <kuribas> well, the goal to have a set of stored procedures which are parametrised.
08:14:41 <kuribas> So not every query is a new program.
08:14:45 <tomsmeding> sure
08:14:58 → danse-nr3_ joins (~francesco@151.37.123.134)
08:15:15 <kuribas> Does it read those programs from disk every time, or are they also cached in RAM?
08:15:18 <tomsmeding> I think the compiled accelerate programs do not even include `use` arrays, so you can change those and still hit the cache
08:15:20 × danse-nr3 quits (~francesco@ge-19-121-23.service.infuturo.it) (Read error: Connection reset by peer)
08:15:31 <tomsmeding> kuribas: I think it reads from disk each time, but disk caches are a thing, so it'll be RAM anyway
08:15:52 <kuribas> hmm, true
08:16:01 <tomsmeding> especially for small files like these
08:16:34 <kuribas> And are they compiled each time?
08:16:47 <kuribas> Or are they stored in native machine code?
08:16:48 <Hecate> morning folks
08:16:55 <kuribas> Morning!
08:17:04 <winny> good morning, make sure to eat well :)
08:20:02 <kuribas> tomsmeding: actually, reading those files for *each* small array computation will like completely swamp any performance benifit I would get from SIMD.
08:20:06 <kuribas> even cached in memory.
08:20:35 <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
08:20:51 <tomsmeding> the cache is (optimised accelerate program) -> (optimised LLVM-compiled binary)
08:21:01 <tomsmeding> so you're paying for fusion etc each time anyway
08:21:14 <tomsmeding> as well as linking the .so in
08:21:27 <tomsmeding> I'm not sure this is the right trade-off
08:21:44 <kuribas> Each time of adding a new function, or each time of calling it?
08:21:53 <tomsmeding> each time invoking `run`
08:22:02 <tomsmeding> if you `runN` once and call the resulting Afunction multiple times, that's cheap
08:22:21 <tomsmeding> (and that's the intended use-case)
08:22:52 <tomsmeding> (er, AfunctionR)
08:23:10 <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
08:23:10 <kuribas> run."
08:23:24 <tomsmeding> yes
08:23:30 × tzh quits (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz)
08:23:50 <kuribas> SO this doesn't go through the disk cache?
08:24:07 <tomsmeding> calling that AfunctionR multiple times should do very little except running the compiled code
08:24:20 <tomsmeding> it's calling runN another time that is expensive
08:24:46 <tomsmeding> (laziness is done correctly so that seq'ing (runN f) does all the compilation)
08:25:03 <tomsmeding> (strictness, rather)
08:26:39 <tomsmeding> JITing is expensive :p
08:26:58 → kuribas` joins (~user@ip-188-118-57-242.reverse.destiny.be)
08:27:11 <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
08:28:12 × kuribas quits (~user@2a02:1808:4:8d81:4e29:dcbe:5b1e:d8a2) (Ping timeout: 240 seconds)
08:29:01 → mmhat joins (~mmh@p200300f1c74e6fafee086bfffe095315.dip0.t-ipconnect.de)
08:30:02 × poscat quits (~poscat@user/poscat) (Quit: Bye)
08:30:02 × mmhat quits (~mmh@p200300f1c74e6fafee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
08:30:05 <kuribas`> True, I could start with just unfused compile time loops, then see if JIT optimizing the loops gives an effect
08:30:19 × euleritian quits (~euleritia@185.238.219.47) (Ping timeout: 264 seconds)
08:30:52 → euleritian joins (~euleritia@185.238.219.30)
08:31:01 → poscat joins (~poscat@user/poscat)
08:31:27 → nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net)
08:32:14 <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.
08:32:40 <tomsmeding> true
08:33:05 → vglfr joins (vglfr@gateway/vpn/protonvpn/vglfr)
08:33:13 <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
08:33:37 <kuribas`> And slower?
08:33:47 <tomsmeding> hm?
08:33:55 <tomsmeding> it's passed through LLVM which will do a good job, presumably
08:34:01 <tomsmeding> but compilation will be slower, yes
08:34:12 <tomsmeding> accelerate's compilation pipeline itself is not particularly optimised
08:34:17 × idgaen quits (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.5)
08:34:25 <tomsmeding> (in fact, for certain kinds of programs, it can be downright slow)
08:34:28 <kuribas`> Well, my plan was to use compilation for stored procedures, and interpretation for one off queries.
08:34:52 <kuribas`> I don't mind, as long is it doesn't cause long GC pauses for the rest of the program.
08:34:59 <tomsmeding> then you should probably compile a procedure to accelerate _once_ per invocation of the interpreter
08:35:22 <tomsmeding> i.e. keep a closure around for the compiled version of the stored procedure, that retains the AfunctionR's obtained from runN
08:35:30 <tomsmeding> then it should be good
08:35:48 <kuribas`> yeah that.
08:35:56 <tomsmeding> kuribas`: it's the _running_ of the accelerate program that could give you long GC pauses
08:35:56 <kuribas`> Or even use another library (Massive?)
08:35:59 <tomsmeding> compilation won't
08:36:06 <tomsmeding> massiv, also check out repa
08:36:17 <tomsmeding> they don't do JITing AFAIU
08:36:22 <kuribas`> Yeah, sadly I cannot preallocate arrays using accelerate.
08:36:35 × nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
08:36:47 <tomsmeding> in what sense?
08:36:56 <tomsmeding> A.fromList will do some allocation that's suitable for the native backend
08:37:32 × euleritian quits (~euleritia@185.238.219.30) (Ping timeout: 248 seconds)
08:37:36 <kuribas`> In the sense of keeping a collection of preallocated blocks for intermediate calculations.
08:37:48 <tomsmeding> ah
08:37:48 <tomsmeding> no
08:37:51 <kuribas`> That don't need to use malloc.
08:37:58 <tomsmeding> but malloc is not the bottleneck
08:38:03 <tomsmeding> typically
08:38:15 <kuribas`> right
08:39:36 <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
08:41:51 <kuribas`> right
08:48:19 × poscat quits (~poscat@user/poscat) (Quit: Bye)
08:48:49 → poscat joins (~poscat@user/poscat)
08:48:53 → hugo joins (znc@verdigris.lysator.liu.se)
08:49:31 × xff0x quits (~xff0x@2405:6580:b080:900:2499:90fc:2915:781d) (Ping timeout: 264 seconds)
08:49:34 → sm joins (~sm@plaintextaccounting/sm)
08:50:11 <haskellbridge> <I​nst> ...
08:50:20 × vglfr quits (vglfr@gateway/vpn/protonvpn/vglfr) (Ping timeout: 248 seconds)
08:51:19 → xff0x joins (~xff0x@2405:6580:b080:900:bb62:225f:513:94b7)
08:52:13 <haskellbridge> <I​nst> 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
08:52:29 <haskellbridge> <I​nst> and you assign it its properties based on a deriving clause?
08:52:58 × poscat quits (~poscat@user/poscat) (Client Quit)
08:53:20 → poscat joins (~poscat@user/poscat)
08:54:38 × poscat quits (~poscat@user/poscat) (Remote host closed the connection)
08:54:59 → poscat joins (~poscat@user/poscat)
09:02:45 × poscat quits (~poscat@user/poscat) (Quit: Bye)
09:03:16 → poscat joins (~poscat@user/poscat)
09:03:23 → migas joins (~migas@astra4961.startdedicated.net)
09:07:10 × poscat quits (~poscat@user/poscat) (Client Quit)
09:07:30 → poscat joins (~poscat@user/poscat)
09:07:48 aforemny_ is now known as aforemny
09:11:27 × eggplantade quits (~Eggplanta@2600:1700:38c5:d800:dff:1f4:b04b:da72) (Remote host closed the connection)
09:14:26 → poscat0x04 joins (~poscat@user/poscat)
09:16:01 × poscat quits (~poscat@user/poscat) (Ping timeout: 260 seconds)
09:20:16 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 252 seconds)
09:23:55 × sm quits (~sm@plaintextaccounting/sm) (Quit: sm)
09:27:03 × econo_ quits (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
09:31:14 → sm joins (~sm@plaintextaccounting/sm)
09:31:51 → hugo joins (znc@verdigris.lysator.liu.se)
09:33:19 × shryke quits (~shryke@2a00:4b00:13c:cc:b27b:25ff:fe18:efd) (Quit: WeeChat 4.0.4)
09:34:33 → Inst joins (~Inst@120.244.192.250)
09:34:48 ← Inst parts (~Inst@120.244.192.250) (Leaving)
09:34:51 → shryke joins (~shryke@2a00:4b00:13c:cc:b27b:25ff:fe18:efd)
09:39:03 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
09:40:58 → Square3 joins (~Square4@user/square)
09:40:59 → __monty__ joins (~toonn@user/toonn)
09:45:56 → eggplantade joins (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555)
09:50:55 → masaeedu joins (~masaeedu@modemcable068.99-80-70.mc.videotron.ca)
09:51:15 <masaeedu> Hello folks
09:51:57 <masaeedu> Was reading through this thread: https://groups.google.com/g/haskell-pipes/c/JFfyquj5HAg/m/Lxz7p50JOh4J
09:52:44 <masaeedu> There's some pretty great ideas in there on how to interface with child processes asynchronously
09:53:56 <masaeedu> Do you folks have any recommendations on libraries in this vein (async child process interaction) that have worked well for you?
09:54:01 → hugo joins (znc@verdigris.lysator.liu.se)
09:54:04 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection)
09:54:24 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
09:58:12 <haskellbridge> <s​m> masaeedu: the async package certainly
09:59:45 <haskellbridge> <s​m> and maybe typed-process or something in the conduit packages ?
10:11:42 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection)
10:12:01 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
10:13:46 × lg188 quits (~lg188@82.18.98.230) (Ping timeout: 260 seconds)
10:15:01 <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.
10:16:18 <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
10:16:45 <masaeedu> i could be misreading thouhg
10:17:56 <haskellbridge> <s​m> for terminal stuff, https://hackage.haskell.org/package/concurrent-output is a cool one
10:22:32 <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
10:22:54 <masaeedu> could be useful for testing though
10:23:52 × jjhoo quits (~jahakala@user/jjhoo) (Ping timeout: 272 seconds)
10:27:44 <kuribas`> tomsmeding: I also suppose arrays only have a single pointer, so they don't contribute a lot to GC time.
10:28:21 × danse-nr3_ quits (~francesco@151.37.123.134) (Ping timeout: 260 seconds)
10:35:03 → vglfr joins (~vglfr@88.155.142.130)
10:35:54 × qqq quits (~qqq@92.43.167.61) (Remote host closed the connection)
10:44:07 <haskellbridge> <m​auke> Terminal stuff is more complicated; for that, you have to implement a pseudo-terminal
10:44:16 × vglfr quits (~vglfr@88.155.142.130) (Ping timeout: 255 seconds)
10:45:29 <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
10:52:32 → vglfr joins (~vglfr@88.155.142.130)
10:53:00 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
10:55:37 → danse-nr3 joins (~francesco@151.37.123.134)
10:56:44 × vglfr quits (~vglfr@88.155.142.130) (Ping timeout: 248 seconds)
10:58:38 × tcard quits (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Read error: Connection reset by peer)
10:58:41 → tcard_ joins (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
10:59:14 × CiaoSen quits (~Jura@2a05:5800:2a3:5900:664b:f0ff:fe37:9ef) (Ping timeout: 246 seconds)
11:00:28 × sm quits (~sm@plaintextaccounting/sm) (Quit: sm)
11:00:48 × jargon quits (~jargon@184.101.67.95) (Remote host closed the connection)
11:01:28 → sm joins (~sm@plaintextaccounting/sm)
11:04:13 → hiyori joins (~hiyori@user/hiyori)
11:05:58 × sm quits (~sm@plaintextaccounting/sm) (Client Quit)
11:06:32 × m1dnight quits (~christoph@78-22-4-67.access.telenet.be) (Quit: WeeChat 4.0.4)
11:06:48 → m1dnight joins (~christoph@78-22-4-67.access.telenet.be)
11:07:13 × danse-nr3 quits (~francesco@151.37.123.134) (Ping timeout: 255 seconds)
11:16:20 → lg188 joins (~lg188@82.18.98.230)
11:26:54 → hugo joins (znc@verdigris.lysator.liu.se)
11:27:05 × stites quits (~stites@130.44.147.204) (Ping timeout: 240 seconds)
11:28:29 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection)
11:28:48 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
11:29:41 → stites joins (~stites@2607:fb90:ad62:9844:b792:bda4:37c7:7710)
11:42:50 × masaeedu quits (~masaeedu@modemcable068.99-80-70.mc.videotron.ca) (Quit: WeeChat 4.0.2)
11:47:46 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection)
11:48:04 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
11:50:53 → [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
11:52:51 → Unicorn_Princess joins (~Unicorn_P@user/Unicorn-Princess/x-3540542)
11:54:36 → Feuermagier_ joins (~Feuermagi@user/feuermagier)
11:54:36 × Feuermagier quits (~Feuermagi@user/feuermagier) (Killed (calcium.libera.chat (Nickname regained by services)))
11:54:36 Feuermagier_ is now known as Feuermagier
11:59:54 → Guest5529 joins (~Guest55@ext-1-173.eduroam.chalmers.se)
12:00:50 <Guest5529> I am trying to write template haskell code that emits some rewrite rules, but they are rejected because they contain redundant parenthesis.
12:00:50 <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?
12:01:49 <dminuoso> Guest5529: What are you using to pretty print the code with, exactly?
12:02:36 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 240 seconds)
12:03:12 × michalz quits (~michalz@185.246.204.125) (Ping timeout: 258 seconds)
12:05:35 <Guest5529> The code I am seeing is shown in a GHC error message
12:05:41 <Guest5529> So whatever is the default, I guess?
12:05:45 → michalz joins (~michalz@185.246.204.126)
12:06:10 <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
12:06:39 <haskellbridge> <m​auke> I see a package called posix-pty on hackage
12:06:49 <dminuoso> Guest5529: What do you mean by "default". Can you show your template haskell code?
12:07:08 <Guest5529> How would you like me to share it? I don't mind
12:07:37 <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.
12:07:48 <dminuoso> https://paste.tomsmeding.com
12:10:34 <Guest5529> Does this work? https://paste.tomsmeding.com/GkTmNkdF
12:12:33 <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
12:12:45 <Guest5529> sorry, the AppE above should be VarE
12:12:54 <dminuoso> Guest5529: No worry, its enough for me to get the idea.
12:13:06 <Guest5529> Thanks, I would appreciate any help
12:13:15 <Guest5529> I am open for hacks, regardless of how greasy they are
12:13:26 <dminuoso> I would say, try to make a simple testcase and file it as a bug report on ghc itself.
12:13:43 <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.
12:14:08 <Guest5529> If I manually copy the rule the error is presenting, and only removes the parenthesis around `locally server`, the rule is accepted
12:14:18 <dminuoso> The ADT shouldnt even let you admit specifying some AST that is invalid syntax.
12:15:17 <Guest5529> Sigh, so maybe this is not a quick fix
12:15:21 <Guest5529> I will open an issue
12:15:55 <int-e> compare https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/ThToHs.hs#L1044-1046
12:16:23 <int-e> (That's where the "extra" parentheses come from)
12:16:58 × hiyori quits (~hiyori@user/hiyori) (Quit: Client closed)
12:17:10 <dminuoso> int-e: Im curious, what is this output of cvtl exactly?
12:17:25 <dminuoso> Arent parenthesis lexical information already? How does that fit into a TH splice?
12:17:52 <dminuoso> Or does TH quite literally splice lexical chunks in place?
12:18:23 → hugo- joins (znc@verdigris.lysator.liu.se)
12:19:05 <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.
12:19:20 <Guest5529> Hm I managed to find a hack just now, by trying a different syntax
12:19:43 <dminuoso> Which are you using instead?
12:19:54 <Guest5529> `locallyLHS endpoint = UInfixE (VarE $ mkName endpoint) (VarE $ mkName "locally") ((VarE $ mkName "f"))` will render as `server `locally` f`, which is accepted
12:20:05 <dminuoso> Heh.
12:20:09 <Guest5529> It works because I have a 2-ary function
12:20:10 <int-e> dminuoso: It's an AST but for some reason, presumably pretty-printing (maybe infix operators) it preserves parentheses.
12:20:11 <Guest5529> Greasy
12:20:29 <dminuoso> Guest5529: Nice to see you have a workaround. But do please file a bug report regardless.
12:20:39 <Guest5529> The rule still seems to fire even if the program I am compiling contains `local server f`
12:20:45 <int-e> Oh in fact that same type may be used before and after fixity resolution? No clue, really.
12:20:47 <Guest5529> So that is nice
12:21:04 <int-e> Guest5529: lol
12:21:08 <Guest5529> Amazing
12:21:26 <int-e> (it'll stop working if you have more than two arguments, but it is a clever hack)
12:21:53 <Guest5529> I am fortunate, I need to add some optimizations for three different functions but they are all 2-ary
12:22:27 <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.
12:23:03 <Guest5529> I was amazed that I could even emit rules with TH
12:23:07 <Guest5529> I like it
12:23:08 <dminuoso> What I dont quite get is why this generates redundant parenthesis at all
12:23:08 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds)
12:23:18 <dminuoso> parenthesizeHsExpr seems to accept precedence parameters
12:23:31 <dminuoso> It feels like TH should be smart enough to not do this.
12:23:41 <int-e> maybe
12:23:50 <int-e> open a ticket, leave it to the devs :)
12:24:11 <Guest5529> Opening it as we speak, preparing the issue
12:25:04 × bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
12:26:57 <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.
12:29:20 <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)
12:30:27 → acidjnk_new joins (~acidjnk@p200300d6e7072f61505e043ab51d70dd.dip0.t-ipconnect.de)
12:32:58 → nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net)
12:35:34 × todi quits (~todi@p5dca5e79.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
12:38:15 → todi joins (~todi@p5dca5e79.dip0.t-ipconnect.de)
12:38:28 × nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 258 seconds)
12:38:37 → hugo- joins (znc@verdigris.lysator.liu.se)
12:41:02 × czy quits (~user@121.231.44.109) (Remote host closed the connection)
12:41:46 → danse-nr3 joins (~francesco@151.35.117.238)
12:41:49 <Guest5529> https://gitlab.haskell.org/ghc/ghc/-/issues/24046
12:43:40 → czy joins (~user@121.231.44.109)
12:44:56 × acidjnk_new quits (~acidjnk@p200300d6e7072f61505e043ab51d70dd.dip0.t-ipconnect.de) (Ping timeout: 246 seconds)
12:45:26 × ubert quits (~Thunderbi@178.115.46.96.wireless.dyn.drei.com) (Ping timeout: 260 seconds)
12:45:31 → acidjnk_new joins (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de)
12:49:25 → qqq joins (~qqq@92.43.167.61)
12:49:28 × AlexZenon quits (~alzenon@178.34.161.162) (Quit: ;-)
12:49:50 × Alex_test quits (~al_test@178.34.161.162) (Quit: ;-)
12:50:13 × AlexNoo quits (~AlexNoo@178.34.161.162) (Quit: Leaving)
12:56:11 × albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
12:57:35 <Guest5529> Apparently my TH problem is patched in 9.6, which is great dminuoso
12:59:02 <int-e> oh, great timing
13:01:49 × Feuermagier quits (~Feuermagi@user/feuermagier) (Quit: Leaving)
13:05:44 × stites quits (~stites@2607:fb90:ad62:9844:b792:bda4:37c7:7710) (Read error: Connection reset by peer)
13:06:03 → stites joins (~stites@130.44.147.204)
13:12:38 → AlexNoo joins (~AlexNoo@178.34.161.162)
13:13:27 → sabino joins (~sabino@user/sabino)
13:13:36 × acidjnk_new quits (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
13:14:16 <kuribas`> Does native ghc support simd? Will massiv compile to vectorised code, or just on LLVM?
13:15:24 <dminuoso> kuribas`: Yes and no.
13:15:41 <dminuoso> GHC has vector primops available, but you have to explicitly select them.
13:16:09 <dminuoso> There is no builtin auto vectorization (there were a few attempts at this, but they have gone stale)
13:16:38 <dminuoso> So whether massiv uses vectorised code, you have to check the massiv codebase whether it (directly or indirectly) uses vectorized primops
13:16:46 → AlexZenon joins (~alzenon@178.34.161.162)
13:17:22 <kuribas`> ok, and if it doesn't, selecting llvm can vectorize the code?
13:18:23 × EvanR quits (~EvanR@user/evanr) (Remote host closed the connection)
13:18:44 → EvanR joins (~EvanR@user/evanr)
13:19:58 <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.
13:20:55 × stiell quits (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
13:22:03 → acidjnk_new joins (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de)
13:22:06 → stiell joins (~stiell@gateway/tor-sasl/stiell)
13:22:28 → Alex_test joins (~al_test@178.34.161.162)
13:22:56 <dminuoso> https://github.com/lehins/massiv/issues/80
13:23:04 → czy` joins (~user@121.231.44.109)
13:23:56 × czy quits (~user@121.231.44.109) (Quit: ERC 5.6-git (IRC client for GNU Emacs 30.0.50))
13:23:58 × czy` quits (~user@121.231.44.109) (Remote host closed the connection)
13:24:41 → czy joins (~user@121.231.44.109)
13:30:27 <kuribas`> well, that claimed a 4x performance increase :)
13:30:57 <dminuoso> Which part of that?
13:31:31 → ystael joins (~ystael@user/ystael)
13:31:32 <dminuoso> Ah I see.
13:31:40 <kuribas`> https://github.com/lehins/massiv/issues/80#issuecomment-508237610
13:32:17 <dminuoso> Id have to look deeper at the examples. But if LLVM vectorization works that good, then great I guess?
13:32:44 <dminuoso> However, Im not entirely sure what "native GHC SIMD (llvm)" refers to.
13:33:16 <kuribas`> I suppose LLVM backend, not native backend.
13:33:54 → ulysses4ever joins (~artem@2601:249:4380:8950:8cb8:b1ce:18cd:1b77)
13:35:00 → albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8)
13:35:29 × albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
13:35:30 <dminuoso> A-ha. https://gitlab.haskell.org/ghc/ghc/-/issues/7741
13:35:38 <dminuoso> It seems that you have to use LLVM even for simd primops.
13:35:40 → albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8)
13:36:26 <kuribas`> I remember there was once SIMD support that was later removed.
13:36:53 <dminuoso> Well, SIMD support for NCG.
13:41:49 × acidjnk_new quits (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) (Remote host closed the connection)
13:42:33 → acidjnk_new joins (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de)
13:45:00 → gatekempt joins (~gatekempt@user/gatekempt)
13:45:19 × _d0t quits (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 264 seconds)
13:46:42 → wroathe joins (~wroathe@207-153-38-140.fttp.usinternet.com)
13:46:42 × wroathe quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
13:46:42 → wroathe joins (~wroathe@user/wroathe)
13:53:48 → _d0t joins (~{-d0t-}@user/-d0t-/x-7915216)
13:55:39 × xff0x quits (~xff0x@2405:6580:b080:900:bb62:225f:513:94b7) (Read error: Connection reset by peer)
13:56:46 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection)
13:57:05 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
14:00:13 → xff0x joins (~xff0x@2405:6580:b080:900:2382:d87:4dd6:d990)
14:02:52 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 248 seconds)
14:07:49 → hugo- joins (znc@verdigris.lysator.liu.se)
14:07:53 × wroathe quits (~wroathe@user/wroathe) (Ping timeout: 255 seconds)
14:08:34 × Guest5529 quits (~Guest55@ext-1-173.eduroam.chalmers.se) (Quit: Connection closed)
14:25:10 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds)
14:37:32 × danse-nr3 quits (~francesco@151.35.117.238) (Ping timeout: 248 seconds)
14:38:09 → hugo- joins (znc@verdigris.lysator.liu.se)
14:40:33 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Ping timeout: 245 seconds)
14:42:07 → waleee joins (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
14:45:45 → Guest30 joins (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9)
14:47:21 × waleee quits (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 260 seconds)
14:48:32 → waleee joins (~waleee@h-176-10-137-138.NA.cust.bahnhof.se)
14:51:52 → danse-nr3 joins (~francesco@151.35.117.238)
14:54:07 × waleee quits (~waleee@h-176-10-137-138.NA.cust.bahnhof.se) (Ping timeout: 252 seconds)
14:54:09 → Guest|20 joins (~Guest|20@145.108.66.99)
14:54:22 × Guest|20 quits (~Guest|20@145.108.66.99) (Client Quit)
14:56:10 → captnemo joins (~captnemo@193.32.127.239)
14:58:11 → segfaultfizzbuzz joins (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
15:01:23 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
15:05:14 × lortabac quits (~lortabac@2a01:e0a:541:b8f0:2aaa:42ea:b9cc:3d82) (Quit: WeeChat 2.8)
15:09:43 × segfaultfizzbuzz quits (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Quit: segfaultfizzbuzz)
15:14:13 → Guest|40 joins (~Guest|40@138-38-227-107.wireless.bath.ac.uk)
15:14:58 → idgaen joins (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
15:19:50 × rickbonavigo quits (~rickbonav@2a00:6d43:500:801:978b:c04c:d728:3c46) (Quit: ZNC 1.8.2 - https://znc.in)
15:21:10 × Guest|40 quits (~Guest|40@138-38-227-107.wireless.bath.ac.uk) (Quit: Connection closed)
15:21:10 → rickbonavigo joins (~rickbonav@ip185-157-107-176.pool-bba.aruba.it)
15:23:28 × Guest30 quits (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9) (Quit: Client closed)
15:25:48 → jabuxas joins (~jabuxas@user/jabuxas)
15:27:40 × rickbonavigo quits (~rickbonav@ip185-157-107-176.pool-bba.aruba.it) (Quit: ZNC 1.8.2 - https://znc.in)
15:32:12 → azimut joins (~azimut@gateway/tor-sasl/azimut)
15:35:14 → Guest30 joins (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9)
15:35:46 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
15:36:51 <haskellbridge> <r​ickbonavigo> !nick
15:39:03 × doyougnu- quits (~doyougnu@45.46.170.68) (Ping timeout: 240 seconds)
15:39:39 × tromp quits (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
15:40:00 → hugo- joins (znc@verdigris.lysator.liu.se)
15:40:43 → vglfr joins (~vglfr@88.155.254.210)
15:40:49 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Remote host closed the connection)
15:41:09 → alexherbo2 joins (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net)
15:42:28 × Pozyomka quits (~pyon@user/pyon) (Quit: Pozyomka, my beloved: https://i.imgur.com/BMmVfTq.png)
15:42:50 × eggplantade quits (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) (Remote host closed the connection)
15:43:06 → eggplantade joins (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
15:47:34 × vglfr quits (~vglfr@88.155.254.210) (Ping timeout: 255 seconds)
15:48:33 × captnemo quits (~captnemo@193.32.127.239) (Quit: WeeChat 4.0.4)
15:50:19 <EvanR> <rickbonavigo>
15:50:57 × Guest30 quits (~Guest30@2a00:6d43:500:801:3306:3d94:1e77:9fc9) (Quit: Client closed)
15:55:10 × jabuxas quits (~jabuxas@user/jabuxas) (Quit: Leaving.)
15:55:57 → vglfr joins (~vglfr@88.155.254.210)
15:58:14 → gmg joins (~user@user/gehmehgeh)
16:10:46 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
16:11:44 × machinedgod quits (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 255 seconds)
16:17:26 × vglfr quits (~vglfr@88.155.254.210) (Remote host closed the connection)
16:19:35 → vglfr joins (~vglfr@88.155.254.210)
16:22:13 × danse-nr3 quits (~francesco@151.35.117.238) (Ping timeout: 255 seconds)
16:22:45 → tzh joins (~tzh@c-71-193-181-0.hsd1.or.comcast.net)
16:23:07 × Square3 quits (~Square4@user/square) (Ping timeout: 255 seconds)
16:26:26 → cpressey joins (~cpressey@host-2-102-82-207.as13285.net)
16:28:54 × kuribas` quits (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1))
16:29:48 → danse-nr3 joins (~francesco@ge-19-120-4.service.infuturo.it)
16:32:21 <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
16:32:38 → jjhoo joins (~jahakala@user/jjhoo)
16:34:45 → nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net)
16:39:18 × alexherbo2 quits (~alexherbo@2a02-8440-3340-d3fe-1412-0c65-3696-c5b2.rev.sfr.net) (Ping timeout: 245 seconds)
16:39:56 × nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
16:41:19 <EvanR> 1 memory cell should be enough for anybody
16:41:43 geekosaur wonders how this relates to differentiation of types
16:42:53 <geekosaur> (that is, does this constitute a one-hole context?)
16:45:34 × EvanR quits (~EvanR@user/evanr) (Quit: Leaving)
16:46:07 <ncf> isn't a DFA basically just a monoid already, with initial and final states?
16:47:46 → hugo- joins (znc@verdigris.lysator.liu.se)
16:48:44 <ncf> well, a finite monoid i guess
16:51:55 → euleritian joins (~euleritia@2001:bc8:3f13:ffc2:90bc:54bf:aeae:e7ab)
16:52:37 → Square joins (~Square@user/square)
16:52:51 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 260 seconds)
16:56:27 × euleritian quits (~euleritia@2001:bc8:3f13:ffc2:90bc:54bf:aeae:e7ab) (Ping timeout: 258 seconds)
16:59:46 × acidjnk_new quits (~acidjnk@p200300d6e7072f619c9a5a82fd280133.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
16:59:53 × cpressey quits (~cpressey@host-2-102-82-207.as13285.net) (Quit: Client closed)
17:00:51 → ski joins (~ski@88.131.7.247)
17:01:22 <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?
17:02:02 <dminuoso> Specifically Im producing a big sum type as part of a parser, and I would like some guarantees I didnt forget any constructor
17:02:07 <tomsmeding> that would have way too many false positives if enabled for every sum type
17:02:34 <tomsmeding> it would need to be a pragma on one function for one sum type
17:02:37 × nckhexen quits (nckx@libera/staff/owl/nckx) (Quit: Updating my Guix System <https://guix.gnu.org>)
17:02:44 → hugo- joins (znc@verdigris.lysator.liu.se)
17:04:20 → AlexNoo_ joins (~AlexNoo@94.233.241.182)
17:04:29 <ski> (i guess you're looking for a (kind of) surjectivity check, as opposed to a (kind of) totality check (checking for missing fields) ..)
17:05:15 × pavonia quits (~user@user/siracusa) (Read error: Connection reset by peer)
17:06:01 → cpressey joins (~cpressey@host-2-102-82-207.as13285.net)
17:06:11 × AlexZenon quits (~alzenon@178.34.161.162) (Ping timeout: 255 seconds)
17:07:02 <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)
17:07:27 × AlexNoo quits (~AlexNoo@178.34.161.162) (Ping timeout: 240 seconds)
17:07:34 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 258 seconds)
17:07:47 → acidjnk joins (~acidjnk@p200300d6e7072f6198c60cc392982534.dip0.t-ipconnect.de)
17:07:57 × Alex_test quits (~al_test@178.34.161.162) (Ping timeout: 258 seconds)
17:08:21 × cpressey quits (~cpressey@host-2-102-82-207.as13285.net) (Client Quit)
17:09:29 <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)
17:12:07 → AlexZenon joins (~alzenon@94.233.241.182)
17:14:07 → Alex_test joins (~al_test@94.233.241.182)
17:17:12 → billchenchina joins (~billchenc@2a0c:b641:7a2:320:ee3e:47ca:6070:d71a)
17:17:55 → cpressey joins (~cpressey@host-89-240-119-146.as13285.net)
17:19:32 <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.)
17:20:56 → hugo- joins (znc@verdigris.lysator.liu.se)
17:26:35 × stites quits (~stites@130.44.147.204) (Ping timeout: 240 seconds)
17:27:29 → stites joins (~stites@2607:fb91:dc1:c8a5:8789:bf98:6bc7:9cd4)
17:31:24 → alexherbo2 joins (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net)
17:38:58 × hugo- quits (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds)
17:45:12 × hrberg quits (~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
17:45:36 → hrberg joins (~quassel@171.79-160-161.customer.lyse.net)
17:47:27 → Pozyomka joins (~pyon@user/pyon)
17:50:25 × eggplantade quits (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
17:52:25 → doyougnu joins (~doyougnu@45.46.170.68)
17:53:34 × Square quits (~Square@user/square) (Ping timeout: 255 seconds)
17:59:40 × stites quits (~stites@2607:fb91:dc1:c8a5:8789:bf98:6bc7:9cd4) (Read error: Connection reset by peer)
18:00:00 → stites joins (~stites@130.44.147.204)
18:01:19 × infinity0 quits (~infinity0@pwned.gg) (Remote host closed the connection)
18:03:28 → infinity0 joins (~infinity0@pwned.gg)
18:05:24 → _ht joins (~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
18:06:44 → eggplantade joins (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
18:07:23 × simendsjo quits (~user@84.211.91.241) (Ping timeout: 255 seconds)
18:08:20 → Square joins (~Square@user/square)
18:10:33 → hugo joins (znc@verdigris.lysator.liu.se)
18:13:25 → infinity0_ joins (~infinity0@pwned.gg)
18:13:25 × infinity0 quits (~infinity0@pwned.gg) (Killed (mercury.libera.chat (Nickname regained by services)))
18:13:25 infinity0_ is now known as infinity0
18:17:21 × danse-nr3 quits (~francesco@ge-19-120-4.service.infuturo.it) (Ping timeout: 260 seconds)
18:22:22 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
18:24:04 → rw joins (~rw@136.226.101.20)
18:26:24 <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?
18:27:45 <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.
18:32:54 <monochrom> Possibly no consequence except not flushing buffers of Handles.
18:34:14 × eggplantade quits (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
18:34:18 × cpressey quits (~cpressey@host-89-240-119-146.as13285.net) (Ping timeout: 245 seconds)
18:35:21 <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
18:39:39 × rw quits (~rw@136.226.101.20) (Quit: Client closed)
18:42:30 → hugo joins (znc@verdigris.lysator.liu.se)
18:44:21 → cpressey joins (~cpressey@host-89-240-119-146.as13285.net)
18:48:29 × acidjnk quits (~acidjnk@p200300d6e7072f6198c60cc392982534.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
18:50:44 → acidjnk joins (~acidjnk@p200300d6e7072f61e1adf3a14c9d7e70.dip0.t-ipconnect.de)
18:54:04 × sord937 quits (~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
18:58:05 → rw joins (~rw@136.226.101.20)
18:58:10 <rw> what happens if I never call hs_exit(), but terminate my program (say it ends or I kill it)
18:59:37 × alexherbo2 quits (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) (Remote host closed the connection)
18:59:57 → alexherbo2 joins (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net)
19:00:33 → rgw joins (~R@2605:a601:a0df:5600:7d17:3b99:a896:2e62)
19:01:27 → jabuxas joins (~jabuxas@user/jabuxas)
19:02:53 × fweht quits (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity)
19:08:00 → eggplantade joins (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555)
19:10:46 <monochrom> <monochrom> Possibly no consequence except not flushing buffers of Handles.
19:12:12 × eggplantade quits (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555) (Ping timeout: 248 seconds)
19:15:46 → danza_ joins (~francesco@151.43.118.113)
19:15:58 × cpressey quits (~cpressey@host-89-240-119-146.as13285.net) (Ping timeout: 245 seconds)
19:16:43 → lortabac joins (~lortabac@2a01:e0a:541:b8f0:fd5:bf9:bc86:68dc)
19:22:51 × lortabac quits (~lortabac@2a01:e0a:541:b8f0:fd5:bf9:bc86:68dc) (Quit: WeeChat 2.8)
19:24:39 → cpressey joins (~cpressey@host-89-240-119-146.as13285.net)
19:28:29 × acidjnk quits (~acidjnk@p200300d6e7072f61e1adf3a14c9d7e70.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
19:34:12 → acidjnk joins (~acidjnk@p200300d6e7072f6150a540857548904b.dip0.t-ipconnect.de)
19:35:19 → bilegeek joins (~bilegeek@2600:1008:b026:1a87:2ee8:e964:d4e2:13c1)
19:36:56 × ski quits (~ski@88.131.7.247) (Ping timeout: 255 seconds)
19:38:12 AlexNoo_ is now known as AlexNoo
19:42:28 × ddellacosta quits (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 255 seconds)
19:43:10 → ddellacosta joins (~ddellacos@ool-44c738de.dyn.optonline.net)
19:45:19 × danza_ quits (~francesco@151.43.118.113) (Ping timeout: 264 seconds)
19:45:26 → ubert joins (~Thunderbi@91.141.57.144.wireless.dyn.drei.com)
19:55:03 → eggplantade joins (~Eggplanta@2600:1700:38c5:d800:388b:f740:8f2c:555)
19:57:49 × takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
20:09:06 × _ht quits (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
20:12:20 × __monty__ quits (~toonn@user/toonn) (Quit: leaving)
20:19:14 → euleritian joins (~euleritia@185.238.219.28)
20:25:48 → artem joins (~artem@73.145.240.174)
20:29:11 × ulysses4ever quits (~artem@2601:249:4380:8950:8cb8:b1ce:18cd:1b77) (Ping timeout: 260 seconds)
20:31:28 → EvanR joins (~EvanR@user/evanr)
20:32:09 → pavonia joins (~user@user/siracusa)
20:32:25 × artem quits (~artem@73.145.240.174) (Ping timeout: 255 seconds)
20:36:14 → nate2 joins (~nate@c-98-45-169-16.hsd1.ca.comcast.net)
20:37:36 → Pickchea joins (~private@user/pickchea)
20:37:37 → ulysses4ever joins (~artem@73.145.240.174)
20:39:52 × bilegeek quits (~bilegeek@2600:1008:b026:1a87:2ee8:e964:d4e2:13c1) (Quit: Leaving)
20:41:32 × nate2 quits (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
20:44:02 × rw quits (~rw@136.226.101.20) (Quit: Client closed)
20:45:57 × jabuxas quits (~jabuxas@user/jabuxas) (Remote host closed the connection)
20:46:25 → jabuxas joins (~jabuxas@user/jabuxas)
20:49:34 → artem joins (~artem@c-73-103-90-145.hsd1.in.comcast.net)
20:51:46 × idgaen quits (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.5)
20:51:55 × ulysses4ever quits (~artem@73.145.240.174) (Read error: Connection reset by peer)
20:54:23 × cpressey quits (~cpressey@host-89-240-119-146.as13285.net) (Quit: Client closed)
21:00:06 → Square3 joins (~Square4@user/square)
21:03:21 → zer0bitz_ joins (~zer0bitz@user/zer0bitz)
21:03:32 × Square quits (~Square@user/square) (Ping timeout: 272 seconds)
21:05:32 × ChaiTRex quits (~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
21:06:23 × jabuxas quits (~jabuxas@user/jabuxas) (Remote host closed the connection)
21:06:46 × zer0bitz quits (~zer0bitz@user/zer0bitz) (Ping timeout: 258 seconds)
21:07:05 × stites quits (~stites@130.44.147.204) (Ping timeout: 240 seconds)
21:07:57 → stites joins (~stites@2607:fb90:ad61:8dda:f76b:db35:422d:4ab8)
21:14:46 → ChaiTRex joins (~ChaiTRex@user/chaitrex)
21:15:36 <tomsmeding> https://ircbrowse.tomsmeding.com/day/lchaskell/2023/10/02?id=1097074#trid1097074
21:21:03 → jabuxas joins (~jabuxas@user/jabuxas)
21:25:23 × michalz quits (~michalz@185.246.204.126) (Remote host closed the connection)
21:28:05 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
21:36:56 → hugo joins (znc@verdigris.lysator.liu.se)
21:41:05 × alexherbo2 quits (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) (Remote host closed the connection)
21:41:24 → alexherbo2 joins (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net)
21:44:19 × johnw quits (~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
21:44:47 → johnw joins (~johnw@69.62.242.138)
21:50:07 × chomwitt quits (~chomwitt@2a02:587:7a24:b000:1ac0:4dff:fedb:a3f1) (Ping timeout: 264 seconds)
21:51:32 → machinedgod joins (~machinedg@d198-53-218-113.abhsia.telus.net)
21:52:37 → hippoid joins (~hippoid@user/hippoid)
21:53:49 × Pickchea quits (~private@user/pickchea) (Quit: Leaving)
21:54:49 × stites quits (~stites@2607:fb90:ad61:8dda:f76b:db35:422d:4ab8) (Read error: Connection reset by peer)
21:55:09 → stites joins (~stites@130.44.147.204)
21:59:06 → Tuplanolla joins (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
21:59:08 <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
22:00:08 <c_wraith> hippoid: would it help you to eta-expand it?
22:00:16 <monochrom> Oh haha this is an abuse of do-notation to save writing "in".
22:01:03 <c_wraith> hippoid: you can change line 27 to `a x = do` and then line 34 to `x >>= traverse d`
22:01:17 <monochrom> First eliminate "do" and have instead "a = let b = ... in let c = ... in let d = ... in (>>= traverse d)"
22:01:38 <monochrom> Then yeah eta expand so it is "a x = let ... in x >>= traverse d"
22:02:29 <monochrom> What I am disappointed at is that the author didn't know that we need only one "let".
22:03:00 <geekosaur> that seems common, especially in `do`
22:03:26 <monochrom> But I guess history may show that the author knew but chose to make it easy-to-add-delete instead.
22:03:27 <haskellbridge> <j​ade> im guilty of that too :)
22:04:29 × [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 248 seconds)
22:04:55 × gatekempt quits (~gatekempt@user/gatekempt) (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:05:20 <monochrom> You can eta-expand once more to "a x = x >>= \i -> traverse d i"
22:05:25 × acidjnk quits (~acidjnk@p200300d6e7072f6150a540857548904b.dip0.t-ipconnect.de) (Ping timeout: 258 seconds)
22:06:06 → benjaminl joins (~benjaminl@user/benjaminl)
22:06:22 <monochrom> So x :: IO [PC.Ref], so i :: [PC.Ref].
22:06:25 → wroathe joins (~wroathe@50.205.197.50)
22:06:25 × wroathe quits (~wroathe@50.205.197.50) (Changing host)
22:06:25 → wroathe joins (~wroathe@user/wroathe)
22:08:15 <monochrom> Who wrote this? You don't design "IO X -> IO Y" unless you plan to call the IO X parameter multiple times. Normally you just design "X -> IO Y".
22:08:43 → [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470)
22:09:12 <hippoid> monochrom: the original is here: https://github.com/Yuras/pdf-toolbox/issues/62. the gist i sent was me altering it and doing bad things
22:09:46 × hugo quits (znc@verdigris.lysator.liu.se) (Ping timeout: 255 seconds)
22:12:40 <hippoid> monochrom: c_wraith: thanks for the eta-expand tip. I'll remember that next time I'm befuddled.
22:18:53 × alexherbo2 quits (~alexherbo@2a02-8440-3340-daca-00ad-ab5a-9bda-e15a.rev.sfr.net) (Ping timeout: 245 seconds)
22:23:51 → hugo joins (znc@verdigris.lysator.liu.se)
22:27:08 × vglfr quits (~vglfr@88.155.254.210) (Ping timeout: 272 seconds)
22:27:41 <EvanR> or unless you plan to call IO X zero times
22:27:58 <EvanR> acme don't
22:28:06 <monochrom> :)
22:28:35 <EvanR> exactly once is a waste of an opportunity to use `id'
22:30:25 × coot quits (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
22:32:19 × johnw quits (~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
22:35:59 <hippoid> so where e :: IO [T.Text] -> IO T.Text, it's better as e:: T.Text -> IO T.Text?
22:36:30 <monochrom> [Text] -> IO Text is fine.
22:38:36 <hippoid> so why is it better to get rid of that first IO?
22:39:20 <monochrom> I may only know that it is more idiomatic. I may not know that it is better.
22:39:58 <monochrom> Imagine a world in which putStrLn :: IO String -> IO String. Then you would write like putStrLn getLine. Would you like that?
22:40:13 <monochrom> Perhaps you might. It would read like C.
22:40:36 <monochrom> Err IO String -> IO ()
22:41:00 <benjaminl> isn't this what (>>=) is for?
22:41:05 <monochrom> Then hello world would also read like putStrLn (pure "hello world").
22:42:06 <hippoid> a new and pure world, hello :)
22:42:38 <c_wraith> well, it can be worth taking an IO action that you run only once if you intend to run something before and after it, like bracket does
22:43:41 <c_wraith> But if your function looks like `f x = x >>= ...` you're not really gaining any expressive power by taking an action as the first argument
22:44:02 <c_wraith> as *an* argument. Doesn't matter which one it is, I suppose.
22:44:04 <monochrom> There can be a whole body of interesting theory on programming in this style, which is like a dual to the continuation-passing style. We may call it the procedure-passing style.
22:44:27 <monochrom> But I doubt that people who actually write that way actually thought of that theory.
22:45:13 <monochrom> Instead, they wrongly believe "IO taints everything, absolutely everything" and go on to make it a self-inflicted prophecy.
22:46:19 → alexherbo2 joins (~alexherbo@2a02-8440-3340-8083-0452-5336-dc84-53ac.rev.sfr.net)
22:46:35 <EvanR> how about IO [Text] -> Text, much better
22:46:37 <mauke> > length [putStrLn "hello", putStrLn "bye"]
22:46:38 <lambdabot> 2
22:49:20 → vglfr joins (~vglfr@149.102.239.226)
22:49:44 × vglfr quits (~vglfr@149.102.239.226) (Remote host closed the connection)
22:49:57 <monochrom> "IO X -> IO Y" is a much larger space than "X -> IO Y". Often you choose the smaller space so that other people know you don't need the extra features of the larger space.
22:50:42 → vglfr joins (~vglfr@149.102.239.226)
22:50:44 <monochrom> It is the whole point many of us chose Haskell. Haskell's "A -> B" space is yet much smaller than C's "B f(A)" space.
22:51:55 <EvanR> which some detractors call bondage and discipline
22:51:56 <monochrom> or even SML's "A -> B" space.
22:52:42 → Sgeo joins (~Sgeo@user/sgeo)
22:52:45 <mauke> technically that should be "B (A)" for C
22:53:09 <monochrom> Yeah except that it would be a syntax error for C, too :)
22:53:41 <mauke> it is the correct syntax for the type "function taking an A and returning a B"
22:53:43 <monochrom> C wants at least B (*)(A)
22:55:08 <EvanR> abstract designator lets you omit the identifier
22:55:47 <mauke> gcc accepts sizeof (int (double))
22:56:04 <mauke> other compilers might reject it, but not because int (double) is a syntax error
22:56:05 <monochrom> :(
22:56:16 <monochrom> I mean, nice. :)
22:56:23 <monochrom> My faith in C is restored. >:)
22:56:37 <monochrom> But what do you use it for?
22:56:45 <mauke> pedantry
22:56:49 <monochrom> haha
22:56:52 × alexherbo2 quits (~alexherbo@2a02-8440-3340-8083-0452-5336-dc84-53ac.rev.sfr.net) (Remote host closed the connection)
22:57:11 → alexherbo2 joins (~alexherbo@2a02-8440-3340-8083-0452-5336-dc84-53ac.rev.sfr.net)
22:57:25 <monochrom> What does sizeof (int (double)) mean?
22:57:35 <mauke> 1, according to gcc
22:57:46 <monochrom> That's strange.
22:58:07 <monochrom> Although, I don't actually mind.
22:59:20 <EvanR> is that related to how empty structs have to have at least size 1 so they can be addressable
23:00:00 <mauke> void sample(int (double));
23:00:53 <mauke> that should be accepted everywhere
23:01:55 <monochrom> Is "void sample2(int f(double));" also legal?
23:02:30 <EvanR> yes the parameter's type will be adjusted to a pointer to int (double), like array parameters
23:02:36 × wroathe quits (~wroathe@user/wroathe) (Ping timeout: 272 seconds)
23:02:39 <monochrom> Ah thanks.
23:08:34 × euleritian quits (~euleritia@185.238.219.28) (Ping timeout: 255 seconds)
23:15:14 × gmg quits (~user@user/gehmehgeh) (Quit: Leaving)
23:20:08 × alexherbo2 quits (~alexherbo@2a02-8440-3340-8083-0452-5336-dc84-53ac.rev.sfr.net) (Ping timeout: 245 seconds)
23:25:41 → urparentshor joins (~Admin1@47.200.75.232)
23:31:32 × urparentshor quits (~Admin1@47.200.75.232) (Remote host closed the connection)
23:31:47 <Hecate> https://twitter.com/flora_haskell/status/1708987542886813846 Flora is becoming the meta-index it was meant to be!!
23:34:40 × vglfr quits (~vglfr@149.102.239.226) (Ping timeout: 255 seconds)
23:35:50 → vglfr joins (~vglfr@149.102.239.226)
23:42:53 → johnw joins (~johnw@69.62.242.138)
23:55:19 → bilegeek joins (~bilegeek@2600:1008:b026:1a87:2ee8:e964:d4e2:13c1)
23:55:56 → wroathe joins (~wroathe@207-153-38-140.fttp.usinternet.com)
23:55:56 × wroathe quits (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
23:55:56 → wroathe joins (~wroathe@user/wroathe)
23:57:32 × Tuplanolla quits (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)

All times are in UTC on 2023-10-02.