| 2024-05-21 00:04:20 +0200 | euleritian | (~euleritia@dynamic-176-006-180-037.176.6.pool.telefonica.de) |
| 2024-05-21 00:05:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-05-21 00:06:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 00:11:11 +0200 | AlexNoo_ | (~AlexNoo@178.34.163.203) |
| 2024-05-21 00:13:41 +0200 | AlexZenon | (~alzenon@5.139.232.131) (Ping timeout: 240 seconds) |
| 2024-05-21 00:13:43 +0200 | Sgeo | (~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 +0200 | AlexNoo | (~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 +0200 | AlexZenon | (~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 +0200 | euleritian | (~euleritia@dynamic-176-006-180-037.176.6.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-05-21 00:21:53 +0200 | euleritian | (~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 +0200 | mikess | (~mikess@user/mikess) (Ping timeout: 264 seconds) |
| 2024-05-21 00:31:08 +0200 | Square | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2024-05-21 00:34:47 +0200 | aryah | (~aryah@141-138-38-218.dsl.iskon.hr) (Ping timeout: 264 seconds) |
| 2024-05-21 00:35:03 +0200 | aryah | (~aryah@141-138-45-48.dsl.iskon.hr) |
| 2024-05-21 00:38:08 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2024-05-21 00:39:33 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-05-21 00:40:11 +0200 | aryah | (~aryah@141-138-45-48.dsl.iskon.hr) (Ping timeout: 264 seconds) |
| 2024-05-21 00:41:03 +0200 | aryah | (~aryah@141-138-38-218.dsl.iskon.hr) |
| 2024-05-21 00:53:37 +0200 | troydm | (~troydm@user/troydm) |
| 2024-05-21 00:56:29 +0200 | euleritian | (~euleritia@dynamic-176-003-074-222.176.3.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 00:56:48 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-21 01:03:11 +0200 | nadja | (~dequbed@banana-new.kilobyte22.de) (Quit: bye!) |
| 2024-05-21 01:04:23 +0200 | xff0x | (~xff0x@2405:6580:b080:900:4704:a3e5:3fba:c1dc) (Ping timeout: 256 seconds) |
| 2024-05-21 01:06:03 +0200 | xff0x | (~xff0x@2405:6580:b080:900:a157:6ed1:5915:7c2c) |
| 2024-05-21 01:07:57 +0200 | pdw | (~user@215.156.62.185.bridgefibre.net) (Ping timeout: 272 seconds) |
| 2024-05-21 01:09:41 +0200 | xff0x | (~xff0x@2405:6580:b080:900:a157:6ed1:5915:7c2c) (Client Quit) |
| 2024-05-21 01:15:26 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-05-21 01:15:40 +0200 | xff0x | (~xff0x@2405:6580:b080:900:b527:98ae:f93a:e494) |
| 2024-05-21 01:22:53 +0200 | nickiminjaj | (~kvirc@user/laxhh) (Quit: KVIrc 5.2.2 Quasar http://www.kvirc.net/) |
| 2024-05-21 01:29:46 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-05-21 01:31:20 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc12c1768acda4802182.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-05-21 01:32:16 +0200 | Nixkernal | (~Nixkernal@240.17.194.178.dynamic.wline.res.cust.swisscom.ch) (Ping timeout: 260 seconds) |
| 2024-05-21 01:53:10 +0200 | phma | (~phma@host-67-44-208-139.hnremote.net) (Read error: Connection reset by peer) |
| 2024-05-21 01:54:08 +0200 | phma | (phma@2001:5b0:210f:6338:6b26:1f57:9336:4cb3) |
| 2024-05-21 01:54:41 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-21 02:28:57 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 268 seconds) |
| 2024-05-21 02:34:25 +0200 | it_ | (~quassel@v2202212189510211193.supersrv.de) (Quit: ,o>) |
| 2024-05-21 02:34:50 +0200 | it_ | (~quassel@v2202212189510211193.supersrv.de) |
| 2024-05-21 02:35:17 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-05-21 02:35:35 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-21 02:49:44 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-05-21 02:50:59 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-05-21 02:57:05 +0200 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2024-05-21 03:05:08 +0200 | xdminsy | (~xdminsy@117.147.70.240) (Ping timeout: 260 seconds) |
| 2024-05-21 03:06:10 +0200 | xdminsy | (~xdminsy@117.147.70.240) |
| 2024-05-21 03:11:48 +0200 | sayola | (~sayola@ip-109-42-242-108.web.vodafone.de) |
| 2024-05-21 03:13:41 +0200 | sayola1 | (~sayola@ip-109-42-241-204.web.vodafone.de) (Ping timeout: 240 seconds) |
| 2024-05-21 03:15:16 +0200 | xdminsy | (~xdminsy@117.147.70.240) (Read error: Connection reset by peer) |
| 2024-05-21 03:16:04 +0200 | xdminsy | (~xdminsy@117.147.70.240) |
| 2024-05-21 03:20:39 +0200 | xdminsy | (~xdminsy@117.147.70.240) (Read error: Connection reset by peer) |
| 2024-05-21 03:21:46 +0200 | xdminsy | (~xdminsy@117.147.70.240) |
| 2024-05-21 03:26:51 +0200 | xff0x | (~xff0x@2405:6580:b080:900:b527:98ae:f93a:e494) (Ping timeout: 255 seconds) |
| 2024-05-21 03:28:40 +0200 | xdminsy | (~xdminsy@117.147.70.240) (Read error: Connection reset by peer) |
| 2024-05-21 03:29:01 +0200 | xdminsy | (~xdminsy@117.147.70.240) |
| 2024-05-21 04:00:01 +0200 | fliife | (~fliife@user/fliife) (Quit: ZNC 1.8.2+deb2build5 - https://znc.in) |
| 2024-05-21 04:00:48 +0200 | fliife | (~fliife@user/fliife) |
| 2024-05-21 04:00:53 +0200 | otto_s | (~user@p5de2fafb.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2024-05-21 04:02:56 +0200 | otto_s | (~user@p5de2f060.dip0.t-ipconnect.de) |
| 2024-05-21 04:05:59 +0200 | td_ | (~td@i53870921.versanet.de) (Ping timeout: 264 seconds) |
| 2024-05-21 04:07:44 +0200 | td_ | (~td@i5387090E.versanet.de) |
| 2024-05-21 04:14:05 +0200 | agent314 | (~quassel@184.75.215.3) (Ping timeout: 240 seconds) |
| 2024-05-21 04:14:11 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-05-21 04:15:07 +0200 | agent314 | (~quassel@104.129.57.116) |
| 2024-05-21 04:15:35 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 264 seconds) |
| 2024-05-21 04:40:45 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-21 04:41:23 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2024-05-21 04:41:37 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-05-21 04:44:59 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2024-05-21 04:50:46 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:64b6:9e88:7ce7:a120) |
| 2024-05-21 05:06:52 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-05-21 05:11:23 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-05-21 05:17:17 +0200 | yin | (~yin@user/zero) (Ping timeout: 240 seconds) |
| 2024-05-21 05:28:11 +0200 | aforemny_ | (~aforemny@i59F516F9.versanet.de) (Ping timeout: 264 seconds) |
| 2024-05-21 05:28:38 +0200 | aforemny | (~aforemny@2001:9e8:6cca:4800:37b5:fb76:9e3f:6a26) |
| 2024-05-21 05:42:48 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-21 05:49:24 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-05-21 05:52:55 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2024-05-21 05:56:02 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-21 06:00:35 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-05-21 06:26:23 +0200 | agent314 | (~quassel@104.129.57.116) (Ping timeout: 264 seconds) |
| 2024-05-21 06:26:36 +0200 | agent314 | (~quassel@162.219.176.19) |
| 2024-05-21 06:34:50 +0200 | michalz | (~michalz@185.246.207.203) |
| 2024-05-21 06:35:05 +0200 | michalz | (~michalz@185.246.207.203) (Client Quit) |
| 2024-05-21 06:37:54 +0200 | michalz | (~michalz@185.246.207.221) |
| 2024-05-21 06:46:50 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-21 07:17:01 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-05-21 07:18:08 +0200 | zetef | (~quassel@5.2.182.99) |
| 2024-05-21 07:20:52 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-05-21 07:27:43 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-05-21 07:30:07 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-05-21 07:30:42 +0200 | vladl | (~vladl@24.35.90.183) |
| 2024-05-21 07:37:18 +0200 | johnw_ | (~johnw@69.62.242.138) (Quit: ZNC - http://znc.in) |
| 2024-05-21 07:38:50 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-21 07:40:59 +0200 | demon-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 +0200 | demon-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 +0200 | geekosaur | is 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 +0200 | johnw | (~johnw@69.62.242.138) |
| 2024-05-21 07:57:35 +0200 | peterbecich | (~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 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 08:10:56 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-21 08:13:25 +0200 | internatetional | (~nate@182.2.51.214) |
| 2024-05-21 08:13:53 +0200 | internatetional | (~nate@182.2.51.214) (Max SendQ exceeded) |
| 2024-05-21 08:14:11 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 08:15:35 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-05-21 08:18:56 +0200 | sord937 | (~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 +0200 | tromp | (~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 +0200 | ski | isn'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 +0200 | ski | doesn'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 +0200 | sayola1 | (~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 +0200 | sayola | (~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 +0200 | sayola1 | (~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 +0200 | sayola | (~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 +0200 | lortabac | (~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 +0200 | acidjnk_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 +0200 | cfricke | (~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 +0200 | chele | (~chele@user/chele) |
| 2024-05-21 09:32:31 +0200 | ubert | (~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 +0200 | kuribas | (~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 +0200 | ubert | (~Thunderbi@p200300ecdf1a44e6bddfe2bf28cca96e.dip0.t-ipconnect.de) (Quit: ubert) |
| 2024-05-21 09:42:45 +0200 | tromp | (~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 +0200 | tromp | (~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 +0200 | danse-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 +0200 | machinedgod | (~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 +0200 | tromp | (~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 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 10:07:17 +0200 | son0p | (~ff@186.121.14.247) (Ping timeout: 240 seconds) |
| 2024-05-21 10:08:02 +0200 | Square2 | (~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 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) (Ping timeout: 260 seconds) |
| 2024-05-21 10:08:34 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-05-21 10:08:59 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Ping timeout: 268 seconds) |
| 2024-05-21 10:09:19 +0200 | Nixkernal | (~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 +0200 | danse-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 +0200 | tromp | (~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 +0200 | tzh | (~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 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) (Ping timeout: 255 seconds) |
| 2024-05-21 10:29:48 +0200 | danse-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 +0200 | ft | (~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 +0200 | tromp | (~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 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2024-05-21 10:43:13 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-05-21 10:46:06 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 260 seconds) |
| 2024-05-21 10:47:04 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:6584:33d2:35a2:fd74) |
| 2024-05-21 10:48:06 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2024-05-21 10:49:59 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-05-21 10:54:08 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) (Ping timeout: 260 seconds) |
| 2024-05-21 10:57:59 +0200 | danse-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 +0200 | danse-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 +0200 | danse-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 +0200 | Flow | (~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 +0200 | tromp | (~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 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-05-21 11:38:16 +0200 | Flow | (~none@gentoo/developer/flow) |
| 2024-05-21 11:42:43 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 11:57:06 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) (Remote host closed the connection) |
| 2024-05-21 11:57:26 +0200 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2024-05-21 11:57:58 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-05-21 11:58:26 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) |
| 2024-05-21 12:00:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 12:01:19 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) (Read error: Connection reset by peer) |
| 2024-05-21 12:02:59 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-05-21 12:03:26 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-05-21 12:03:43 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) |
| 2024-05-21 12:04:13 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 12:04:38 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-21 12:04:51 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 12:05:21 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2024-05-21 12:09:23 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 252 seconds) |
| 2024-05-21 12:11:03 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-21 12:11:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-21 12:12:38 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) |
| 2024-05-21 12:23:16 +0200 | aryah | (~aryah@141-138-38-218.dsl.iskon.hr) (Read error: Connection reset by peer) |
| 2024-05-21 12:25:03 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 255 seconds) |
| 2024-05-21 12:28:27 +0200 | son0p | (~ff@181.32.157.144) |
| 2024-05-21 12:39:55 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:64b6:9e88:7ce7:a120) (Quit: Leaving) |
| 2024-05-21 12:40:36 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:6584:33d2:35a2:fd74) (Remote host closed the connection) |
| 2024-05-21 12:40:49 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:f77c:428b:229c:4616) |
| 2024-05-21 12:47:47 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 12:53:59 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-05-21 12:54:24 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) |
| 2024-05-21 12:54:33 +0200 | yin | (~yin@user/zero) |
| 2024-05-21 12:56:53 +0200 | danse-nr3 | (~danse-nr3@151.35.171.208) (Ping timeout: 240 seconds) |
| 2024-05-21 13:01:58 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 255 seconds) |
| 2024-05-21 13:04:06 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 13:07:42 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-05-21 13:08:17 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
| 2024-05-21 13:13:42 +0200 | xff0x | (~xff0x@2405:6580:b080:900:6e2f:a302:dfa:99b5) |
| 2024-05-21 13:16:18 +0200 | CiaoSen | (~Jura@2a05:5800:2b2:8e00:e6b9:7aff:fe80:3d03) |
| 2024-05-21 13:19:29 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 13:19:56 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-05-21 13:20:34 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 13:27:29 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:eb4a:233c:d82d:5868) |
| 2024-05-21 13:29:49 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-21 13:30:55 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 13:35:57 +0200 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-05-21 13:42:49 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 13:43:17 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) |
| 2024-05-21 13:46:33 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 13:49:45 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b940:892b:2549:5c20:9c9b) (Ping timeout: 268 seconds) |
| 2024-05-21 13:55:40 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2024-05-21 13:56:27 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2) |
| 2024-05-21 13:57:10 +0200 | joeyadams | (~joeyadams@2603:6010:5100:2ed:eb4a:233c:d82d:5868) (Quit: Leaving) |
| 2024-05-21 13:57:49 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-05-21 13:58:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 14:00:26 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) |
| 2024-05-21 14:02:59 +0200 | yin | (~yin@user/zero) (Ping timeout: 264 seconds) |
| 2024-05-21 14:04:08 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 14:08:55 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 14:09:12 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-05-21 14:09:32 +0200 | yin | (~yin@user/zero) |
| 2024-05-21 14:13:48 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 268 seconds) |
| 2024-05-21 14:14:02 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) |
| 2024-05-21 14:22:56 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-05-21 14:23:12 +0200 | euleritian | (~euleritia@dynamic-176-006-198-126.176.6.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2024-05-21 14:24:29 +0200 | euleritian | (~euleritia@dynamic-176-001-018-229.176.1.pool.telefonica.de) |
| 2024-05-21 14:28:43 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 14:35:48 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2024-05-21 14:39:32 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 260 seconds) |
| 2024-05-21 14:41:33 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.2.1) |
| 2024-05-21 14:51:00 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) |
| 2024-05-21 14:51:00 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:6009:6384:e3cb:2220) (Changing host) |
| 2024-05-21 14:51:00 +0200 | haritz | (~hrtz@user/haritz) |
| 2024-05-21 14:52:33 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 14:54:14 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-05-21 14:55:53 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-21 15:08:20 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-05-21 15:22:22 +0200 | ystael | (~ystael@user/ystael) |
| 2024-05-21 15:33:05 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc192d105e993ca958d7.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-05-21 15:34:34 +0200 | weechat | dminuoso |
| 2024-05-21 15:34:51 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 260 seconds) |
| 2024-05-21 15:35:31 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2024-05-21 15:36:35 +0200 | euleritian | (~euleritia@dynamic-176-001-018-229.176.1.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-05-21 15:37:03 +0200 | euleritian | (~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) |
| 2024-05-21 15:43:08 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-21 15:56:29 +0200 | zetef | (~quassel@5.2.182.99) (Remote host closed the connection) |
| 2024-05-21 16:01:19 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb2 - https://znc.in) |
| 2024-05-21 16:01:50 +0200 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) |
| 2024-05-21 16:03:40 +0200 | haritz | (~hrtz@82-69-11-11.dsl.in-addr.zen.co.uk) (Changing host) |
| 2024-05-21 16:03:40 +0200 | haritz | (~hrtz@user/haritz) |
| 2024-05-21 16:04:15 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Quit: Lost terminal) |
| 2024-05-21 16:13:00 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-05-21 16:14:29 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds) |
| 2024-05-21 16:21:39 +0200 | danse-nr3 | (~danse-nr3@151.35.136.250) |
| 2024-05-21 16:27:34 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Quit: So long and thanks for all the fish) |
| 2024-05-21 16:27:55 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2024-05-21 16:30:12 +0200 | haritz | (~hrtz@user/haritz) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in) |
| 2024-05-21 16:32:38 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) |
| 2024-05-21 16:32:41 +0200 | haritz | (~hrtz@2a02:8010:65b5:0:5d9a:9bab:ee5e:b737) (Changing host) |
| 2024-05-21 16:32:41 +0200 | haritz | (~hrtz@user/haritz) |
| 2024-05-21 16:34:24 +0200 | bontaq | (~user@ool-45779c03.dyn.optonline.net) |
| 2024-05-21 16:42:37 +0200 | sayola | (~sayola@ip-109-42-241-195.web.vodafone.de) (Read error: Connection reset by peer) |
| 2024-05-21 16:42:45 +0200 | sayola | (~sayola@ip-109-42-243-149.web.vodafone.de) |
| 2024-05-21 16:50:52 +0200 | aryah | (~aryah@141-138-38-218.dsl.iskon.hr) |
| 2024-05-21 16:53:47 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-21 16:58:47 +0200 | agent314 | (~quassel@162.219.176.19) (Ping timeout: 264 seconds) |
| 2024-05-21 17:09:07 +0200 | d34df00d | (~d34df00d@2600:1702:4f1b:7c10::43) |
| 2024-05-21 17:09:18 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-21 17:11:44 +0200 | mei | (~mei@user/mei) |
| 2024-05-21 17:15:09 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 17:15:35 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc192d105e993ca958d7.dip0.t-ipconnect.de) |
| 2024-05-21 17:33:36 +0200 | ocra8 | (ocra8@user/ocra8) |
| 2024-05-21 17:34:24 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2024-05-21 17:34:56 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:f77c:428b:229c:4616) (Remote host closed the connection) |
| 2024-05-21 17:35:16 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:8905:bde4:99bc:a84f) |
| 2024-05-21 17:40:18 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-21 17:45:21 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2024-05-21 17:52:36 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-05-21 17:54:51 +0200 | euleritian | (~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 17:55:10 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-21 17:56:56 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 260 seconds) |
| 2024-05-21 18:03:16 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2024-05-21 18:05:23 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-05-21 18:08:08 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-05-21 18:08:10 +0200 | titibandit | (~user@user/titibandit) |
| 2024-05-21 18:11:17 +0200 | CiaoSen | (~Jura@2a05:5800:2b2:8e00:e6b9:7aff:fe80:3d03) (Ping timeout: 240 seconds) |
| 2024-05-21 18:16:47 +0200 | danse-nr3 | (~danse-nr3@151.35.136.250) (Ping timeout: 264 seconds) |
| 2024-05-21 18:17:48 +0200 | danse-nr3 | (~danse-nr3@151.43.113.96) |
| 2024-05-21 18:23:59 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-05-21 18:24:13 +0200 | euleritian | (~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 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-05-21 18:35:40 +0200 | raehik | (~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 +0200 | noctux | (~noctux@user/noctux) (Ping timeout: 272 seconds) |
| 2024-05-21 18:39:19 +0200 | euleritian | (~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 18:39:38 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-21 18:40:16 +0200 | noctux | (~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 +0200 | manwithluck | (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 +0200 | euleritian | (~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 +0200 | euleritian | (~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 +0200 | Guest62 | (~Guest54@1.240.117.251) |
| 2024-05-21 18:54:11 +0200 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:8905:bde4:99bc:a84f) (Remote host closed the connection) |
| 2024-05-21 18:54:34 +0200 | yin | (~yin@user/zero) (Quit: Lost terminal) |
| 2024-05-21 18:54:45 +0200 | <lxsameer> | thank you |
| 2024-05-21 18:56:07 +0200 | lxsameer | (~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 +0200 | raehik | (~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 +0200 | danse-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 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-21 19:04:16 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-21 19:05:06 +0200 | y04nn | (~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 +0200 | mei | (~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 +0200 | chele | (~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 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-05-21 19:12:53 +0200 | dtman34 | (~dtman34@c-75-72-163-222.hsd1.mn.comcast.net) (Ping timeout: 240 seconds) |
| 2024-05-21 19:12:55 +0200 | euleritian | (~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) |
| 2024-05-21 19:15:32 +0200 | tromp | (~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 +0200 | Guest62 | (~Guest54@1.240.117.251) (Quit: Client closed) |
| 2024-05-21 19:18:39 +0200 | FragByte | (~christian@user/fragbyte) (Quit: Quit) |
| 2024-05-21 19:19:46 +0200 | euleritian | (~euleritia@dynamic-176-006-196-082.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-21 19:20:03 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-21 19:20:23 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-05-21 19:20:35 +0200 | FragByte | (~christian@user/fragbyte) |
| 2024-05-21 19:20:41 +0200 | danse-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 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-21 19:26:54 +0200 | ocra8 | (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 +0200 | rdcdr | (~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 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2024-05-21 19:33:42 +0200 | rdcdr | (~rdcdr@user/rdcdr) |
| 2024-05-21 19:40:57 +0200 | jstolarek | (~jstolarek@staticline-31-183-174-191.toya.net.pl) |
| 2024-05-21 19:43:21 +0200 | Guest86 | (~Guest41@186.82.99.37) |
| 2024-05-21 19:43:48 +0200 | Guest86 | (~Guest41@186.82.99.37) () |
| 2024-05-21 19:47:31 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-05-21 19:51:56 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-05-21 19:53:43 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-21 19:53:54 +0200 | lxsameer | (~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 +0200 | dtman34 | (~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 +0200 | peterbecich | (~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 +0200 | Guest86 | (~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 +0200 | Guest86 | (~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 +0200 | awnmp | (~awnmp@user/awnmp) |
| 2024-05-21 20:16:02 +0200 | gentauro | (~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 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds) |
| 2024-05-21 20:18:20 +0200 | raehik | (~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 +0200 | gentauro | (~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 +0200 | ft | (~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 +0200 | Guest86 | (~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 +0200 | raehik | (~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 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2024-05-21 20:50:01 +0200 | kuribas | (~user@ptr-17d51encis8jg2ccf48.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2024-05-21 20:50:40 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-21 20:52:29 +0200 | yin | (~yin@user/zero) |
| 2024-05-21 20:54:51 +0200 | mesaoptimizer | (~mesaoptim@user/PapuaHardyNet) (Quit: mesaoptimizer) |
| 2024-05-21 20:55:05 +0200 | mesaoptimizer | (~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 +0200 | Guest86 | (~Guest86@186.82.99.37) (Quit: Client closed) |
| 2024-05-21 21:17:23 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds) |
| 2024-05-21 21:17:58 +0200 | JimL | (~quassel@89.162.16.26) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2024-05-21 21:17:59 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) (Ping timeout: 264 seconds) |
| 2024-05-21 21:18:20 +0200 | JimL | (~quassel@89.162.16.26) |
| 2024-05-21 21:19:06 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Quit: .) |
| 2024-05-21 21:21:29 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 2024-05-21 21:21:51 +0200 | tolt_ | tolt |
| 2024-05-21 21:26:22 +0200 | causal | (~eric@50.35.88.207) (Quit: WeeChat 4.1.1) |
| 2024-05-21 21:27:18 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-05-21 21:27:30 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Read error: Connection reset by peer) |
| 2024-05-21 21:33:32 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-05-21 21:34:57 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-05-21 21:34:57 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Read error: Connection reset by peer) |
| 2024-05-21 21:34:59 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-21 21:37:25 +0200 | mei | (~mei@user/mei) |
| 2024-05-21 21:40:46 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-05-21 21:40:48 +0200 | jstolarek | (~jstolarek@staticline-31-183-174-191.toya.net.pl) (Quit: Lost terminal) |
| 2024-05-21 21:41:22 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Read error: Connection reset by peer) |
| 2024-05-21 21:41:42 +0200 | aryah | (~aryah@141-138-38-218.dsl.iskon.hr) (Read error: Connection reset by peer) |
| 2024-05-21 21:47:00 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2024-05-21 21:47:00 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Read error: Connection reset by peer) |
| 2024-05-21 21:47:34 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) (Remote host closed the connection) |
| 2024-05-21 21:47:40 +0200 | aryah | (~aryah@141-138-38-218.dsl.iskon.hr) |
| 2024-05-21 21:47:48 +0200 | y04nn | (~username@2a03:1b20:8:f011::e10d) |
| 2024-05-21 21:49:49 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-21 21:52:42 +0200 | basicnpc | (~asleep@user/basicnpc) |
| 2024-05-21 21:52:42 +0200 | basicnpc | (~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 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2024-05-21 22:03:39 +0200 | jcarpenter2 | (~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 +0200 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-05-21 22:14:56 +0200 | kayvank | (~user@52-119-115-185.PUBLIC.monkeybrains.net) |
| 2024-05-21 22:15:56 +0200 | danse-nr3 | (~danse-nr3@151.43.113.96) (Ping timeout: 260 seconds) |
| 2024-05-21 22:16:17 +0200 | zetef | (~quassel@5.2.182.98) |
| 2024-05-21 22:20:30 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 260 seconds) |
| 2024-05-21 22:20:57 +0200 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 272 seconds) |
| 2024-05-21 22:23:44 +0200 | awnmp | (~awnmp@user/awnmp) (Quit: WeeChat 4.2.2) |
| 2024-05-21 22:28:10 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2024-05-21 22:30:17 +0200 | jinsun | (~jinsun@user/jinsun) (Read error: Connection reset by peer) |
| 2024-05-21 22:36:52 +0200 | iteratee | (~kyle@162.218.222.207) (Read error: Connection reset by peer) |
| 2024-05-21 22:37:07 +0200 | iteratee | (~kyle@162.218.222.207) |
| 2024-05-21 22:40:04 +0200 | <EvanR> | app :: Config -> IO () |
| 2024-05-21 22:47:48 +0200 | phma | (phma@2001:5b0:210f:6338:6b26:1f57:9336:4cb3) (Read error: Connection reset by peer) |
| 2024-05-21 22:47:59 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 264 seconds) |
| 2024-05-21 22:52:42 +0200 | phma | (~phma@host-67-44-208-11.hnremote.net) |
| 2024-05-21 22:54:01 +0200 | xstill_ | (xstill@fimu/xstill) (Quit: Ping timeout (120 seconds)) |
| 2024-05-21 22:54:53 +0200 | xstill_ | (xstill@fimu/xstill) |
| 2024-05-21 22:54:53 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 268 seconds) |
| 2024-05-21 22:55:13 +0200 | migas97 | (~migas@static.140.65.63.178.clients.your-server.de) (Quit: Ping timeout (120 seconds)) |
| 2024-05-21 22:55:13 +0200 | mauke | (~mauke@user/mauke) |
| 2024-05-21 22:55:30 +0200 | migas97 | (~migas@static.140.65.63.178.clients.your-server.de) |
| 2024-05-21 22:56:08 +0200 | Dykam | (Dykam@dykam.nl) (Remote host closed the connection) |
| 2024-05-21 22:57:18 +0200 | Dykam | (Dykam@dykam.nl) |
| 2024-05-21 22:57:39 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-05-21 23:01:46 +0200 | philopsos1 | (~caecilius@user/philopsos) (Client Quit) |
| 2024-05-21 23:02:08 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 260 seconds) |
| 2024-05-21 23:04:24 +0200 | philopsos1 | (~caecilius@user/philopsos) |
| 2024-05-21 23:05:20 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2024-05-21 23:06:37 +0200 | pavonia | (~user@user/siracusa) |
| 2024-05-21 23:11:00 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2024-05-21 23:11:53 +0200 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2024-05-21 23:12:52 +0200 | hgolden | (~hgolden@2603:8000:9d00:3ed1:2678:8497:aa5c:7fa9) (Remote host closed the connection) |
| 2024-05-21 23:15:20 +0200 | hgolden | (~hgolden@2603:8000:9d00:3ed1:2678:8497:aa5c:7fa9) |
| 2024-05-21 23:15:35 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds) |
| 2024-05-21 23:15:40 +0200 | lol_ | (~lol@2603:3016:1e01:b980:557b:2881:fb5f:f7b0) |
| 2024-05-21 23:15:57 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b980:f1ac:fe7d:6abe:6f13) (Read error: Connection reset by peer) |
| 2024-05-21 23:17:02 +0200 | lol_ | jcarpenter2 |
| 2024-05-21 23:19:00 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-21 23:22:32 +0200 | motherfsck | (~motherfsc@user/motherfsck) (Quit: quit) |
| 2024-05-21 23:24:17 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-05-21 23:24:48 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2024-05-21 23:27:58 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b980:557b:2881:fb5f:f7b0) (Read error: Connection reset by peer) |
| 2024-05-21 23:28:05 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b980:6c3b:ba23:fce8:e37c) |
| 2024-05-21 23:28:48 +0200 | michalz | (~michalz@185.246.207.221) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-05-21 23:35:12 +0200 | Square | (~Square@user/square) |
| 2024-05-21 23:36:40 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) |
| 2024-05-21 23:36:40 +0200 | lol_ | (~lol@2603:3016:1e01:b9a0:a184:6ee0:68d5:cf53) |
| 2024-05-21 23:38:15 +0200 | Square2 | (~Square4@user/square) (Ping timeout: 255 seconds) |
| 2024-05-21 23:40:11 +0200 | titibandit | (~user@user/titibandit) (Ping timeout: 264 seconds) |
| 2024-05-21 23:40:45 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b980:6c3b:ba23:fce8:e37c) (Ping timeout: 272 seconds) |
| 2024-05-21 23:41:59 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 264 seconds) |
| 2024-05-21 23:43:21 +0200 | lol_ | jcarpenter2 |
| 2024-05-21 23:45:21 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |