2024/05/21

2024-05-21 00:04:20 +0200euleritian(~euleritia@dynamic-176-006-180-037.176.6.pool.telefonica.de)
2024-05-21 00:05:23 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2024-05-21 00:06:58 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 00:11:11 +0200AlexNoo_(~AlexNoo@178.34.163.203)
2024-05-21 00:13:41 +0200AlexZenon(~alzenon@5.139.232.131) (Ping timeout: 240 seconds)
2024-05-21 00:13:43 +0200Sgeo(~Sgeo@user/sgeo)
2024-05-21 00:14:32 +0200 <nitrix> As someone returning to Haskell, what's the state of the ecosystem now? Are projects primarily Cabal or Stack?
2024-05-21 00:14:59 +0200AlexNoo(~AlexNoo@5.139.232.131) (Ping timeout: 264 seconds)
2024-05-21 00:15:29 +0200 <geekosaur> 50-50
2024-05-21 00:15:44 +0200 <geekosaur> but cabal has been increasing its "market share" of late
2024-05-21 00:16:57 +0200 <glguy> I still check that my projects build in stack but don't use it day to day
2024-05-21 00:17:19 +0200 <yin> yeah. +ghcup -stack
2024-05-21 00:17:59 +0200 <yin> maybe +ghcid depending on how long have you been away
2024-05-21 00:19:02 +0200AlexZenon(~alzenon@178.34.163.203)
2024-05-21 00:19:04 +0200 <glguy> I like ghcid during Advent of Code but is easy enough to use these days that I don't bother in general
2024-05-21 00:19:10 +0200 <glguy> but HLS is*
2024-05-21 00:20:59 +0200euleritian(~euleritia@dynamic-176-006-180-037.176.6.pool.telefonica.de) (Ping timeout: 264 seconds)
2024-05-21 00:21:53 +0200euleritian(~euleritia@dynamic-176-003-074-222.176.3.pool.telefonica.de)
2024-05-21 00:22:09 +0200 <yin> ghcid --warnings --no-status --run --clear --no-height-limit
2024-05-21 00:24:09 +0200 <yin> for advent of code this is what i do, and i test the sample inputs first
2024-05-21 00:26:23 +0200mikess(~mikess@user/mikess) (Ping timeout: 264 seconds)
2024-05-21 00:31:08 +0200Square(~Square@user/square) (Ping timeout: 260 seconds)
2024-05-21 00:34:47 +0200aryah(~aryah@141-138-38-218.dsl.iskon.hr) (Ping timeout: 264 seconds)
2024-05-21 00:35:03 +0200aryah(~aryah@141-138-45-48.dsl.iskon.hr)
2024-05-21 00:38:08 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds)
2024-05-21 00:39:33 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2024-05-21 00:40:11 +0200aryah(~aryah@141-138-45-48.dsl.iskon.hr) (Ping timeout: 264 seconds)
2024-05-21 00:41:03 +0200aryah(~aryah@141-138-38-218.dsl.iskon.hr)
2024-05-21 00:53:37 +0200troydm(~troydm@user/troydm)
2024-05-21 00:56:29 +0200euleritian(~euleritia@dynamic-176-003-074-222.176.3.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 00:56:48 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 01:03:11 +0200nadja(~dequbed@banana-new.kilobyte22.de) (Quit: bye!)
2024-05-21 01:04:23 +0200xff0x(~xff0x@2405:6580:b080:900:4704:a3e5:3fba:c1dc) (Ping timeout: 256 seconds)
2024-05-21 01:06:03 +0200xff0x(~xff0x@2405:6580:b080:900:a157:6ed1:5915:7c2c)
2024-05-21 01:07:57 +0200pdw(~user@215.156.62.185.bridgefibre.net) (Ping timeout: 272 seconds)
2024-05-21 01:09:41 +0200xff0x(~xff0x@2405:6580:b080:900:a157:6ed1:5915:7c2c) (Client Quit)
2024-05-21 01:15:26 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2024-05-21 01:15:40 +0200xff0x(~xff0x@2405:6580:b080:900:b527:98ae:f93a:e494)
2024-05-21 01:22:53 +0200nickiminjaj(~kvirc@user/laxhh) (Quit: KVIrc 5.2.2 Quasar http://www.kvirc.net/)
2024-05-21 01:29:46 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2024-05-21 01:31:20 +0200acidjnk_new(~acidjnk@p200300d6e714dc12c1768acda4802182.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2024-05-21 01:32:16 +0200Nixkernal(~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch) (Ping timeout: 260 seconds)
2024-05-21 01:53:10 +0200phma(~phma@host-67-44-208-139.hnremote.net) (Read error: Connection reset by peer)
2024-05-21 01:54:08 +0200phma(phma@2001:5b0:210f:6338:6b26:1f57:9336:4cb3)
2024-05-21 01:54:41 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 02:28:57 +0200ystael(~ystael@user/ystael) (Ping timeout: 268 seconds)
2024-05-21 02:34:25 +0200it_(~quassel@v2202212189510211193.supersrv.de) (Quit: ,o>)
2024-05-21 02:34:50 +0200it_(~quassel@v2202212189510211193.supersrv.de)
2024-05-21 02:35:17 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2024-05-21 02:35:35 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-21 02:49:44 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-05-21 02:50:59 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-21 02:57:05 +0200hsw(~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net)
2024-05-21 03:05:08 +0200xdminsy(~xdminsy@117.147.70.240) (Ping timeout: 260 seconds)
2024-05-21 03:06:10 +0200xdminsy(~xdminsy@117.147.70.240)
2024-05-21 03:11:48 +0200sayola(~sayola@ip-109-42-242-108.web.vodafone.de)
2024-05-21 03:13:41 +0200sayola1(~sayola@ip-109-42-241-204.web.vodafone.de) (Ping timeout: 240 seconds)
2024-05-21 03:15:16 +0200xdminsy(~xdminsy@117.147.70.240) (Read error: Connection reset by peer)
2024-05-21 03:16:04 +0200xdminsy(~xdminsy@117.147.70.240)
2024-05-21 03:20:39 +0200xdminsy(~xdminsy@117.147.70.240) (Read error: Connection reset by peer)
2024-05-21 03:21:46 +0200xdminsy(~xdminsy@117.147.70.240)
2024-05-21 03:26:51 +0200xff0x(~xff0x@2405:6580:b080:900:b527:98ae:f93a:e494) (Ping timeout: 255 seconds)
2024-05-21 03:28:40 +0200xdminsy(~xdminsy@117.147.70.240) (Read error: Connection reset by peer)
2024-05-21 03:29:01 +0200xdminsy(~xdminsy@117.147.70.240)
2024-05-21 04:00:01 +0200fliife(~fliife@user/fliife) (Quit: ZNC 1.8.2+deb2build5 - https://znc.in)
2024-05-21 04:00:48 +0200fliife(~fliife@user/fliife)
2024-05-21 04:00:53 +0200otto_s(~user@p5de2fafb.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2024-05-21 04:02:56 +0200otto_s(~user@p5de2f060.dip0.t-ipconnect.de)
2024-05-21 04:05:59 +0200td_(~td@i53870921.versanet.de) (Ping timeout: 264 seconds)
2024-05-21 04:07:44 +0200td_(~td@i5387090E.versanet.de)
2024-05-21 04:14:05 +0200agent314(~quassel@184.75.215.3) (Ping timeout: 240 seconds)
2024-05-21 04:14:11 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2024-05-21 04:15:07 +0200agent314(~quassel@104.129.57.116)
2024-05-21 04:15:35 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds)
2024-05-21 04:40:45 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-21 04:41:23 +0200justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2024-05-21 04:41:37 +0200justsomeguy(~justsomeg@user/justsomeguy)
2024-05-21 04:44:59 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 252 seconds)
2024-05-21 04:50:46 +0200joeyadams(~joeyadams@2603:6010:5100:2ed:64b6:9e88:7ce7:a120)
2024-05-21 05:06:52 +0200Midjak(~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep)
2024-05-21 05:11:23 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-21 05:17:17 +0200yin(~yin@user/zero) (Ping timeout: 240 seconds)
2024-05-21 05:28:11 +0200aforemny_(~aforemny@i59F516F9.versanet.de) (Ping timeout: 264 seconds)
2024-05-21 05:28:38 +0200aforemny(~aforemny@2001:9e8:6cca:4800:37b5:fb76:9e3f:6a26)
2024-05-21 05:42:48 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 05:49:24 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-05-21 05:52:55 +0200justsomeguy(~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6)
2024-05-21 05:56:02 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-21 06:00:35 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-21 06:26:23 +0200agent314(~quassel@104.129.57.116) (Ping timeout: 264 seconds)
2024-05-21 06:26:36 +0200agent314(~quassel@162.219.176.19)
2024-05-21 06:34:50 +0200michalz(~michalz@185.246.207.203)
2024-05-21 06:35:05 +0200michalz(~michalz@185.246.207.203) (Client Quit)
2024-05-21 06:37:54 +0200michalz(~michalz@185.246.207.221)
2024-05-21 06:46:50 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 07:17:01 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2024-05-21 07:18:08 +0200zetef(~quassel@5.2.182.99)
2024-05-21 07:20:52 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds)
2024-05-21 07:27:43 +0200y04nn(~username@2a03:1b20:8:f011::e10d)
2024-05-21 07:30:07 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2024-05-21 07:30:42 +0200vladl(~vladl@24.35.90.183)
2024-05-21 07:37:18 +0200johnw_(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2024-05-21 07:38:50 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 07:40:59 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-21 07:41:29 +0200 <vladl> What patterns are present in a recursion scheme that requires synchronization? For example, recursively interpolating subpixels in an image, where the interpolation step requires the parent pixel neighborhood? The subpixels get folded back into the original resolution, so this is almost a hylomorphism, except the coalgebra gets "split" over the synchronization step. This seems like a common pattern but I
2024-05-21 07:41:35 +0200 <vladl> can't really find much on it, which could definitely be a skill issue. I read "Fantastic Morphisms and where to find them" but none of these really fit the bill. There's a problem on tree nexuses in Richard Bird's Pearls of Functional Algorithm design that I went through that, again, seemed very close to what I wanted but I couldn't make the pieces fit.
2024-05-21 07:45:55 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 268 seconds)
2024-05-21 07:50:40 +0200 <probie> I don't quite understand what you mean by "synchronization" here
2024-05-21 07:53:11 +0200geekosauris thinking this sounds more like a comonad
2024-05-21 07:53:39 +0200 <vladl> At a given resolution j, before interpolating the subpixels at resolution j+1, the neighboring (sub)pixels at resolution j have to have been computed. So we need to sync layer-by-layer. Synchronization like a fence or a barrier.
2024-05-21 07:54:55 +0200johnw(~johnw@69.62.242.138)
2024-05-21 07:57:35 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2024-05-21 07:57:40 +0200 <vladl> Yes I think I see a comonad in there too, but its also split. Like, lets suppose a 1D array of pixels p with neighborhoods w, so something like [w p]. We have a (w p -> p), but in order to extend and get a (w p) out, we have to step all the way out of the [] in order to propagate neighbor values. So we can go [p] -> [w p], but that [] prevents me from making it a proper comonad.
2024-05-21 07:58:13 +0200 <probie> I don't see what requires you to synchronize layer-by-layer. A subpixel merely requires its neighbours at the previous resolution to have been computed, not the entire previous layer
2024-05-21 07:59:11 +0200 <vladl> That's true but I'm relaxing my focus to the layer scale in hopes of making it easier for me to reason about
2024-05-21 08:00:39 +0200 <vladl> Also because my particular use case ultimately does need to synchonize layer-by-layer for other reasons (memory allocation strategy) so I may as well
2024-05-21 08:01:56 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 08:10:56 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net)
2024-05-21 08:13:25 +0200internatetional(~nate@182.2.51.214)
2024-05-21 08:13:53 +0200internatetional(~nate@182.2.51.214) (Max SendQ exceeded)
2024-05-21 08:14:11 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 08:15:35 +0200demon-cat(~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-21 08:18:56 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2024-05-21 08:20:24 +0200 <vladl> Actually, scratch that - we don't have a (w p -> p), we have a (w p -> f p), where f is the coalgebra functor (what contains the subpixels). So the comonad situation is even messier.
2024-05-21 08:21:35 +0200 <vladl> Its like... taking an anamorphism and a comonad and trying to thread them through one another somehow.
2024-05-21 08:21:38 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 08:22:50 +0200 <vladl> Or, hopefully, I am just overcomplicating things and there is some more elegant formalism for this out there
2024-05-21 08:34:48 +0200skiisn't too clear on the concrete example with subpixel interpolation
2024-05-21 08:36:01 +0200 <ski> you're building a quadtree of the pixels, or something ?
2024-05-21 08:37:09 +0200 <vladl> You guessed right. If it matters, the pixels are actually fluid density distributions and the interpolation is meant to refine the grid cells until they're fine enough for the fluid to advect across in one time step.
2024-05-21 08:37:39 +0200 <ski> hm, or maybe considering a rectangle of pixels, and then a rectangle of all windows around each pixel, and then a rectangle of all windows around those, &c. (so this is a DAG, not a tree) ?
2024-05-21 08:38:49 +0200 <vladl> Well it is a tree in the sense that every parent cell is exactly decomposed into its child cells, like they overlap. But in terms of data dependencies, it is a DAG.
2024-05-21 08:38:50 +0200 <ski> (windows of a particular fixed size, in terms of the elements of the layer below, say)
2024-05-21 08:39:32 +0200skidoesn't know the term "advect"
2024-05-21 08:40:06 +0200 <vladl> It just means the movement of materials. So basically it is the fluid traversing space.
2024-05-21 08:40:09 +0200 <ski> does two adjacent parent cells share child cells ?
2024-05-21 08:40:59 +0200 <vladl> No, no child cells are shared. So imagine each pixel gets broken up into 4 child pixels, but the values of the child pixels gets interpolated from the parent pixels and its adjacent neighbors (for a first-order interpolation scheme)
2024-05-21 08:41:58 +0200 <vladl> Er, cells, sorry, I should stop mixing terminology
2024-05-21 08:42:05 +0200 <ski> hm, interpolated from parent cell, and parentsibling cells ? or also from cousin cells ?
2024-05-21 08:42:21 +0200sayola1(~sayola@ip-109-42-241-195.web.vodafone.de)
2024-05-21 08:42:34 +0200 <vladl> Only from parent sibling cells. So a cell at resolution j only depends on cell values at resolutoin j-1
2024-05-21 08:43:28 +0200sayola(~sayola@ip-109-42-242-108.web.vodafone.de) (Ping timeout: 260 seconds)
2024-05-21 08:43:41 +0200 <ski> mhm
2024-05-21 08:44:00 +0200 <ski> so how does information flow ? only from root towards leaves ?
2024-05-21 08:44:07 +0200 <ski> hmm
2024-05-21 08:44:08 +0200sayola1(~sayola@ip-109-42-241-195.web.vodafone.de) (Read error: Connection reset by peer)
2024-05-21 08:44:29 +0200 <ski> well, to sibling children as well, yea
2024-05-21 08:44:50 +0200 <vladl> Both ways, but not at the same time. We unfold all the way, then do some transformations, and then fold it back up to the original resolution.
2024-05-21 08:45:49 +0200 <ski> mhm, so first stage is basically from root toward leaves (but including from siblings to children). and then later from leaves to root again ?
2024-05-21 08:46:36 +0200 <vladl> so a 1D example, say you have [x0, x1, x2, x3, x4...] and you want to expand x2 into [y0, y1], then y0 = f 0 [x1, x2, x3] and y1 = f 1 [x1, x2, x3] for some interpolation function f
2024-05-21 08:46:40 +0200 <vladl> yes
2024-05-21 08:46:51 +0200sayola(~sayola@ip-109-42-241-195.web.vodafone.de)
2024-05-21 08:48:51 +0200 <ski> hm, i see
2024-05-21 08:49:03 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-05-21 08:49:25 +0200 <ski> (or `[y0,y1] = g [x1,x2,x3]')
2024-05-21 08:49:38 +0200 <vladl> yes, that's more accurate
2024-05-21 08:50:06 +0200 <ski> so this would be `w p -> f p'
2024-05-21 08:50:16 +0200 <vladl> yes, exactly
2024-05-21 08:53:07 +0200acidjnk_new(~acidjnk@p200300d6e714dc192d105e993ca958d7.dip0.t-ipconnect.de)
2024-05-21 08:53:21 +0200 <ski> still not following what you mean by the synchronization
2024-05-21 08:55:09 +0200 <vladl> so, suppose we have [[y0, y1], [y2, y3], ...] from the expansion and we flattened it down to [y0, y1, y2, y3,...]. So we want to expand y1 into [z0,z1] but we need [y0, y1, y2] to do this. but x2 only computes y0 and y1, so we need x3 to have been expanded into y2 and y3 before we can compute z0,z1
2024-05-21 08:56:25 +0200 <vladl> so z's have to wait until all of the y's in their interpolation domain are done
2024-05-21 08:57:09 +0200 <vladl> which means x2 and x3 have to both finish their expansions before either y1 or y2 can be expanded
2024-05-21 08:58:24 +0200 <ski> "but x2 only computes y0 and y1, so we need x3" -- hm, shouldn't `x2' and `x3' be `x0' and `x1' ?
2024-05-21 08:59:05 +0200 <ski> (hm, or maybe you don't have cropped windows/neighbourhoods at the edges. that would make it `x1' and `x2' though, i think)
2024-05-21 08:59:36 +0200 <vladl> we don't expand x0, because it doesn't have a complete interpolation domain
2024-05-21 08:59:58 +0200 <ski> mm, right
2024-05-21 09:03:54 +0200 <vladl> And then i just try to simplify it for myself and consider dependencies at the scale of an entire layer at a time, instead of worrying about the implicit DAG in the window-wise dependencies
2024-05-21 09:04:48 +0200 <ski> hmm .. so i guess you only need siblings,cousins,&c. ("same generation") up to a common ancestor `n' levels up, where `n' would depend on the width of `w' and the branching factor of `f'
2024-05-21 09:05:29 +0200 <ski> (only thinking of fairly "regular" `w' and `f' here (e.g. probably linear), rather than say more arbitrary ones)
2024-05-21 09:05:35 +0200cfricke(~cfricke@user/cfricke)
2024-05-21 09:06:07 +0200 <ski> at least, for your example above, `n' would seem to be `2'
2024-05-21 09:06:08 +0200 <vladl> yes, but note the common ancestor could be pretty far up, if the cell's position is near a power-of-two.
2024-05-21 09:06:18 +0200 <ski> hmm
2024-05-21 09:06:30 +0200 <ski> oh right. i was misthinking here
2024-05-21 09:08:02 +0200 <ski> the flattening, to generate `w', is complicating stuff
2024-05-21 09:09:09 +0200 <ski> "consider dependencies at the scale of an entire layer at a time" -- i suppose you mean generating a layer completely, before increasing the resolution. is this what you meant by "synchronization" ?
2024-05-21 09:09:32 +0200 <vladl> yes. the flattening complicates things significantly, and yes that is what i mean by synchronization
2024-05-21 09:13:58 +0200 <ski> given `t p', you can get to `t (w p)', and then to `t (f p)'. then that becomes `t p' with one level deeper
2024-05-21 09:16:09 +0200 <vladl> yes. t needs to be able to absorb f (and remember it so it can form it later) so it seems like a tree with layer-wise views
2024-05-21 09:19:35 +0200 <ski> i guess, something like `data TreeD f :: Nat -> * -> * where Leaf :: TreeD f Zero p; Branch :: f (TreeD f n p) -> TreeD f (Succ n) p' or `data TreeB f p = Conquer p | Divide (TreeB f (f p))'
2024-05-21 09:20:22 +0200 <ski> (where `TreeB f p' amounts to `exists n :: Nat. TreeD f n p')
2024-05-21 09:20:58 +0200 <ski> the interesting part, of course, is how to do the `t p -> t (w p)' part
2024-05-21 09:24:52 +0200 <vladl> Yeah, something like that
2024-05-21 09:25:41 +0200 <ski> .. i'm wondering if you could carry siblings with you, as you go down, so that you don't have to traverse arbitarily high up again to retrieve them
2024-05-21 09:26:24 +0200 <vladl> So the way I do it in my specific case, is that, during the unfolding, each cell carries with it an object called a "topology" that you can basically think of as a list of pointers to the neighbors
2024-05-21 09:26:49 +0200 <vladl> So when a cell gets expanded, it actually computes this right away, so it knows from the moment of birth where its neighbors are, so to speak
2024-05-21 09:27:14 +0200 <ski> hm, so instead of `t p >-> t (w p) >-> t (f p)', could one do `t (w p) >-> t (w (f p)) >-> t (f (w p))' ?
2024-05-21 09:28:09 +0200 <vladl> i don't think so, because the new cell only knows where its neighbors are, not what their values are
2024-05-21 09:29:22 +0200 <ski> mhm
2024-05-21 09:30:52 +0200 <vladl> so in my case, in a sense i have to pair the topology with the entire parent layer (since the offsets are with respect to the layer) in order to compute the child cells
2024-05-21 09:31:50 +0200chele(~chele@user/chele)
2024-05-21 09:32:31 +0200ubert(~Thunderbi@p200300ecdf1a44e6bddfe2bf28cca96e.dip0.t-ipconnect.de)
2024-05-21 09:33:10 +0200 <vladl> that's another reason I go layer-by-layer, I can access neighbors in O(1) and I only have to store 2 layers at a time
2024-05-21 09:33:21 +0200 <vladl> instead of O(log n) and storing the entire tree
2024-05-21 09:34:13 +0200 <ski> yup, just like dynamic programming with fixed memory/history
2024-05-21 09:34:53 +0200kuribas(~user@ptr-17d51encis8jg2ccf48.18120a2.ip6.access.telenet.be)
2024-05-21 09:36:00 +0200 <vladl> yeah, and I was considering the dynamorphism as a model but its that lateral dependency that trips me up.
2024-05-21 09:36:59 +0200 <ski> (hm, this all is making me think of "structure syntax" now .. although that's tangential to what you're pondering)
2024-05-21 09:38:39 +0200 <vladl> you mean like how ListF a b is a functor over its recursive structure, that kind of thing?
2024-05-21 09:39:54 +0200 <ski> well .. it's an idea i've been pondeing, on and off. basically, given a structure/collection with elements, i want to name the structure (the layer(s)) itself, separately from the elements
2024-05-21 09:41:39 +0200ubert(~Thunderbi@p200300ecdf1a44e6bddfe2bf28cca96e.dip0.t-ipconnect.de) (Quit: ubert)
2024-05-21 09:42:45 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 09:42:49 +0200 <ski> e.g. with `concat :: [[a]] -> [a]' and `sum :: [Integer] -> Integer' we have a law `sum . map sum = sum . concat'. i was to express this as `sum (| l0 ; sum (| l1 ; n |) |) = sum (| concat (| l0,l1 |) ; n |)'. here `l0' is the name of the outer list structure, and `l1' is the name of each inner list structure (it's plural), and `n' is the name of each element (it's doubly plural)
2024-05-21 09:43:06 +0200 <ski> s/i was to/i want to/
2024-05-21 09:48:51 +0200 <vladl> i think i'm following. i read `sum(| a ; b |)` as sum of b's ranging over a, so this expression shows how different views of the structure relate to one another, which tells you about the structure as a whole
2024-05-21 09:49:30 +0200 <vladl> s/expression/equation
2024-05-21 09:51:37 +0200 <vladl> i'm guessing you might be able to derive equivalent-but-different traversals if you had some syntax like that?
2024-05-21 09:51:58 +0200 <ski> (and then i want to be able to say things like `[] -> Maybe', which would be a right kan extension. `([] -> Maybe) a' amounting to `forall b. (a -> [b]) -> Maybe b'. and `(exists n. t n) a', i think (?), amounting to `exists n. t n a' (and similarly for `forall'))
2024-05-21 09:52:49 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 09:53:11 +0200 <ski> `sum (| a ; b |)' sums all the `b's inside the `a' structure. `concat (| l0,l1 |)' concatenates ("flattens") the `l0' and `l1' structures (the latter being contained inside the former). note that there are no elements mentioned here (hence no `;', just `,')
2024-05-21 09:54:12 +0200 <vladl> we don't think of l1 as elements of l0?
2024-05-21 09:54:25 +0200 <ski> basically, it's an attempt to make a calculus where you can name individual structures, or layers, *without* including the contents/elements in that name. *separating* structure from contents
2024-05-21 09:54:44 +0200 <ski> concat :: [] . [] -> []
2024-05-21 09:55:07 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 09:55:13 +0200 <ski> this is why it is `concat (| l0,l1 |)', the `.' (composition) means that you call `concat' with two layers (`l0' and `l1' here)
2024-05-21 09:55:24 +0200 <ski> (and the result is also a list layer)
2024-05-21 09:56:15 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net)
2024-05-21 09:56:16 +0200 <ski> so, polymorphic operations don't need to mention the elements of the type parameters. but `sum' involves both the structure and the elements, so it still needs to mention both
2024-05-21 09:56:55 +0200 <vladl> i see now
2024-05-21 09:57:32 +0200 <ski> (`sum' is like a monoid action, `[]' acting on `Integer'. the law involving `concat' and `sum' above is similar to e.g. `(x * y) * v = x * (y * v)' law for scalars `x',`y' and vector `v')
2024-05-21 10:00:13 +0200 <ski> part of the point here is to avoid having to spell out annoying `fmap's, to manipulate the correct layer of a structure
2024-05-21 10:01:49 +0200 <ski> like, which is more readable, `join . fmap join = join . join', or `join (| m0,join (| m1,m2 |) |) = join (| join (| m0,m1 |),m2 |)' ?
2024-05-21 10:02:49 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 10:02:57 +0200 <ski> i should also say that this isn't just meant for expressing laws, but also for defining things. it's just that i'm drawing inspiration from some laws
2024-05-21 10:05:55 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 10:07:17 +0200son0p(~ff@186.121.14.247) (Ping timeout: 240 seconds)
2024-05-21 10:08:02 +0200Square2(~Square4@user/square)
2024-05-21 10:08:22 +0200 <vladl> so instead of using fmap which says "just give me the function, i know how to map it over me" the structure syntax shows explicitly where the function gets applied, in terms of the part-to-whole relationship (the nature of which is abstracted over by the syntax) of the structure and its substructures?
2024-05-21 10:08:24 +0200danse-nr3(~danse-nr3@151.35.171.208) (Ping timeout: 260 seconds)
2024-05-21 10:08:34 +0200gmg(~user@user/gehmehgeh)
2024-05-21 10:08:59 +0200y04nn(~username@2a03:1b20:8:f011::e10d) (Ping timeout: 268 seconds)
2024-05-21 10:09:19 +0200Nixkernal(~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch)
2024-05-21 10:10:04 +0200 <vladl> so you end up defining the law by naming the substructures in the operations, without reference to the elements if they're not relevant to the calculation
2024-05-21 10:11:12 +0200 <ski> yea .. it's basically a pointful syntax, but for function kinds (so having expressions `e', where `e :: f', where `f :: * -> *', say), rather than for concrete kinds (plain expressions `e' where `e :: t' and `t :: *')
2024-05-21 10:11:51 +0200 <ski> (well, preferably it'd work for `f :: k0 -> k1' ..)
2024-05-21 10:12:12 +0200 <ski> yes
2024-05-21 10:12:26 +0200 <ski> or defining the operation
2024-05-21 10:16:27 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 10:17:35 +0200__monty__(~toonn@user/toonn)
2024-05-21 10:22:22 +0200 <ski> something like
2024-05-21 10:22:29 +0200 <ski> data List :: * -> *
2024-05-21 10:22:39 +0200 <ski> where
2024-05-21 10:22:58 +0200 <ski> Nil :: ( ) -> List
2024-05-21 10:23:17 +0200 <ski> Cons :: (Identity,List) -> List
2024-05-21 10:23:28 +0200 <ski> and then you can do
2024-05-21 10:23:45 +0200 <ski> append :: (List,List) -> List
2024-05-21 10:24:02 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 10:24:33 +0200 <ski> append (Nil ( ),l1) = l1
2024-05-21 10:24:52 +0200 <ski> append (Cons ((||),l0),l1) = Cons ((||),append (l0,l1))
2024-05-21 10:24:54 +0200 <ski> and
2024-05-21 10:25:00 +0200tzh(~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz)
2024-05-21 10:25:08 +0200 <ski> concat :: List . List -> List
2024-05-21 10:26:03 +0200 <ski> concat (| Nil ( ),l1 |) = Nil ( )
2024-05-21 10:26:22 +0200 <ski> concat (| Cons ((||),l0),l1 |) = append (l1,concat (| l0,l1 |))
2024-05-21 10:27:32 +0200 <ski> (note that `f . g -> h' here curries as `f -> g -> h' (and `Identity -> h' as `h'). `(f,g) -> h' does not curry (and nor does `() -> h'))
2024-05-21 10:28:29 +0200 <ski> the `(||)' in the `Cons' case of `append' basically indicates the place of the element (the "hole", since elements are not explicitly mentioned in these operations)
2024-05-21 10:28:57 +0200danse-nr3(~danse-nr3@151.35.171.208) (Ping timeout: 255 seconds)
2024-05-21 10:29:48 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 10:30:34 +0200 <ski> note that, in the `Cons' case of `concat', because `l1' is plural, in the first argument of `append' (whose domain is a (lifted) product, not a composition), `l1' refers to the first list (which is pointed out by the `(||)', in the pattern). wihle in the second argument of `append', `l1' refers to all the other lists, living under the `l0' list structure
2024-05-21 10:32:46 +0200 <vladl> ah yes that makes sense now
2024-05-21 10:33:04 +0200ft(~ft@p508db8fc.dip0.t-ipconnect.de) (Quit: leaving)
2024-05-21 10:33:23 +0200 <ski> .. it's a bit weird and unusual to think in these terms
2024-05-21 10:33:26 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 10:34:22 +0200 <ski> and i'm not too sure how more generally useful it would be .. but it seems like an interesting idea to explore, regardless, to see how far one can push it, how much it can make sense, and perhaps how much can be incorporated in such a system
2024-05-21 10:36:59 +0200 <ski> the type system for this requires keeping track of an *ordered* context/environment of variable typings ..
2024-05-21 10:37:59 +0200 <ski> .. which i guess is another reason i've semi-recently been interested in grokking ordered logic (also for its own sake, e.g. for use as a logic programming language, or a logical framework)
2024-05-21 10:42:30 +0200sord937(~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
2024-05-21 10:43:13 +0200sord937(~sord937@gateway/tor-sasl/sord937)
2024-05-21 10:46:06 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds)
2024-05-21 10:47:04 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:6584:33d2:35a2:fd74)
2024-05-21 10:48:06 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2024-05-21 10:49:59 +0200lxsameer(~lxsameer@Serene/lxsameer)
2024-05-21 10:54:08 +0200danse-nr3(~danse-nr3@151.35.171.208) (Ping timeout: 260 seconds)
2024-05-21 10:57:59 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 11:04:07 +0200 <tomsmeding> why is Ord a superclass of Real?
2024-05-21 11:04:45 +0200 <ncf> the reals are ordered aren't they
2024-05-21 11:05:02 +0200 <tomsmeding> you have a point
2024-05-21 11:05:04 +0200 <ncf> well i guess not decidably so
2024-05-21 11:05:20 +0200danse-nr3(~danse-nr3@151.35.171.208) (Ping timeout: 260 seconds)
2024-05-21 11:05:32 +0200 <tomsmeding> I guess my actual X question is: why are all the numeric classes specifically for single scalars
2024-05-21 11:05:41 +0200 <tomsmeding> there's no sensible way to make arrays an instance of the numeric hierarchy
2024-05-21 11:06:11 +0200 <tomsmeding> if you squint on fromInteger you can maybe make Num work, but that's as far as you get
2024-05-21 11:06:14 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 11:07:46 +0200 <ski> it's a mess
2024-05-21 11:21:29 +0200 <mauke> the numeric classes lift straightforwardly into Applicative
2024-05-21 11:21:38 +0200 <mauke> so [a] works fine :-)
2024-05-21 11:22:29 +0200Flow(~none@gentoo/developer/flow) (Ping timeout: 240 seconds)
2024-05-21 11:22:38 +0200 <int-e> > liftA2 (+) [1,2] [10,20]
2024-05-21 11:22:39 +0200 <lambdabot> [11,21,12,22]
2024-05-21 11:22:51 +0200 <int-e> is that what you want though :)
2024-05-21 11:24:27 +0200 <mauke> WYGIWYG
2024-05-21 11:24:45 +0200 <int-e> I'll give you that it is /a/ (non-commutative) ring.
2024-05-21 11:27:53 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 11:30:12 +0200 <tomsmeding> the numeric classes lift straightforwardly into applicative?
2024-05-21 11:30:22 +0200 <tomsmeding> > liftA toInteger [1,2]
2024-05-21 11:30:24 +0200 <lambdabot> [1,2]
2024-05-21 11:30:42 +0200 <tomsmeding> okay that typechecks as-is but it's not a valid definition of toInteger :p
2024-05-21 11:31:00 +0200 <tomsmeding> goes wrong at Num(fromInteger) already
2024-05-21 11:31:25 +0200 <tomsmeding> and everything breaks down once you get to Real, RealFrac and RealFloat
2024-05-21 11:31:47 +0200 <tomsmeding> (decldeFloat :: a -> (Integer, Int) ?)
2024-05-21 11:31:53 +0200 <ski> fromInteger = pure . fromInteger
2024-05-21 11:31:53 +0200 <tomsmeding> *decodeFloat
2024-05-21 11:32:25 +0200 <tomsmeding> ski: okay I concede that one, but what about toInteger :p
2024-05-21 11:32:50 +0200 <tomsmeding> though that's a very questionable definition for fromInteger on arrays
2024-05-21 11:34:10 +0200 <ski> replication is sensible for pointwise operations
2024-05-21 11:34:31 +0200 <tomsmeding> it is
2024-05-21 11:34:34 +0200 <tomsmeding> those are the easy ones
2024-05-21 11:34:43 +0200noumenon(~noumenon@113.51-175-156.customer.lyse.net)
2024-05-21 11:38:16 +0200Flow(~none@gentoo/developer/flow)
2024-05-21 11:42:43 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 11:57:06 +0200danse-nr3(~danse-nr3@151.35.171.208) (Remote host closed the connection)
2024-05-21 11:57:26 +0200rvalue(~rvalue@user/rvalue) (Read error: Connection reset by peer)
2024-05-21 11:57:58 +0200rvalue(~rvalue@user/rvalue)
2024-05-21 11:58:26 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 12:00:49 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 12:01:19 +0200danse-nr3(~danse-nr3@151.35.171.208) (Read error: Connection reset by peer)
2024-05-21 12:02:59 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2024-05-21 12:03:26 +0200sawilagar(~sawilagar@user/sawilagar)
2024-05-21 12:03:43 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de)
2024-05-21 12:04:13 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 12:04:38 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 12:04:51 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 12:05:21 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2024-05-21 12:09:23 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds)
2024-05-21 12:11:03 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-21 12:11:37 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 12:12:38 +0200danse-nr3(~danse-nr3@151.35.171.208)
2024-05-21 12:23:16 +0200aryah(~aryah@141-138-38-218.dsl.iskon.hr) (Read error: Connection reset by peer)
2024-05-21 12:25:03 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 255 seconds)
2024-05-21 12:28:27 +0200son0p(~ff@181.32.157.144)
2024-05-21 12:39:55 +0200joeyadams(~joeyadams@2603:6010:5100:2ed:64b6:9e88:7ce7:a120) (Quit: Leaving)
2024-05-21 12:40:36 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:6584:33d2:35a2:fd74) (Remote host closed the connection)
2024-05-21 12:40:49 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:f77c:428b:229c:4616)
2024-05-21 12:47:47 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 12:53:59 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2024-05-21 12:54:24 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de)
2024-05-21 12:54:33 +0200yin(~yin@user/zero)
2024-05-21 12:56:53 +0200danse-nr3(~danse-nr3@151.35.171.208) (Ping timeout: 240 seconds)
2024-05-21 13:01:58 +0200cfricke(~cfricke@user/cfricke) (Ping timeout: 255 seconds)
2024-05-21 13:04:06 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 13:07:42 +0200noumenon(~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer)
2024-05-21 13:08:17 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2024-05-21 13:13:42 +0200xff0x(~xff0x@2405:6580:b080:900:6e2f:a302:dfa:99b5)
2024-05-21 13:16:18 +0200CiaoSen(~Jura@2a05:5800:2b2:8e00:e6b9:7aff:fe80:3d03)
2024-05-21 13:19:29 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 13:19:56 +0200cfricke(~cfricke@user/cfricke)
2024-05-21 13:20:34 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 13:27:29 +0200joeyadams(~joeyadams@2603:6010:5100:2ed:eb4a:233c:d82d:5868)
2024-05-21 13:29:49 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-21 13:30:55 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 13:35:57 +0200Lycurgus(~georg@user/Lycurgus)
2024-05-21 13:42:49 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 13:43:17 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de)
2024-05-21 13:46:33 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 13:49:45 +0200jcarpenter2(~lol@2603:3016:1e01:b940:892b:2549:5c20:9c9b) (Ping timeout: 268 seconds)
2024-05-21 13:55:40 +0200cfricke(~cfricke@user/cfricke) (Ping timeout: 256 seconds)
2024-05-21 13:56:27 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2)
2024-05-21 13:57:10 +0200joeyadams(~joeyadams@2603:6010:5100:2ed:eb4a:233c:d82d:5868) (Quit: Leaving)
2024-05-21 13:57:49 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in)
2024-05-21 13:58:15 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 14:00:26 +0200p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1)
2024-05-21 14:02:59 +0200yin(~yin@user/zero) (Ping timeout: 264 seconds)
2024-05-21 14:04:08 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 14:08:55 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 14:09:12 +0200euleritian(~euleritia@77.22.252.56)
2024-05-21 14:09:32 +0200yin(~yin@user/zero)
2024-05-21 14:13:48 +0200euleritian(~euleritia@77.22.252.56) (Ping timeout: 268 seconds)
2024-05-21 14:14:02 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de)
2024-05-21 14:22:56 +0200cfricke(~cfricke@user/cfricke)
2024-05-21 14:23:12 +0200euleritian(~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Ping timeout: 260 seconds)
2024-05-21 14:24:29 +0200euleritian(~euleritia@dynamic-176-001-018-229.176.1.pool.telefonica.de)
2024-05-21 14:28:43 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 14:35:48 +0200haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in)
2024-05-21 14:39:32 +0200cfricke(~cfricke@user/cfricke) (Ping timeout: 260 seconds)
2024-05-21 14:41:33 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1)
2024-05-21 14:51:00 +0200haritz(~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220)
2024-05-21 14:51:00 +0200haritz(~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host)
2024-05-21 14:51:00 +0200haritz(~hrtz@user/haritz)
2024-05-21 14:52:33 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 14:54:14 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2024-05-21 14:55:53 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-21 15:08:20 +0200cfricke(~cfricke@user/cfricke)
2024-05-21 15:22:22 +0200ystael(~ystael@user/ystael)
2024-05-21 15:33:05 +0200acidjnk_new(~acidjnk@p200300d6e714dc192d105e993ca958d7.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2024-05-21 15:34:34 +0200weechatdminuoso
2024-05-21 15:34:51 +0200Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 260 seconds)
2024-05-21 15:35:31 +0200Maxdamantus(~Maxdamant@user/maxdamantus)
2024-05-21 15:36:35 +0200euleritian(~euleritia@dynamic-176-001-018-229.176.1.pool.telefonica.de) (Ping timeout: 264 seconds)
2024-05-21 15:37:03 +0200euleritian(~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de)
2024-05-21 15:43:08 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-21 15:56:29 +0200zetef(~quassel@5.2.182.99) (Remote host closed the connection)
2024-05-21 16:01:19 +0200haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in)
2024-05-21 16:01:50 +0200haritz(~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk)
2024-05-21 16:03:40 +0200haritz(~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host)
2024-05-21 16:03:40 +0200haritz(~hrtz@user/haritz)
2024-05-21 16:04:15 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Quit: Lost terminal)
2024-05-21 16:13:00 +0200cfricke(~cfricke@user/cfricke) (Quit: WeeChat 4.2.2)
2024-05-21 16:14:29 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds)
2024-05-21 16:21:39 +0200danse-nr3(~danse-nr3@151.35.136.250)
2024-05-21 16:27:34 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker) (Quit: So long and thanks for all the fish)
2024-05-21 16:27:55 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2024-05-21 16:30:12 +0200haritz(~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
2024-05-21 16:32:38 +0200haritz(~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737)
2024-05-21 16:32:41 +0200haritz(~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) (Changing host)
2024-05-21 16:32:41 +0200haritz(~hrtz@user/haritz)
2024-05-21 16:34:24 +0200bontaq(~user@ool-45779c03.dyn.optonline.net)
2024-05-21 16:42:37 +0200sayola(~sayola@ip-109-42-241-195.web.vodafone.de) (Read error: Connection reset by peer)
2024-05-21 16:42:45 +0200sayola(~sayola@ip-109-42-243-149.web.vodafone.de)
2024-05-21 16:50:52 +0200aryah(~aryah@141-138-38-218.dsl.iskon.hr)
2024-05-21 16:53:47 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 16:58:47 +0200agent314(~quassel@162.219.176.19) (Ping timeout: 264 seconds)
2024-05-21 17:09:07 +0200d34df00d(~d34df00d@2600:1702:4f1b:7c10::43)
2024-05-21 17:09:18 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-21 17:11:44 +0200mei(~mei@user/mei)
2024-05-21 17:15:09 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 17:15:35 +0200acidjnk_new(~acidjnk@p200300d6e714dc192d105e993ca958d7.dip0.t-ipconnect.de)
2024-05-21 17:33:36 +0200ocra8(ocra8@user/ocra8)
2024-05-21 17:34:24 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 256 seconds)
2024-05-21 17:34:56 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:f77c:428b:229c:4616) (Remote host closed the connection)
2024-05-21 17:35:16 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:8905:bde4:99bc:a84f)
2024-05-21 17:40:18 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-21 17:45:21 +0200sawilagar(~sawilagar@user/sawilagar) (Quit: Leaving)
2024-05-21 17:52:36 +0200Midjak(~MarciZ@82.66.147.146)
2024-05-21 17:54:51 +0200euleritian(~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 17:55:10 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 17:56:56 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds)
2024-05-21 18:03:16 +0200infinity0(~infinity0@pwned.gg) (Remote host closed the connection)
2024-05-21 18:05:23 +0200infinity0(~infinity0@pwned.gg)
2024-05-21 18:08:08 +0200y04nn(~username@2a03:1b20:8:f011::e10d)
2024-05-21 18:08:10 +0200titibandit(~user@user/titibandit)
2024-05-21 18:11:17 +0200CiaoSen(~Jura@2a05:5800:2b2:8e00:e6b9:7aff:fe80:3d03) (Ping timeout: 240 seconds)
2024-05-21 18:16:47 +0200danse-nr3(~danse-nr3@151.35.136.250) (Ping timeout: 264 seconds)
2024-05-21 18:17:48 +0200danse-nr3(~danse-nr3@151.43.113.96)
2024-05-21 18:23:59 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2024-05-21 18:24:13 +0200euleritian(~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de)
2024-05-21 18:27:32 +0200 <c_wraith> abs and signum are the weird ones...
2024-05-21 18:29:02 +0200 <int-e> just use abs x | x == 0 = 0 | otherwise = 1; signum x = x
2024-05-21 18:29:39 +0200 <c_wraith> Like, the meaning of signum is utterly baffling for non-scalar numbers. You can make sure (x == abs x * signum x) is true, but why you'd ever use expect signum to mean anything for a non-scalar is an interesting question
2024-05-21 18:32:32 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2024-05-21 18:35:40 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds)
2024-05-21 18:36:47 +0200 <dolio> Generalizing to magnitude and direction doesn't seem that weird.
2024-05-21 18:37:25 +0200 <dolio> Not sure about, like, matricies, though
2024-05-21 18:39:17 +0200noctux(~noctux@user/noctux) (Ping timeout: 272 seconds)
2024-05-21 18:39:19 +0200euleritian(~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 18:39:38 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 18:40:16 +0200noctux(~noctux@user/noctux)
2024-05-21 18:43:26 +0200 <d34df00d> Got a fairly ill-posed question here, but anyway. I'm looking at the disassembly of ghc to see how certain constructs get optimized, and there's a lot of boilerplate apparently related to laziness even if I do -XStrict (which makes sense, since the arguments aren't necessarily strict at the invocation site).
2024-05-21 18:43:31 +0200 <EvanR> matrices have a positive negative or zero determinant
2024-05-21 18:43:51 +0200 <d34df00d> Is there any decent way to get rid of that boilerplate (or at least clearly separate it out)?
2024-05-21 18:44:02 +0200manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck)
2024-05-21 18:44:38 +0200 <lxsameer> hey folks, I'm looking for some reading material on how the haskell compiler is designed and its internal architecture. Any suggestion?
2024-05-21 18:46:03 +0200 <kuribas> d34df00d: haskell assembly doesn't look like imperative assembly
2024-05-21 18:46:52 +0200 <mauke> https://www.stephendiehl.com/posts/ghc_01.html ?
2024-05-21 18:46:56 +0200 <kuribas> For example, all functions are called using continuation passing style.
2024-05-21 18:47:33 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2024-05-21 18:48:18 +0200 <mauke> you could try writing code that passes unboxed values around explicitly
2024-05-21 18:48:18 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 18:48:26 +0200 <mauke> not sure how helpful/workable that would be
2024-05-21 18:49:07 +0200 <lxsameer> mauke: cheers
2024-05-21 18:49:32 +0200 <kuribas> d34df00d: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/generated-code
2024-05-21 18:52:59 +0200Guest62(~Guest54@1.240.117.251)
2024-05-21 18:54:11 +0200ubert(~Thunderbi@2a02:8109:ab8a:5a00:8905:bde4:99bc:a84f) (Remote host closed the connection)
2024-05-21 18:54:34 +0200yin(~yin@user/zero) (Quit: Lost terminal)
2024-05-21 18:54:45 +0200 <lxsameer> thank you
2024-05-21 18:56:07 +0200lxsameer(~lxsameer@Serene/lxsameer) (Quit: WeeChat 4.2.1)
2024-05-21 18:58:17 +0200 <mauke> @let willHalt :: IO a -> IO Bool; willHalt = (True <$)
2024-05-21 18:58:18 +0200 <lambdabot> Defined.
2024-05-21 18:58:29 +0200 <mauke> > willHalt (pure ())
2024-05-21 18:58:30 +0200 <lambdabot> <IO Bool>
2024-05-21 18:59:37 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-21 19:00:23 +0200 <c_wraith> now.. willHaltUnsafely a = True <$ unsafeInterleaveIO a
2024-05-21 19:01:57 +0200danse-nr3(~danse-nr3@151.43.113.96) (Ping timeout: 255 seconds)
2024-05-21 19:02:02 +0200 <EvanR> :t fix willHalt
2024-05-21 19:02:04 +0200 <lambdabot> IO Bool
2024-05-21 19:04:01 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 19:04:16 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-21 19:05:06 +0200y04nn(~username@2a03:1b20:8:f011::e10d) (Ping timeout: 255 seconds)
2024-05-21 19:05:21 +0200 <mauke> proof of correctness: 'willHalt x' will return True for all actions x that halt
2024-05-21 19:05:31 +0200 <mauke> 'willHalt x' will never return True for any action x that doesn't halt
2024-05-21 19:06:42 +0200mei(~mei@user/mei)
2024-05-21 19:07:04 +0200 <EvanR> classically valid
2024-05-21 19:08:01 +0200 <ncf> that's the statement not the proof
2024-05-21 19:09:25 +0200 <EvanR> argument of correctness, ethos pathos logos
2024-05-21 19:09:39 +0200 <mauke> I use an old technique called "proof by assertion"
2024-05-21 19:10:09 +0200 <ncf> proof by intimidation
2024-05-21 19:11:29 +0200 <systemfault> I bench press more so I'm right?
2024-05-21 19:11:37 +0200chele(~chele@user/chele) (Remote host closed the connection)
2024-05-21 19:12:15 +0200 <Rembane> Proof by flex!
2024-05-21 19:12:20 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2024-05-21 19:12:53 +0200dtman34(~dtman34@c-75-72-163-222.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2024-05-21 19:12:55 +0200euleritian(~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de)
2024-05-21 19:15:32 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 19:17:10 +0200 <EvanR> too real
2024-05-21 19:18:15 +0200Guest62(~Guest54@1.240.117.251) (Quit: Client closed)
2024-05-21 19:18:39 +0200FragByte(~christian@user/fragbyte) (Quit: Quit)
2024-05-21 19:19:46 +0200euleritian(~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) (Read error: Connection reset by peer)
2024-05-21 19:20:03 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2024-05-21 19:20:23 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2024-05-21 19:20:35 +0200FragByte(~christian@user/fragbyte)
2024-05-21 19:20:41 +0200danse-nr3(~danse-nr3@151.43.113.96)
2024-05-21 19:23:38 +0200 <d34df00d> kuribas: I'm curious then how one might compare some common haskell constructs (think even pattern matching) to what happens in other, more imperative languages.
2024-05-21 19:26:37 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 19:26:54 +0200ocra8(ocra8@user/ocra8) (Quit: WeeChat 4.2.2)
2024-05-21 19:27:09 +0200 <EvanR> the core language has a simplified version of pattern matching which can be implemented like the switch statement in C
2024-05-21 19:27:39 +0200 <EvanR> the translation of haskell into core language is where the magic happens
2024-05-21 19:31:30 +0200 <EvanR> looking at core output can give clues to the success of optimizing
2024-05-21 19:32:06 +0200rdcdr(~rdcdr@user/rdcdr) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
2024-05-21 19:32:18 +0200 <EvanR> or lack of success
2024-05-21 19:32:47 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 256 seconds)
2024-05-21 19:33:42 +0200rdcdr(~rdcdr@user/rdcdr)
2024-05-21 19:40:57 +0200jstolarek(~jstolarek@staticline-31-183-174-191.toya.net.pl)
2024-05-21 19:43:21 +0200Guest86(~Guest41@186.82.99.37)
2024-05-21 19:43:48 +0200Guest86(~Guest41@186.82.99.37) ()
2024-05-21 19:47:31 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 19:51:56 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds)
2024-05-21 19:53:43 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-21 19:53:54 +0200lxsameer(~lxsameer@Serene/lxsameer)
2024-05-21 19:54:26 +0200 <lxsameer> hey folks, what lib do you recommend for using sqlite? Supporting db migrations is a plus
2024-05-21 20:01:38 +0200 <monochrom> I no longer distinguish continuation passing from call stack.
2024-05-21 20:02:36 +0200 <EvanR> care to explain how they are the same
2024-05-21 20:02:49 +0200 <dolio> The stack is the continuation.
2024-05-21 20:02:54 +0200 <monochrom> If you see a "push <code address>", it can be narrated as "push return address", but it can just as well be narrated as "push address of continuation". Same difference.
2024-05-21 20:03:50 +0200dtman34(~dtman34@2601:447:d001:ed50:ebe5:b36d:357b:8a39)
2024-05-21 20:03:53 +0200 <monochrom> And in the latter case, furthermore, "push" is narrated as "pass a parameter".
2024-05-21 20:05:01 +0200 <EvanR> this calls for a closed cartesian comics on this subject
2024-05-21 20:06:08 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com)
2024-05-21 20:07:52 +0200 <monochrom> ghc-generated code looks different from gcc-generated code because of better reasons than this. Evaluation order. Heap system. Closures. How they decide to use registers.
2024-05-21 20:11:01 +0200Guest86(~Guest86@186.82.99.37)
2024-05-21 20:11:16 +0200 <mauke> lxsameer: I like direct-sqlite. no built-in support for migrations, but pretty trivial to add IMHO. depends on what you expect from a migration feature
2024-05-21 20:11:29 +0200 <monochrom> The fact that Haskell FFI works best if Haskell code leave OS-sanctioned stack alone (so C code can use it unconfused) so ghc-generated code uses another register and another memory area for Haskell stack.
2024-05-21 20:12:33 +0200 <dolio> That's probably not the only reason.
2024-05-21 20:13:26 +0200Guest86(~Guest86@186.82.99.37) (Client Quit)
2024-05-21 20:14:02 +0200 <monochrom> Ah yeah, then also N Haskell threads can have N distinct Haskell stacks too.
2024-05-21 20:14:21 +0200 <monochrom> As a bonus, stack is also growable and movable.
2024-05-21 20:14:25 +0200 <dolio> Yeah. Switching out OS stacks is bad news, I think.
2024-05-21 20:16:02 +0200awnmp(~awnmp@user/awnmp)
2024-05-21 20:16:02 +0200gentauro(~gentauro@user/gentauro) (Read error: Connection reset by peer)
2024-05-21 20:16:25 +0200 <monochrom> OS stacks would be OK if there were a 1-1 mapping from Haskell threads to OS threads. OS threads already enjoy individual stacks. But of course we are more ambitious, we want our own cramming M Haskell threads into 1 OS thread.
2024-05-21 20:17:19 +0200 <monochrom> It also turns out we want to liberally move Haskell threads to any OS thread at a whim.
2024-05-21 20:17:59 +0200peterbecich(~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2024-05-21 20:18:20 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 260 seconds)
2024-05-21 20:18:44 +0200 <dolio> Yeah, I guess. The problem is that you can't get away with having as many OS threads as people want Haskell threads.
2024-05-21 20:19:21 +0200 <dolio> At least, last I heard.
2024-05-21 20:20:01 +0200 <geekosaur> C/Gtk programmers have told me otherwise (thousands of threads)
2024-05-21 20:20:32 +0200 <monochrom> We certainly recommend "don't bother writing your own select event loop, just fork more threads". So the RTS has to actually optimize for that. >:)
2024-05-21 20:21:11 +0200 <lxsameer> mauke: cheers
2024-05-21 20:21:43 +0200 <dolio> Are they actually using OS threads? I thought there was some other C thing that people used when they wanted that level of concurrency.
2024-05-21 20:21:53 +0200gentauro(~gentauro@user/gentauro)
2024-05-21 20:21:56 +0200 <monochrom> But lazy evaluation is the major difference. It also has the domino effect of causing many other differences e.g. how and why GHC does heap, closures, and GC in a way a C compiler doesn't.
2024-05-21 20:21:57 +0200 <Rembane> The uv thing?
2024-05-21 20:22:06 +0200 <dolio> Yeah, that sounds right.
2024-05-21 20:23:44 +0200 <geekosaur> pthread_create. and libuv is an event loop, not a thread multiplexer
2024-05-21 20:24:07 +0200 <geekosaur> Gtk provides its own event loop
2024-05-21 20:35:03 +0200ft(~ft@p508db8fc.dip0.t-ipconnect.de)
2024-05-21 20:35:38 +0200 <mauke> fibers, maybe
2024-05-21 20:38:02 +0200 <mauke> last time I tried to benchmark thread systems (by creating an ever-growing bucket chain of threads in various systems/languages), C/pthreads maxed out at a couple hundred threads IIRC
2024-05-21 20:38:25 +0200 <mauke> perl was under 100
2024-05-21 20:39:04 +0200 <mauke> haskell got very slow, but still made visible progress at 300,000 threads
2024-05-21 20:39:09 +0200 <[exa]> let's take a moment now to commemorate the magnificent glorious 1 globally interpreter-locked thread of python
2024-05-21 20:39:42 +0200 <mauke> (mind, this was a 32-bit system with limited RAM)
2024-05-21 20:40:41 +0200Guest86(~Guest86@186.82.99.37)
2024-05-21 20:41:02 +0200 <[exa]> dolio: btw the last time I read the RTS the total haskell IO-thread (_not_ OS thread) count was much more like memory-bounded than actually switch-starvation-bounded
2024-05-21 20:41:24 +0200 <dolio> Yeah.
2024-05-21 20:41:59 +0200 <dolio> There's an old ghc tracker ticker where Simon Marlow says he ran 1 million threads without a problem.
2024-05-21 20:42:12 +0200 <dolio> Although I assume they weren't doing much.
2024-05-21 20:42:38 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net)
2024-05-21 20:42:39 +0200 <[exa]> like, most threads in existence just wait for some resource to arrive anyway, right
2024-05-21 20:43:28 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf)
2024-05-21 20:50:01 +0200kuribas(~user@ptr-17d51encis8jg2ccf48.18120a2.ip6.access.telenet.be) (Remote host closed the connection)
2024-05-21 20:50:40 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-21 20:52:29 +0200yin(~yin@user/zero)
2024-05-21 20:54:51 +0200mesaoptimizer(~mesaoptim@user/PapuaHardyNet) (Quit: mesaoptimizer)
2024-05-21 20:55:05 +0200mesaoptimizer(~mesaoptim@user/PapuaHardyNet)
2024-05-21 20:58:18 +0200 <EvanR> worker threads that can wait for work, furiously accomplish something and go back to sleep in ~0 time, vs the thread running the black hole merger simulation
2024-05-21 21:08:59 +0200Guest86(~Guest86@186.82.99.37) (Quit: Client closed)
2024-05-21 21:17:23 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds)
2024-05-21 21:17:58 +0200JimL(~quassel@89.162.16.26) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2024-05-21 21:17:59 +0200raehik(~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds)
2024-05-21 21:18:20 +0200JimL(~quassel@89.162.16.26)
2024-05-21 21:19:06 +0200mrmonday(~robert@what.i.hope.is.not.a.tabernaevagant.es) (Quit: .)
2024-05-21 21:21:29 +0200mrmonday(~robert@what.i.hope.is.not.a.tabernaevagant.es)
2024-05-21 21:21:51 +0200tolt_tolt
2024-05-21 21:26:22 +0200causal(~eric@50.35.88.207) (Quit: WeeChat 4.1.1)
2024-05-21 21:27:18 +0200justsomeguy(~justsomeg@user/justsomeguy)
2024-05-21 21:27:30 +0200justsomeguy(~justsomeg@user/justsomeguy) (Read error: Connection reset by peer)
2024-05-21 21:33:32 +0200justsomeguy(~justsomeg@user/justsomeguy)
2024-05-21 21:34:57 +0200y04nn(~username@2a03:1b20:8:f011::e10d)
2024-05-21 21:34:57 +0200justsomeguy(~justsomeg@user/justsomeguy) (Read error: Connection reset by peer)
2024-05-21 21:34:59 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-21 21:37:25 +0200mei(~mei@user/mei)
2024-05-21 21:40:46 +0200justsomeguy(~justsomeg@user/justsomeguy)
2024-05-21 21:40:48 +0200jstolarek(~jstolarek@staticline-31-183-174-191.toya.net.pl) (Quit: Lost terminal)
2024-05-21 21:41:22 +0200justsomeguy(~justsomeg@user/justsomeguy) (Read error: Connection reset by peer)
2024-05-21 21:41:42 +0200aryah(~aryah@141-138-38-218.dsl.iskon.hr) (Read error: Connection reset by peer)
2024-05-21 21:47:00 +0200justsomeguy(~justsomeg@user/justsomeguy)
2024-05-21 21:47:00 +0200justsomeguy(~justsomeg@user/justsomeguy) (Read error: Connection reset by peer)
2024-05-21 21:47:34 +0200y04nn(~username@2a03:1b20:8:f011::e10d) (Remote host closed the connection)
2024-05-21 21:47:40 +0200aryah(~aryah@141-138-38-218.dsl.iskon.hr)
2024-05-21 21:47:48 +0200y04nn(~username@2a03:1b20:8:f011::e10d)
2024-05-21 21:49:49 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-21 21:52:42 +0200basicnpc(~asleep@user/basicnpc)
2024-05-21 21:52:42 +0200basicnpc(~asleep@user/basicnpc) (Remote host closed the connection)
2024-05-21 21:58:33 +0200 <lxsameer> is there any library to manage user configurations? for exmaple automatically map cli args to yaml keys and env vars?
2024-05-21 22:01:31 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2024-05-21 22:03:39 +0200jcarpenter2(~lol@2603:3016:1e01:b980:f1ac:fe7d:6abe:6f13)
2024-05-21 22:04:57 +0200 <monochrom> I would think I would prefer mapping all of cli args, yaml keys, env vars to my internal algebaric data type, not among themselves, why would I need that.
2024-05-21 22:05:23 +0200 <monochrom> At which point it is 3 libraries, one for each input format. But then all 3 already exist.
2024-05-21 22:07:20 +0200 <lxsameer> monochrom: i'm looking for a way to let the user configure the app
2024-05-21 22:12:19 +0200machinedgod(~machinedg@d173-183-246-216.abhsia.telus.net)
2024-05-21 22:14:56 +0200kayvank(~user@52-119-115-185.PUBLIC.monkeybrains.net)
2024-05-21 22:15:56 +0200danse-nr3(~danse-nr3@151.43.113.96) (Ping timeout: 260 seconds)
2024-05-21 22:16:17 +0200zetef(~quassel@5.2.182.98)
2024-05-21 22:20:30 +0200ec(~ec@gateway/tor-sasl/ec) (Ping timeout: 260 seconds)
2024-05-21 22:20:57 +0200jinsun(~jinsun@user/jinsun) (Ping timeout: 272 seconds)
2024-05-21 22:23:44 +0200awnmp(~awnmp@user/awnmp) (Quit: WeeChat 4.2.2)
2024-05-21 22:28:10 +0200jinsun(~jinsun@user/jinsun)
2024-05-21 22:30:17 +0200jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2024-05-21 22:36:52 +0200iteratee(~kyle@162.218.222.207) (Read error: Connection reset by peer)
2024-05-21 22:37:07 +0200iteratee(~kyle@162.218.222.207)
2024-05-21 22:40:04 +0200 <EvanR> app :: Config -> IO ()
2024-05-21 22:47:48 +0200phma(phma@2001:5b0:210f:6338:6b26:1f57:9336:4cb3) (Read error: Connection reset by peer)
2024-05-21 22:47:59 +0200lxsameer(~lxsameer@Serene/lxsameer) (Ping timeout: 264 seconds)
2024-05-21 22:52:42 +0200phma(~phma@host-67-44-208-11.hnremote.net)
2024-05-21 22:54:01 +0200xstill_(xstill@fimu/xstill) (Quit: Ping timeout (120 seconds))
2024-05-21 22:54:53 +0200xstill_(xstill@fimu/xstill)
2024-05-21 22:54:53 +0200mauke(~mauke@user/mauke) (Ping timeout: 268 seconds)
2024-05-21 22:55:13 +0200migas97(~migas@static.140.65.63.178.clients.your-server.de) (Quit: Ping timeout (120 seconds))
2024-05-21 22:55:13 +0200mauke(~mauke@user/mauke)
2024-05-21 22:55:30 +0200migas97(~migas@static.140.65.63.178.clients.your-server.de)
2024-05-21 22:56:08 +0200Dykam(Dykam@dykam.nl) (Remote host closed the connection)
2024-05-21 22:57:18 +0200Dykam(Dykam@dykam.nl)
2024-05-21 22:57:39 +0200philopsos1(~caecilius@user/philopsos)
2024-05-21 23:01:46 +0200philopsos1(~caecilius@user/philopsos) (Client Quit)
2024-05-21 23:02:08 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 260 seconds)
2024-05-21 23:04:24 +0200philopsos1(~caecilius@user/philopsos)
2024-05-21 23:05:20 +0200euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2024-05-21 23:06:37 +0200pavonia(~user@user/siracusa)
2024-05-21 23:11:00 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds)
2024-05-21 23:11:53 +0200zetef(~quassel@5.2.182.98) (Remote host closed the connection)
2024-05-21 23:12:52 +0200hgolden(~hgolden@2603:8000:9d00:3ed1:2678:8497:aa5c:7fa9) (Remote host closed the connection)
2024-05-21 23:15:20 +0200hgolden(~hgolden@2603:8000:9d00:3ed1:2678:8497:aa5c:7fa9)
2024-05-21 23:15:35 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds)
2024-05-21 23:15:40 +0200lol_(~lol@2603:3016:1e01:b980:557b:2881:fb5f:f7b0)
2024-05-21 23:15:57 +0200jcarpenter2(~lol@2603:3016:1e01:b980:f1ac:fe7d:6abe:6f13) (Read error: Connection reset by peer)
2024-05-21 23:17:02 +0200lol_jcarpenter2
2024-05-21 23:19:00 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-21 23:22:32 +0200motherfsck(~motherfsc@user/motherfsck) (Quit: quit)
2024-05-21 23:24:17 +0200Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2024-05-21 23:24:48 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2024-05-21 23:27:58 +0200jcarpenter2(~lol@2603:3016:1e01:b980:557b:2881:fb5f:f7b0) (Read error: Connection reset by peer)
2024-05-21 23:28:05 +0200jcarpenter2(~lol@2603:3016:1e01:b980:6c3b:ba23:fce8:e37c)
2024-05-21 23:28:48 +0200michalz(~michalz@185.246.207.221) (Quit: ZNC 1.9.0 - https://znc.in)
2024-05-21 23:35:12 +0200Square(~Square@user/square)
2024-05-21 23:36:40 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2024-05-21 23:36:40 +0200lol_(~lol@2603:3016:1e01:b9a0:a184:6ee0:68d5:cf53)
2024-05-21 23:38:15 +0200Square2(~Square4@user/square) (Ping timeout: 255 seconds)
2024-05-21 23:40:11 +0200titibandit(~user@user/titibandit) (Ping timeout: 264 seconds)
2024-05-21 23:40:45 +0200jcarpenter2(~lol@2603:3016:1e01:b980:6c3b:ba23:fce8:e37c) (Ping timeout: 272 seconds)
2024-05-21 23:41:59 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds)
2024-05-21 23:43:21 +0200lol_jcarpenter2
2024-05-21 23:45:21 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-05-21 23:48:09 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2024-05-21 23:48:39 +0200mei(~mei@user/mei) (Remote host closed the connection)
2024-05-21 23:49:35 +0200lol_(~lol@2603:3016:1e01:b9a0:f567:9fc4:eb72:a51c)
2024-05-21 23:51:05 +0200mei(~mei@user/mei)
2024-05-21 23:53:17 +0200jcarpenter2(~lol@2603:3016:1e01:b9a0:a184:6ee0:68d5:cf53) (Ping timeout: 240 seconds)
2024-05-21 23:53:38 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2024-05-21 23:56:18 +0200lol_jcarpenter2