| 2022-09-03 00:02:44 +0200 | leah_ | (lp0@heathens.club) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-03 00:03:23 +0200 | leah_ | (lp0@heathens.club) |
| 2022-09-03 00:04:07 +0200 | zmt00 | (~zmt00@user/zmt00) |
| 2022-09-03 00:04:19 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:a8c4:c646:2b11:d02f) (Ping timeout: 248 seconds) |
| 2022-09-03 00:07:07 +0200 | Guest5078 | (~Guest50@50.47.108.232) (Quit: Client closed) |
| 2022-09-03 00:17:47 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2022-09-03 00:18:29 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-09-03 00:18:50 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) (Remote host closed the connection) |
| 2022-09-03 00:19:13 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) |
| 2022-09-03 00:20:22 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-09-03 00:20:33 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 00:21:15 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-09-03 00:23:25 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 00:25:01 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-03 00:31:06 +0200 | fhn | (~fhn@2.58.185.24) |
| 2022-09-03 00:32:18 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2230878ffc93dd9ace.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-09-03 00:34:06 +0200 | <fhn> | I want to apply STArray s to newArray in ghci but this doesn't work: ghci> :t newArray @(forall s. STArray s) Can I do this somehow? |
| 2022-09-03 00:34:20 +0200 | <fhn> | (Error is: no impredicative polymorphism) |
| 2022-09-03 00:34:54 +0200 | luffy | (~chenqisu1@183.217.201.192) |
| 2022-09-03 00:37:29 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 00:38:00 +0200 | <geekosaur> | what's wrong with newSTArray? |
| 2022-09-03 00:40:16 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 00:43:22 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection) |
| 2022-09-03 00:43:34 +0200 | <fhn> | I didn't know it existed ;) I looked into Data.Array.ST and from there to Data.Array.MArray. I see now that newSTArray is in GHC.Arr |
| 2022-09-03 00:44:39 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 244 seconds) |
| 2022-09-03 00:44:52 +0200 | <geekosaur> | @index newSTArray |
| 2022-09-03 00:44:52 +0200 | <lambdabot> | bzzt |
| 2022-09-03 00:45:39 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 00:47:42 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-09-03 00:47:49 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) |
| 2022-09-03 00:48:07 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-09-03 00:48:31 +0200 | <fhn> | bzzt? |
| 2022-09-03 00:48:49 +0200 | <geekosaur> | I believe what you really want is https://hackage.haskell.org/package/array-0.5.4.0/docs/Data-Array-ST.html and runSTArray, not using newSTArray directly |
| 2022-09-03 00:48:57 +0200 | <geekosaur> | the bot was telling me it's not in base |
| 2022-09-03 00:50:06 +0200 | <geekosaur> | any module starting with "GHC" is an internals module and you probably shouldn't use it directly |
| 2022-09-03 00:50:24 +0200 | <geekosaur> | only GHC.Exts is considered "safe" |
| 2022-09-03 00:50:54 +0200 | <fhn> | Good to know. Thank you! |
| 2022-09-03 00:52:40 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-09-03 00:53:02 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-09-03 00:55:50 +0200 | <geekosaur> | sorry for misleading you, I used hoogle but didn't notice it was pointing me at an internals module 😕 |
| 2022-09-03 00:59:58 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-09-03 01:00:46 +0200 | Successus | (~Successus@user/Successus) () |
| 2022-09-03 01:05:36 +0200 | <fhn> | No worries. Appreciate suggesting runSTArray. If other beginners are wondering how to use it this is a minimal example: |
| 2022-09-03 01:05:38 +0200 | <fhn> | Data.Array.ST.runSTArray (do arr <- Data.Array.ST.newArray (0, 3) "empty"; return arr) |
| 2022-09-03 01:05:56 +0200 | <fhn> | Should return: array (0,3) [(0,"empty"),(1,"empty"),(2,"empty"),(3,"empty")] |
| 2022-09-03 01:06:16 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-03 01:13:11 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 2022-09-03 01:16:22 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 01:16:25 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: Leaving) |
| 2022-09-03 01:21:51 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) (Ping timeout: 244 seconds) |
| 2022-09-03 01:29:33 +0200 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2022-09-03 01:30:43 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 01:32:26 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) |
| 2022-09-03 01:33:24 +0200 | ix | (~ix@2a02:8010:674f:0:d65d:64ff:fe52:5efe) (Read error: Connection reset by peer) |
| 2022-09-03 01:34:18 +0200 | ix | (~ix@2a02:8010:674f:0:d65d:64ff:fe52:5efe) |
| 2022-09-03 01:35:11 +0200 | `2jt | (~jtomas@56.red-88-17-82.dynamicip.rima-tde.net) (Ping timeout: 252 seconds) |
| 2022-09-03 01:37:52 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-03 01:39:02 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 2022-09-03 01:46:26 +0200 | pavonia | (~user@user/siracusa) |
| 2022-09-03 01:50:13 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 01:50:52 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 01:53:39 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 01:59:41 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-09-03 01:59:47 +0200 | rref | (~moe@cpc110681-lewi19-2-0-cust485.2-4.cable.virginm.net) |
| 2022-09-03 01:59:48 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-09-03 01:59:48 +0200 | finn_elija | FinnElija |
| 2022-09-03 02:01:25 +0200 | rref | (~moe@cpc110681-lewi19-2-0-cust485.2-4.cable.virginm.net) (Client Quit) |
| 2022-09-03 02:02:57 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-09-03 02:04:48 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 02:15:09 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-09-03 02:15:27 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 02:21:53 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds) |
| 2022-09-03 02:23:43 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 268 seconds) |
| 2022-09-03 02:24:32 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-09-03 02:32:07 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-09-03 02:34:23 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-09-03 02:35:41 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 02:37:17 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 244 seconds) |
| 2022-09-03 02:43:39 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 02:45:06 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 02:46:55 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 02:53:30 +0200 | OscarZ | (~oscarz@95.175.104.83) (Ping timeout: 264 seconds) |
| 2022-09-03 02:59:43 +0200 | razetime | (~quassel@117.254.34.255) |
| 2022-09-03 03:11:54 +0200 | razetime | (~quassel@117.254.34.255) (Ping timeout: 244 seconds) |
| 2022-09-03 03:12:51 +0200 | razetime | (~quassel@117.193.6.155) |
| 2022-09-03 03:13:47 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 03:14:35 +0200 | <SrPx> | https://github.com/Kindelia/Functional-Benchmarks !! |
| 2022-09-03 03:18:13 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds) |
| 2022-09-03 03:18:13 +0200 | razetime | (~quassel@117.193.6.155) (Read error: Connection reset by peer) |
| 2022-09-03 03:21:03 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-09-03 03:22:40 +0200 | razetime | (~quassel@117.254.35.60) |
| 2022-09-03 03:22:55 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 268 seconds) |
| 2022-09-03 03:25:14 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-09-03 03:27:43 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2022-09-03 03:27:59 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) |
| 2022-09-03 03:36:25 +0200 | nilradical | (~nilradica@user/naso) (Remote host closed the connection) |
| 2022-09-03 03:36:37 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 268 seconds) |
| 2022-09-03 03:37:12 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 03:37:35 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 03:38:34 +0200 | nilradical | (~nilradica@user/naso) (Remote host closed the connection) |
| 2022-09-03 03:38:58 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 03:44:03 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 03:47:45 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-09-03 03:51:35 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-09-03 03:56:52 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 244 seconds) |
| 2022-09-03 04:05:32 +0200 | jargon | (~jargon@184.101.185.66) (Remote host closed the connection) |
| 2022-09-03 04:05:38 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 04:09:55 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds) |
| 2022-09-03 04:17:27 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 04:24:18 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2022-09-03 04:25:14 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-09-03 04:25:40 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-09-03 04:27:16 +0200 | jargon | (~jargon@184.101.185.66) |
| 2022-09-03 04:28:56 +0200 | nilradical | (~nilradica@user/naso) (Remote host closed the connection) |
| 2022-09-03 04:29:43 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 04:33:03 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2022-09-03 04:34:21 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-09-03 04:36:39 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-03 04:39:44 +0200 | razetime | (~quassel@117.254.35.60) (Ping timeout: 244 seconds) |
| 2022-09-03 04:41:22 +0200 | xff0x | (~xff0x@2405:6580:b080:900:e333:df19:b280:4b33) (Ping timeout: 268 seconds) |
| 2022-09-03 04:41:48 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-03 04:42:36 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-09-03 04:42:44 +0200 | razetime | (~quassel@117.193.3.170) |
| 2022-09-03 04:43:04 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 268 seconds) |
| 2022-09-03 04:43:41 +0200 | td_ | (~td@94.134.91.208) (Ping timeout: 268 seconds) |
| 2022-09-03 04:44:28 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-09-03 04:45:05 +0200 | mzan | (~quassel@mail.asterisell.com) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-03 04:45:14 +0200 | td_ | (~td@muedsl-82-207-238-133.citykom.de) |
| 2022-09-03 04:46:10 +0200 | mzan | (~quassel@mail.asterisell.com) |
| 2022-09-03 04:49:34 +0200 | glguy | (x@libera/staff-emeritus/glguy) (Read error: Connection reset by peer) |
| 2022-09-03 04:50:02 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 258 seconds) |
| 2022-09-03 04:50:35 +0200 | razetime | (~quassel@117.193.3.170) (Ping timeout: 244 seconds) |
| 2022-09-03 04:50:51 +0200 | razetime | (~quassel@2401:4900:234b:1cfb:d8:711a:a29e:7017) |
| 2022-09-03 04:51:19 +0200 | qhong_ | qhong |
| 2022-09-03 04:51:42 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-09-03 04:51:50 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 04:52:06 +0200 | glguy | (x@libera/staff-emeritus/glguy) |
| 2022-09-03 04:52:40 +0200 | ix | (~ix@2a02:8010:674f:0:d65d:64ff:fe52:5efe) (Ping timeout: 244 seconds) |
| 2022-09-03 04:52:45 +0200 | nilradical | (~nilradica@user/naso) (Client Quit) |
| 2022-09-03 04:53:06 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-09-03 04:53:06 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-09-03 04:53:06 +0200 | finn_elija | FinnElija |
| 2022-09-03 04:55:17 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 04:56:15 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 2022-09-03 04:56:23 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) |
| 2022-09-03 04:56:47 +0200 | glguy | (x@libera/staff-emeritus/glguy) (Ping timeout: 244 seconds) |
| 2022-09-03 04:56:48 +0200 | aeka | (~aeka@pool-96-233-77-78.bstnma.fios.verizon.net) (Ping timeout: 244 seconds) |
| 2022-09-03 04:59:49 +0200 | glguy | (x@libera/staff-emeritus/glguy) |
| 2022-09-03 04:59:51 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 05:01:22 +0200 | aeka | (~aeka@user/hiruji) |
| 2022-09-03 05:02:06 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 05:04:44 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-09-03 05:05:54 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-09-03 05:06:08 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-09-03 05:06:28 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-03 05:06:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 05:07:09 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-09-03 05:08:00 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-09-03 05:08:23 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-03 05:14:21 +0200 | aeka | (~aeka@user/hiruji) (Ping timeout: 244 seconds) |
| 2022-09-03 05:21:13 +0200 | raym | (~raym@user/raym) (Remote host closed the connection) |
| 2022-09-03 05:22:09 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2022-09-03 05:24:19 +0200 | _xor | (~xor@74.215.182.83) |
| 2022-09-03 05:24:55 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 258 seconds) |
| 2022-09-03 05:25:02 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds) |
| 2022-09-03 05:32:03 +0200 | bilegeek | (~bilegeek@2600:1008:b041:e5e8:7ca6:51d9:f9b4:708b) |
| 2022-09-03 05:34:21 +0200 | xff0x | (~xff0x@2405:6580:b080:900:e333:df19:b280:4b33) |
| 2022-09-03 05:35:32 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 05:36:00 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-09-03 05:36:08 +0200 | odnes | (~odnes@5-203-166-239.pat.nym.cosmote.net) |
| 2022-09-03 05:36:13 +0200 | odnes | (~odnes@5-203-166-239.pat.nym.cosmote.net) (Remote host closed the connection) |
| 2022-09-03 05:37:27 +0200 | zebrag | (~chris@user/zebrag) (Client Quit) |
| 2022-09-03 05:38:45 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-09-03 05:43:10 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-09-03 05:43:36 +0200 | zebrag | (~chris@user/zebrag) (Client Quit) |
| 2022-09-03 05:45:10 +0200 | notzmv | (~zmv@user/notzmv) |
| 2022-09-03 05:47:26 +0200 | jargon | (~jargon@184.101.185.66) (Remote host closed the connection) |
| 2022-09-03 05:48:02 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 05:52:09 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-09-03 05:53:28 +0200 | zebrag | (~chris@user/zebrag) (Client Quit) |
| 2022-09-03 05:54:34 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-09-03 06:07:52 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-09-03 06:07:54 +0200 | raym | (~raym@user/raym) |
| 2022-09-03 06:08:45 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 06:11:01 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 06:19:43 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 06:21:55 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 06:28:10 +0200 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2022-09-03 06:28:45 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 06:34:14 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-09-03 06:44:35 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-09-03 06:45:17 +0200 | vglfr | (~vglfr@145.224.94.248) (Ping timeout: 244 seconds) |
| 2022-09-03 06:48:15 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 268 seconds) |
| 2022-09-03 06:52:00 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 244 seconds) |
| 2022-09-03 06:52:36 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds) |
| 2022-09-03 06:54:31 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 07:04:32 +0200 | vglfr | (~vglfr@145.224.94.248) |
| 2022-09-03 07:06:39 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-03 07:11:22 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-03 07:14:24 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) (Quit: Leaving) |
| 2022-09-03 07:17:52 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-09-03 07:18:29 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 07:21:13 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) |
| 2022-09-03 07:21:45 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 07:24:00 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-09-03 07:24:29 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-09-03 07:24:33 +0200 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-09-03 07:31:12 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-09-03 07:31:50 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-09-03 07:34:19 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 07:40:19 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-09-03 07:42:36 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 07:42:38 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 244 seconds) |
| 2022-09-03 07:44:05 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-09-03 07:44:23 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-09-03 07:44:37 +0200 | Guest6348 | (~owsley@pool-100-11-18-203.phlapa.fios.verizon.net) |
| 2022-09-03 07:45:32 +0200 | Guest6348 | (~owsley@pool-100-11-18-203.phlapa.fios.verizon.net) (Changing host) |
| 2022-09-03 07:45:32 +0200 | Guest6348 | (~owsley@user/polo) |
| 2022-09-03 07:46:04 +0200 | Guest6348 | (~owsley@user/polo) (Client Quit) |
| 2022-09-03 07:47:17 +0200 | razetime | (~quassel@2401:4900:234b:1cfb:d8:711a:a29e:7017) (Ping timeout: 244 seconds) |
| 2022-09-03 07:47:37 +0200 | razetime | (~quassel@117.254.35.99) |
| 2022-09-03 07:48:06 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 264 seconds) |
| 2022-09-03 07:50:10 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 07:52:06 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2022-09-03 07:53:35 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 07:57:37 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 244 seconds) |
| 2022-09-03 07:57:38 +0200 | jinsun | (~jinsun@user/jinsun) (Ping timeout: 244 seconds) |
| 2022-09-03 07:58:21 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (Quit: WeeChat 3.6) |
| 2022-09-03 07:58:42 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-09-03 08:00:40 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 08:01:20 +0200 | soumen | (~soumen@58.182.45.203) (Quit: Konversation terminated!) |
| 2022-09-03 08:01:39 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 08:03:42 +0200 | soumen | (~soumen@58.182.45.203) |
| 2022-09-03 08:03:47 +0200 | poscat | (~poscat@114.245.110.105) |
| 2022-09-03 08:04:41 +0200 | poscat0x04 | (~poscat@114.245.109.80) (Ping timeout: 255 seconds) |
| 2022-09-03 08:05:41 +0200 | razetime | (~quassel@117.254.35.99) (Ping timeout: 252 seconds) |
| 2022-09-03 08:05:57 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-09-03 08:06:16 +0200 | razetime | (~quassel@117.254.34.183) |
| 2022-09-03 08:06:22 +0200 | soumen | (~soumen@58.182.45.203) (Client Quit) |
| 2022-09-03 08:07:57 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-09-03 08:08:22 +0200 | soumen | (~soumen@58.182.45.203) |
| 2022-09-03 08:10:45 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-09-03 08:12:50 +0200 | Linux | Unix |
| 2022-09-03 08:16:26 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 268 seconds) |
| 2022-09-03 08:18:58 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 08:23:50 +0200 | razetime | (~quassel@117.254.34.183) (Ping timeout: 268 seconds) |
| 2022-09-03 08:24:19 +0200 | razetime | (~quassel@117.193.4.200) |
| 2022-09-03 08:28:10 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 08:28:25 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 08:31:01 +0200 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-09-03 08:33:05 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-09-03 08:33:11 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-03 08:34:49 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 244 seconds) |
| 2022-09-03 08:34:51 +0200 | hgolden | (~Howard@cpe-172-251-233-141.socal.res.rr.com) (Remote host closed the connection) |
| 2022-09-03 08:35:02 +0200 | mikoto-chan | (~mikoto-ch@85-76-3-93-nat.elisa-mobile.fi) |
| 2022-09-03 08:36:55 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-09-03 08:37:39 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-09-03 08:39:12 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-09-03 08:40:43 +0200 | paddymahoney | (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) |
| 2022-09-03 08:43:20 +0200 | bilegeek | (~bilegeek@2600:1008:b041:e5e8:7ca6:51d9:f9b4:708b) (Quit: Leaving) |
| 2022-09-03 08:44:38 +0200 | razetime | (~quassel@117.193.4.200) (Ping timeout: 244 seconds) |
| 2022-09-03 08:45:12 +0200 | razetime | (~quassel@117.254.34.232) |
| 2022-09-03 08:47:52 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2230878ffc93dd9ace.dip0.t-ipconnect.de) |
| 2022-09-03 08:50:06 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 08:51:28 +0200 | Unix | UNIX |
| 2022-09-03 08:51:58 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-09-03 08:52:32 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) |
| 2022-09-03 08:56:03 +0200 | razetime | (~quassel@117.254.34.232) (Ping timeout: 248 seconds) |
| 2022-09-03 08:59:33 +0200 | MoC | (~moc@user/moc) |
| 2022-09-03 09:01:53 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 09:04:20 +0200 | <Franciman> | thanks SrPx for bringing us light |
| 2022-09-03 09:05:26 +0200 | <Franciman> | make us dream. This is ultimately, what makes us stay alive |
| 2022-09-03 09:06:20 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 244 seconds) |
| 2022-09-03 09:09:07 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 09:14:21 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 09:14:31 +0200 | razetime | (~quassel@117.254.34.180) |
| 2022-09-03 09:15:43 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 252 seconds) |
| 2022-09-03 09:17:02 +0200 | <[exa]> | is there finally a good description of what HVM actually does? |
| 2022-09-03 09:19:17 +0200 | <Franciman> | there always was i suppose? |
| 2022-09-03 09:19:37 +0200 | <Franciman> | implement optimal \beta-reduction, last i checked, was the goal |
| 2022-09-03 09:21:35 +0200 | <Franciman> | https://github.com/kindelia/hvm#high-order-virtual-machine-hvm |
| 2022-09-03 09:23:20 +0200 | <[exa]> | the HOW.md is kinda chaotic tbh, was hoping for something more rigorous finally |
| 2022-09-03 09:23:56 +0200 | <Franciman> | https://www.academia.edu/79625586/Linear_Logic_Comonads_and_Optimal_Reductions this was a nice paper i was reading |
| 2022-09-03 09:24:09 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 09:24:13 +0200 | <Franciman> | [related to the subject, not strictly to HVM] |
| 2022-09-03 09:26:04 +0200 | <[exa]> | we've seen quite a few such magical approaches in past 20 years and all were subject to TAINSTAAFL |
| 2022-09-03 09:26:16 +0200 | <Franciman> | what does it mean? |
| 2022-09-03 09:26:43 +0200 | <Franciman> | that you perform benchmarks on accurately picked example so that you are faster than everyone? |
| 2022-09-03 09:27:07 +0200 | <Franciman> | ah |
| 2022-09-03 09:27:09 +0200 | <Franciman> | ok |
| 2022-09-03 09:27:11 +0200 | <Franciman> | https://it.wikipedia.org/wiki/TANSTAAFL |
| 2022-09-03 09:27:57 +0200 | <Franciman> | ops |
| 2022-09-03 09:28:03 +0200 | <Franciman> | https://en.wikipedia.org/wiki/There_ain%27t_no_such_thing_as_a_free_lunch |
| 2022-09-03 09:29:30 +0200 | <Franciman> | the thing is [exa], that you can work in the worst case as GHC |
| 2022-09-03 09:29:46 +0200 | <Franciman> | and then, in the case of pure lambda functions, you apply HVM optimal reduction operations |
| 2022-09-03 09:29:52 +0200 | <Franciman> | and get speed |
| 2022-09-03 09:30:20 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) (Quit: Leaving.) |
| 2022-09-03 09:31:39 +0200 | <Franciman> | so the no free lunch would be that you don't get all the time this extra speed |
| 2022-09-03 09:31:50 +0200 | <Franciman> | and you could equally effectively use ghc, with all its libs |
| 2022-09-03 09:31:55 +0200 | <Franciman> | but who knows |
| 2022-09-03 09:33:01 +0200 | <Franciman> | ofc haskellers would be wary of HVM |
| 2022-09-03 09:33:04 +0200 | <Franciman> | it's only natural |
| 2022-09-03 09:35:21 +0200 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (Quit: WeeChat 3.6) |
| 2022-09-03 09:35:59 +0200 | mikoto-chan | (~mikoto-ch@85-76-3-93-nat.elisa-mobile.fi) (Ping timeout: 268 seconds) |
| 2022-09-03 09:37:35 +0200 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2022-09-03 09:37:57 +0200 | toeffel | (~toeffel@user/toeffel) |
| 2022-09-03 09:38:38 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 09:39:34 +0200 | <[exa]> | Franciman: it's probably good and I'm not contradicting that it _is_ super good and fast, it's just fishy. Which is not supported by various ad-hoc explanations in the commentary such as https://github.com/Kindelia/HVM/blob/master/src/runtime.c#L365 |
| 2022-09-03 09:40:04 +0200 | <maerwald[m]> | Yeah, it's threatening to GHC ;) |
| 2022-09-03 09:40:11 +0200 | <Franciman> | make sense |
| 2022-09-03 09:40:13 +0200 | <Franciman> | makes |
| 2022-09-03 09:40:27 +0200 | <Franciman> | ghc il threatened by its bloat more than HVM lol |
| 2022-09-03 09:40:36 +0200 | <[exa]> | the natural question is "did the authors really explore everything that could go wrong?" and the answer is "no proof available" now |
| 2022-09-03 09:40:47 +0200 | Franciman | nods |
| 2022-09-03 09:41:47 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 09:41:55 +0200 | <[exa]> | I'm perfectly okay with whatever current compiler going away if the replacement is somehow better or so, but before one starts destroying the established methods it is very useful to know the work won't be doomed by insufficient prior analysis |
| 2022-09-03 09:42:47 +0200 | <[exa]> | the authors in hvm should invest in explaining the whole concept in a way that can be verified, preferably without screaming "hahaha we pwned ghc!!!1111" at every corner |
| 2022-09-03 09:43:37 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 09:46:09 +0200 | <[exa]> | Franciman: btw you're somehow related to the project? it would be really useful to explain how `subst()` and `link()` from the runtime.c works in the how-to |
| 2022-09-03 09:46:14 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 09:46:41 +0200 | <Franciman> | sorry, i am not |
| 2022-09-03 09:47:00 +0200 | <Franciman> | i agree with all your observations |
| 2022-09-03 09:47:24 +0200 | <[exa]> | so hopefully anyone from the HVM peeps will read haskelllogs and see this :D |
| 2022-09-03 09:47:39 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-09-03 09:47:41 +0200 | <Franciman> | i've been reading something about optimal evaluation, that's all lolz |
| 2022-09-03 09:48:07 +0200 | <Franciman> | the no free lunch wrt optimal evaluation, seems to me that can be reduced by using a purity check and applying mixed evaluation strategies |
| 2022-09-03 09:48:40 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-09-03 09:49:17 +0200 | <[exa]> | is it still provably optimal then? |
| 2022-09-03 09:50:07 +0200 | <Franciman> | does it make sense to apply optimal evaluation to impure code? |
| 2022-09-03 09:50:33 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-09-03 09:50:37 +0200 | <Franciman> | like laziness, it requires you manually encode the order of evaluation |
| 2022-09-03 09:50:43 +0200 | <Franciman> | using the State Monad |
| 2022-09-03 09:50:50 +0200 | <Franciman> | cps etc |
| 2022-09-03 09:51:34 +0200 | <Franciman> | so you have to actively fight against the evaluation system, to make it listen to you lol |
| 2022-09-03 10:00:08 +0200 | hrberg | (~quassel@171.79-160-161.customer.lyse.net) |
| 2022-09-03 10:00:09 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 10:00:34 +0200 | causal | (~user@50.35.83.177) (Quit: WeeChat 3.6) |
| 2022-09-03 10:07:42 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 10:08:57 +0200 | <nilradical> | when doing "+s print timing/memory stats after each evaluation" in ghci, what does the displayed memory amount mean? |
| 2022-09-03 10:09:22 +0200 | <nilradical> | i do a computation and it said 8,622,559,104 bytes , but in my activity monitor it says ghc is only using about 300 MB |
| 2022-09-03 10:11:54 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 10:15:10 +0200 | <analoq> | im trying to figure out how to get this snipped to work https://dpaste.com/ATS8X5A7A.txt It works fine when i change the function type to IO() and print the data instead of returning it |
| 2022-09-03 10:15:11 +0200 | poscat | (~poscat@114.245.110.105) (Quit: Bye) |
| 2022-09-03 10:16:07 +0200 | <analoq> | I assume my issue is that due to BS.readFile returning an IO ByteString it isn't pure. so the solution should be to convert IO ByteString to ByteString? |
| 2022-09-03 10:16:28 +0200 | <[exa]> | analoq: `decode` is from what package? |
| 2022-09-03 10:16:34 +0200 | <analoq> | aeson |
| 2022-09-03 10:16:40 +0200 | <[exa]> | ah. |
| 2022-09-03 10:16:57 +0200 | <analoq> | that part works. it's tricky to give a working sample due to the fact that im reading a file |
| 2022-09-03 10:17:27 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 10:17:32 +0200 | <[exa]> | analoq: add a return "return $" before the case |
| 2022-09-03 10:17:49 +0200 | <[exa]> | you can't return "pure" data from an IO action, but need something to carry the IO along |
| 2022-09-03 10:17:53 +0200 | <[exa]> | `return` does that |
| 2022-09-03 10:18:10 +0200 | poscat | (~poscat@114.245.106.91) |
| 2022-09-03 10:18:18 +0200 | <[exa]> | accordingly, the type of import_db should be FilePath -> IO [Task] |
| 2022-09-03 10:18:20 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-09-03 10:20:00 +0200 | <[exa]> | re "converting IO ByteString to ByteString" -- you can't really *convert* it because it is "tainted" by communication with external environment, but you can easily defer this communication with external environment to a larger scope and play with the inner ByteString locally |
| 2022-09-03 10:21:07 +0200 | <analoq> | [exa]: I thought i could either return [] if it fails or the actual result if it succeeds. Doesn't that remove the uncertainty? |
| 2022-09-03 10:21:19 +0200 | <[exa]> | which is precisely what `x <- someIOaction` does -- if someIOaction has type `IO value`, you get `x :: value`, but the environment must be of type `IO something` so that the IO actions do not "disappear" |
| 2022-09-03 10:21:52 +0200 | <analoq> | so as soon as IO happens inside a function the function needs to return IO .... ? |
| 2022-09-03 10:22:41 +0200 | <[exa]> | analoq: it is not about uncertainty but about evaluation order. the "Returning IO" can be seen as a mark for the runtime that the functions can't be evaluated in whatever order |
| 2022-09-03 10:23:18 +0200 | <[exa]> | (i.e., without IO the runtime is perfectly free to read your file after exiting the program, because it's sure that the exit always happens) |
| 2022-09-03 10:23:28 +0200 | <analoq> | i see. that makes sense |
| 2022-09-03 10:23:29 +0200 | <[exa]> | (haha) |
| 2022-09-03 10:24:01 +0200 | <[exa]> | anyway, yes -- basically all functions that do some kind of IO get the `IO something` return type, which is kinda annoying at first but there are good tools to cope with that |
| 2022-09-03 10:24:05 +0200 | poscat | (~poscat@114.245.106.91) (Quit: Bye) |
| 2022-09-03 10:24:24 +0200 | kitty4 | (~kitty@096-039-147-043.res.spectrum.com) |
| 2022-09-03 10:25:54 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-09-03 10:26:10 +0200 | <[exa]> | in a bigger view, you can view values of type `IO something` as a description of sequential runtime behavior that your program is doing to produce the `something`, and the program is a big description of that behavior which is `main :: IO ()` |
| 2022-09-03 10:28:00 +0200 | <[exa]> | anyway |
| 2022-09-03 10:28:07 +0200 | poscat | (~poscat@2408:8206:4823:a05:4aaa:cd6a:209f:4edd) |
| 2022-09-03 10:29:13 +0200 | <[exa]> | you should eventually be able to get rid of the `:: Maybe [Task]` annotation in the middle of that function because ghc should be able to see that it should indeed return the same type as what the function should produce |
| 2022-09-03 10:30:04 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) |
| 2022-09-03 10:30:11 +0200 | <[exa]> | and a few nice tools to reduce the complexity of the IO functions: |
| 2022-09-03 10:30:26 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 10:30:45 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 10:31:41 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2022-09-03 10:31:50 +0200 | <[exa]> | 1] you can write stuff like `lineLength <- length <$> getLine` -- the operator (which is fmap) applies a pure function into the IO action |
| 2022-09-03 10:32:01 +0200 | <[exa]> | in your case it may be handy to do this with decode |
| 2022-09-03 10:34:20 +0200 | <[exa]> | and 2] there are tons of tiny helper functions to prevent you from writing ifs and cases yourself. `case x of {Nothing -> []; Just x -> x}` should be equivalent to `maybe [] id x` or `fromMaybe [] x` (but that's not directly in Prelude) |
| 2022-09-03 10:34:53 +0200 | <analoq> | yeah there's a lot of stuff. usually i write a long solution only to realize there was a one liner for it afterwards >.> |
| 2022-09-03 10:35:12 +0200 | <[exa]> | that's the haskell way tbh, I'm doing the same |
| 2022-09-03 10:35:39 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-03 10:35:52 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 10:35:59 +0200 | <[exa]> | high-level concepts are rarely apparent before seeing a working example |
| 2022-09-03 10:36:26 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-09-03 10:37:06 +0200 | <analoq> | regarding your earlier fmap recommendation. you mean something like json <- decode <$> BS.readFile x :: Maybe [Task]? |
| 2022-09-03 10:38:31 +0200 | analoq | is out of his comfort zone :D |
| 2022-09-03 10:39:31 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2230878ffc93dd9ace.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-09-03 10:40:53 +0200 | <c_wraith> | there probably needs to be an IO in that type |
| 2022-09-03 10:43:17 +0200 | <analoq> | IO( Maybe [Task]) appears to work |
| 2022-09-03 10:43:32 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 10:43:35 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 10:43:39 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-09-03 10:47:29 +0200 | <[exa]> | analoq: yeah, the thing on the right side of <- is the description of an IO action |
| 2022-09-03 10:47:39 +0200 | <analoq> | the thing is the compiler considers `Just x -> x` to be [Task] and not IO [Task], while `Nothing -> []` is considered to be [[Task]] (which i totally not understand, how can an empty list be considered to be a list of lists?) |
| 2022-09-03 10:47:45 +0200 | <analoq> | https://dpaste.com/2LER588NW.txt |
| 2022-09-03 10:47:51 +0200 | poscat | (~poscat@2408:8206:4823:a05:4aaa:cd6a:209f:4edd) (Quit: Bye) |
| 2022-09-03 10:48:14 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-09-03 10:48:29 +0200 | <[exa]> | analoq: it is trying to find a monad that would match your return type there, [] is one choice |
| 2022-09-03 10:49:11 +0200 | <[exa]> | as a quick fix, just add the returns: `Nothing -> return []` and `Just x -> return x` |
| 2022-09-03 10:49:53 +0200 | <[exa]> | return takes a plain value and makes an IO action of it, allowing you to use that value in a larger IO computation |
| 2022-09-03 10:51:05 +0200 | nilradical | (~nilradica@user/naso) (Remote host closed the connection) |
| 2022-09-03 10:51:47 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 10:52:31 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-09-03 10:53:28 +0200 | poscat | (~poscat@114.245.109.13) |
| 2022-09-03 10:56:54 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 244 seconds) |
| 2022-09-03 10:58:01 +0200 | <[exa]> | analoq: btw if you are unsure about types, you can always place a _ to any part in the program to see what Haskell thinks should be the type there |
| 2022-09-03 11:01:07 +0200 | <analoq> | [exa]: as in replace the 'variable' with a '_'? |
| 2022-09-03 11:01:23 +0200 | <analoq> | at least that seems to print some helpful information |
| 2022-09-03 11:02:37 +0200 | poscat | (~poscat@114.245.109.13) (Quit: Bye) |
| 2022-09-03 11:03:10 +0200 | <[exa]> | yes like that... replacing the first guess with _ kinda avoids confusing the typesystem with possible mistakes in my first guess |
| 2022-09-03 11:04:10 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-09-03 11:04:23 +0200 | <analoq> | nice feature. I also realized i have no idea what 'return' actually does :D |
| 2022-09-03 11:04:35 +0200 | <[exa]> | you can see it as a counterpart to <- |
| 2022-09-03 11:05:23 +0200 | poscat | (~poscat@2408:8206:4823:d0a:777d:33d3:a29b:a4b6) |
| 2022-09-03 11:06:49 +0200 | <[exa]> | very allegorically -- `x <- something` temporarily unwraps whatever impurity in `something` giving you a pure `x` to play with; and `return x` attaches some impurity annotation to a pure `x` so that it can be connected to the other "impure" stuff by the do notation |
| 2022-09-03 11:07:14 +0200 | <[exa]> | :t return |
| 2022-09-03 11:07:15 +0200 | <lambdabot> | Monad m => a -> m a |
| 2022-09-03 11:07:24 +0200 | <[exa]> | in our case it is `a -> IO a` |
| 2022-09-03 11:07:46 +0200 | <[exa]> | `<-` is a syntax sugar for something else though |
| 2022-09-03 11:07:52 +0200 | <[exa]> | :t (>>=) |
| 2022-09-03 11:07:53 +0200 | <lambdabot> | Monad m => m a -> (a -> m b) -> m b |
| 2022-09-03 11:07:53 +0200 | <analoq> | so return snatches the `m` from the -> IO [Task]? |
| 2022-09-03 11:08:37 +0200 | <[exa]> | yes, the type system infers which kind of "wrap" it needs there, so that it correctly uses IO |
| 2022-09-03 11:08:53 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 11:09:18 +0200 | <analoq> | i see. so of I were to manually cast the type I wouldnt have to use return? |
| 2022-09-03 11:09:29 +0200 | <analoq> | s/of/if |
| 2022-09-03 11:09:44 +0200 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) (Remote host closed the connection) |
| 2022-09-03 11:09:56 +0200 | <[exa]> | well if you could construct IO values manually, you could. there's no "casting" though. |
| 2022-09-03 11:10:53 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 11:11:00 +0200 | <analoq> | it feels like learning haskell is a lifetime job :P |
| 2022-09-03 11:11:15 +0200 | <[exa]> | nah you're in like 50% of the initial shock, after that it's okay |
| 2022-09-03 11:11:17 +0200 | <analoq> | or im just handicapped who knows~ |
| 2022-09-03 11:11:31 +0200 | <[exa]> | monads are mind-bending before you get kinda used to them |
| 2022-09-03 11:12:22 +0200 | <analoq> | i've stopped trying to understand them on a mathematical level. i just view them as Rusts option type |
| 2022-09-03 11:13:07 +0200 | <[exa]> | ah well, that is one example of monadic thing, yes |
| 2022-09-03 11:13:53 +0200 | <[exa]> | actually, let's try something |
| 2022-09-03 11:14:01 +0200 | <analoq> | i watched multiple videos on haskell monads, didnt understand it. Rusts options are self explaining and they seem to behave just like haskells monads idk :/ |
| 2022-09-03 11:14:38 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 11:14:44 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 11:15:15 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 248 seconds) |
| 2022-09-03 11:15:28 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation (Just 3) (Just 4) |
| 2022-09-03 11:15:30 +0200 | <lambdabot> | Just 15 |
| 2022-09-03 11:15:31 +0200 | <[exa]> | Just 15 |
| 2022-09-03 11:15:55 +0200 | barrucadu | (~barrucadu@carcosa.barrucadu.co.uk) |
| 2022-09-03 11:15:57 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2230878ffc93dd9ace.dip0.t-ipconnect.de) |
| 2022-09-03 11:15:58 +0200 | <[exa]> | this is how you use monads to work with option-like values ^ |
| 2022-09-03 11:16:11 +0200 | odnes | (~odnes@5-203-166-239.pat.nym.cosmote.net) |
| 2022-09-03 11:18:09 +0200 | <[exa]> | you don't see any maybe-ing in `myMonadicComputation`, but the function will correctly short-circuit once some of the values get missing (None in rust, Nothing in haskell): |
| 2022-09-03 11:18:18 +0200 | <analoq> | whats the purpose of using 2 arguments? |
| 2022-09-03 11:18:30 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation (Just 3) (Nothing) |
| 2022-09-03 11:18:33 +0200 | <lambdabot> | Nothing |
| 2022-09-03 11:18:39 +0200 | <[exa]> | not much, just for demonstration |
| 2022-09-03 11:19:07 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 244 seconds) |
| 2022-09-03 11:19:22 +0200 | <analoq> | i see that one was better |
| 2022-09-03 11:19:31 +0200 | <[exa]> | and there are many different monads, with many different ways how the "extra information" in the wrapper gets connected together |
| 2022-09-03 11:19:41 +0200 | <analoq> | so it does the math, while maintaining the monad |
| 2022-09-03 11:20:03 +0200 | <[exa]> | yes. for example, Either does a slightly more complicated short-circuiting (Right values are "okay", Left values represent "errors") |
| 2022-09-03 11:20:12 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation (Right 3) (Right 4) |
| 2022-09-03 11:20:15 +0200 | <lambdabot> | Right 15 |
| 2022-09-03 11:20:29 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation (Left "Whoops an error!") (Right 4) |
| 2022-09-03 11:20:31 +0200 | <lambdabot> | Left "Whoops an error!" |
| 2022-09-03 11:21:08 +0200 | <[exa]> | lists represent programs that can produce more than one solution (say non-determinism): |
| 2022-09-03 11:21:23 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation [1,2] [10,20] |
| 2022-09-03 11:21:25 +0200 | <lambdabot> | [11,21,22,42] |
| 2022-09-03 11:21:42 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation [3] [4] |
| 2022-09-03 11:21:44 +0200 | <lambdabot> | [15] |
| 2022-09-03 11:21:59 +0200 | <[exa]> | (no non-determinism in that example ^) |
| 2022-09-03 11:22:08 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation [1,2,3] [] |
| 2022-09-03 11:22:09 +0200 | <lambdabot> | [] |
| 2022-09-03 11:22:19 +0200 | <[exa]> | (empty list means "no choices" ^) |
| 2022-09-03 11:22:48 +0200 | neceve | (~quassel@2.26.93.14) |
| 2022-09-03 11:23:53 +0200 | <analoq> | that was helpful. ty |
| 2022-09-03 11:24:10 +0200 | <[exa]> | IO is not different -- the actual IO value stores a function of type that looks a bit like `RealWorld -> (RealWorld, someresult)` -- it gets some state of a computer, possibly changes it a bit, and may also produce a pure value in the process as a side output (e.g., a string that was read) |
| 2022-09-03 11:24:45 +0200 | <[exa]> | and the IO monad literally just allows you to chain this thing reasonably without shooting yourself into the foot by forgetting the RealWorld somewhere (or cloning it!) |
| 2022-09-03 11:25:06 +0200 | <[exa]> | it won't work with lambdabot but you can try `myMonadicComputation readLn readLn` |
| 2022-09-03 11:26:01 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds) |
| 2022-09-03 11:26:54 +0200 | <[exa]> | (technically, if you had access to the internals, you could reconstruct the IO return very roughly as: `return a = \realworld -> (realworld,a)` ) |
| 2022-09-03 11:27:47 +0200 | _xor | (~xor@74.215.182.83) (Quit: WeeChat 3.6) |
| 2022-09-03 11:28:00 +0200 | <[exa]> | and as always there is a monad that just doesn't do anything except for the wrapping and unwrapping, which may be useful for learning purposes: |
| 2022-09-03 11:28:11 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation (Identity 3) (Identity 4) |
| 2022-09-03 11:28:13 +0200 | <lambdabot> | Identity 15 |
| 2022-09-03 11:28:53 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 11:28:55 +0200 | <[exa]> | and the whole purpose of `return` is that you don't need to remember what exact monad you're actually writing the code for -- you may notice that the `return` in myMonadicComputation actually created lots of different things without us changing a bit |
| 2022-09-03 11:29:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 11:29:56 +0200 | <[exa]> | which you can (thanks to inference) also use in outside code to simplify creating "trivial" wrapped values, for example: |
| 2022-09-03 11:30:10 +0200 | <[exa]> | > let myMonadicComputation a b = do { x <- a; y <- (+1) <$> b; return (x * y) } in myMonadicComputation [1,2,3] (return 10) |
| 2022-09-03 11:30:13 +0200 | <lambdabot> | [11,22,33] |
| 2022-09-03 11:30:37 +0200 | <[exa]> | here `return` correctly knows that it should create a single-possibility list |
| 2022-09-03 11:30:44 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2022-09-03 11:31:06 +0200 | <analoq> | it's amazing how seemingly everything works when you know what you are doing :D |
| 2022-09-03 11:31:47 +0200 | <[exa]> | like, I hope you have a bit of intuition now, once that is in place, chewing through the types and implementation details is much easier |
| 2022-09-03 11:32:06 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 11:32:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2022-09-03 11:32:35 +0200 | <[exa]> | try checking the types of everything in the demo code btw, that often helps (you can do (anything :: _) to get type info from ghc) |
| 2022-09-03 11:34:51 +0200 | <[exa]> | finally, a motivating compressed example: |
| 2022-09-03 11:34:54 +0200 | <[exa]> | > (*) <$> Just 3 <*> ((1+) <$> Just 4) |
| 2022-09-03 11:34:56 +0200 | <lambdabot> | Just 15 |
| 2022-09-03 11:35:57 +0200 | <[exa]> | (you can replace the justs like we did with anything that is able to behave monadically) |
| 2022-09-03 11:36:14 +0200 | <analoq> | that one is easy to understand |
| 2022-09-03 11:36:28 +0200 | <analoq> | at least i believe so :D |
| 2022-09-03 11:37:03 +0200 | <[exa]> | (actually I should have say applicatively, the typeclass police is watching... :D ) |
| 2022-09-03 11:37:49 +0200 | <[exa]> | you might wanna check State, that's a monad that literally keeps a stateful variable through the computation, which is helpful |
| 2022-09-03 11:39:24 +0200 | poscat | (~poscat@2408:8206:4823:d0a:777d:33d3:a29b:a4b6) (Quit: Bye) |
| 2022-09-03 11:40:18 +0200 | <[exa]> | anyway, the magic of monads in haskell is that you can write high-level combinators completely unaware of what is going to be the actual execution logic. Typically, you can print many values using `mapM print`, and mapM prints just as well for the nondeterminism and/or "optional" short-circuiting |
| 2022-09-03 11:41:34 +0200 | <[exa]> | s/prints/works/ |
| 2022-09-03 11:41:47 +0200 | poscat | (~poscat@114.245.110.14) |
| 2022-09-03 11:42:23 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 252 seconds) |
| 2022-09-03 11:43:52 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-09-03 11:44:16 +0200 | _xor | (~xor@74.215.182.83) |
| 2022-09-03 11:44:47 +0200 | <[exa]> | (...which eventually brings us to the main killer feature of haskell, which is monadic parsing) |
| 2022-09-03 11:47:20 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 11:48:36 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2022-09-03 11:48:42 +0200 | poscat | (~poscat@114.245.110.14) (Quit: Bye) |
| 2022-09-03 11:50:12 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 11:51:16 +0200 | poscat | (~poscat@2408:8206:4823:10b5:cd89:a947:c49f:4bc1) |
| 2022-09-03 11:51:34 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) |
| 2022-09-03 11:57:35 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 12:00:37 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 12:13:14 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-09-03 12:13:14 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2022-09-03 12:13:14 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2022-09-03 12:13:14 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-09-03 12:13:46 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-03 12:13:53 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-09-03 12:14:00 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-09-03 12:14:36 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-09-03 12:19:35 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-09-03 12:22:33 +0200 | acidjnk | (~acidjnk@p200300d6e7137a2230878ffc93dd9ace.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-09-03 12:24:44 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2022-09-03 12:25:54 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-09-03 12:30:12 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-09-03 12:32:36 +0200 | VictorHugenay | (~jh@user/VictorHugenay) |
| 2022-09-03 12:34:33 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 244 seconds) |
| 2022-09-03 12:35:15 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 248 seconds) |
| 2022-09-03 12:36:05 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-09-03 12:36:39 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-09-03 12:37:18 +0200 | VictorHugenay | (~jh@user/VictorHugenay) (Client Quit) |
| 2022-09-03 12:40:44 +0200 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-09-03 12:46:18 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 264 seconds) |
| 2022-09-03 12:48:58 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 12:50:30 +0200 | nilradical | (~nilradica@user/naso) () |
| 2022-09-03 12:52:23 +0200 | Successus | (~Successus@user/Successus) |
| 2022-09-03 12:53:13 +0200 | squiffs | (~squiffs@2a00:23c7:bb7a:9701:bcd9:126:695:8182) |
| 2022-09-03 12:53:16 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 12:53:40 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 244 seconds) |
| 2022-09-03 12:55:02 +0200 | fhn | (~fhn@2.58.185.24) (Ping timeout: 252 seconds) |
| 2022-09-03 12:55:12 +0200 | squiffs | (~squiffs@2a00:23c7:bb7a:9701:bcd9:126:695:8182) (Remote host closed the connection) |
| 2022-09-03 12:57:17 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 244 seconds) |
| 2022-09-03 12:58:54 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-09-03 13:01:25 +0200 | odnes | (~odnes@5-203-166-239.pat.nym.cosmote.net) (Ping timeout: 244 seconds) |
| 2022-09-03 13:16:24 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2022-09-03 13:40:20 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 13:40:21 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 13:44:51 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 13:54:13 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 13:56:42 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 244 seconds) |
| 2022-09-03 13:56:42 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-03 13:58:05 +0200 | fryguybob | (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) (Quit: leaving) |
| 2022-09-03 14:02:34 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 14:03:57 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 258 seconds) |
| 2022-09-03 14:05:00 +0200 | fryguybob | (~fryguybob@cpe-74-67-169-145.rochester.res.rr.com) |
| 2022-09-03 14:05:09 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-09-03 14:11:44 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-09-03 14:11:58 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-09-03 14:12:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 14:14:02 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-09-03 14:14:17 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 14:17:42 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-09-03 14:17:51 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 252 seconds) |
| 2022-09-03 14:19:10 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-09-03 14:19:29 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2022-09-03 14:27:01 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 14:27:26 +0200 | ccntrq | (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) |
| 2022-09-03 14:27:45 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2022-09-03 14:28:05 +0200 | euandreh | (~euandreh@179.214.113.107) (Ping timeout: 255 seconds) |
| 2022-09-03 14:28:12 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 14:29:15 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 14:31:34 +0200 | off^^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 14:32:57 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 14:33:49 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2022-09-03 14:34:25 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 244 seconds) |
| 2022-09-03 14:35:28 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 14:39:19 +0200 | Vajb | (~Vajb@2001:999:705:3c86:e7ea:442b:1e01:22d8) (Read error: Connection reset by peer) |
| 2022-09-03 14:40:36 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) |
| 2022-09-03 14:41:11 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-09-03 14:51:17 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-09-03 14:51:51 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-03 14:53:01 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 258 seconds) |
| 2022-09-03 14:54:26 +0200 | coot | (~coot@213.134.176.158) (Client Quit) |
| 2022-09-03 14:54:56 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-03 15:03:24 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 15:05:02 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-09-03 15:05:04 +0200 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-09-03 15:05:05 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-09-03 15:05:23 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Client Quit) |
| 2022-09-03 15:05:54 +0200 | off^^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 268 seconds) |
| 2022-09-03 15:06:10 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-09-03 15:06:34 +0200 | ccntrq | (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection) |
| 2022-09-03 15:10:02 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2022-09-03 15:10:27 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 15:10:36 +0200 | [_] | [itchyjunk] |
| 2022-09-03 15:11:59 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-09-03 15:12:15 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Remote host closed the connection) |
| 2022-09-03 15:14:26 +0200 | ccntrq | (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) |
| 2022-09-03 15:15:10 +0200 | luffy | (~chenqisu1@183.217.201.192) (Ping timeout: 268 seconds) |
| 2022-09-03 15:15:37 +0200 | jakalx | (~jakalx@base.jakalx.net) () |
| 2022-09-03 15:15:45 +0200 | vglfr | (~vglfr@145.224.94.248) (Ping timeout: 244 seconds) |
| 2022-09-03 15:15:57 +0200 | vglfr | (~vglfr@145.224.94.248) |
| 2022-09-03 15:16:23 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) |
| 2022-09-03 15:16:43 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 15:16:53 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2022-09-03 15:21:24 +0200 | bsima- | bsima |
| 2022-09-03 15:23:31 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 244 seconds) |
| 2022-09-03 15:24:04 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 15:25:20 +0200 | euandreh | (~euandreh@179.214.113.107) |
| 2022-09-03 15:30:49 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 15:31:43 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-09-03 15:34:54 +0200 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-09-03 15:37:06 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 258 seconds) |
| 2022-09-03 15:42:05 +0200 | califax | (~califax@user/califx) (Ping timeout: 258 seconds) |
| 2022-09-03 15:48:19 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 15:51:17 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Ping timeout: 258 seconds) |
| 2022-09-03 15:51:42 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2022-09-03 15:52:27 +0200 | kitty4 | (~kitty@096-039-147-043.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2022-09-03 15:52:31 +0200 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 2022-09-03 15:58:18 +0200 | ccntrq | (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Ping timeout: 240 seconds) |
| 2022-09-03 15:58:19 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 268 seconds) |
| 2022-09-03 15:58:33 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2022-09-03 16:04:11 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2022-09-03 16:07:43 +0200 | ccntrq | (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) |
| 2022-09-03 16:14:14 +0200 | razetime_ | (~quassel@117.193.3.116) |
| 2022-09-03 16:14:21 +0200 | razetime | (~quassel@117.254.34.180) (Ping timeout: 268 seconds) |
| 2022-09-03 16:17:14 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) (Ping timeout: 244 seconds) |
| 2022-09-03 16:18:47 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-09-03 16:19:35 +0200 | kuribas | (~user@ptr-17d51emn3roko68gdk1.18120a2.ip6.access.telenet.be) (Remote host closed the connection) |
| 2022-09-03 16:19:48 +0200 | kuribas | (~user@ptr-17d51emtyrhqrcgzxtn.18120a2.ip6.access.telenet.be) |
| 2022-09-03 16:20:13 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-09-03 16:21:23 +0200 | ccntrq | (~Thunderbi@exit-1.office.han.de.mhd.medondo.com) (Remote host closed the connection) |
| 2022-09-03 16:21:25 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 16:24:58 +0200 | APic | (apic@apic.name) (Remote host closed the connection) |
| 2022-09-03 16:27:18 +0200 | APic | (apic@apic.name) |
| 2022-09-03 16:36:57 +0200 | off^^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) |
| 2022-09-03 16:37:07 +0200 | off^^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Remote host closed the connection) |
| 2022-09-03 16:38:56 +0200 | off^ | (~off@c-73-237-184-20.hsd1.ga.comcast.net) (Ping timeout: 244 seconds) |
| 2022-09-03 16:43:52 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 16:50:30 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 16:55:09 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-09-03 16:55:49 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 17:01:06 +0200 | coot | (~coot@2a02:a310:e241:1b00:ec1a:e9df:79ac:66ba) (Quit: coot) |
| 2022-09-03 17:02:44 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-03 17:07:04 +0200 | coot | (~coot@213.134.176.158) (Client Quit) |
| 2022-09-03 17:16:55 +0200 | Kaiepi | (~Kaiepi@142.68.249.28) |
| 2022-09-03 17:24:32 +0200 | cristianorocha | (~cristiano@2804:108c:c9a9:cd01:9f82:aa32:57c:7335) |
| 2022-09-03 17:24:49 +0200 | <cristianorocha> | Hello there! |
| 2022-09-03 17:28:20 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-09-03 17:28:53 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 17:29:01 +0200 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Quit: leaving) |
| 2022-09-03 17:29:49 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-09-03 17:31:26 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 17:32:08 +0200 | eikke | (~NicolasT@user/NicolasT) |
| 2022-09-03 17:32:20 +0200 | <[exa]> | h e l l o ! |
| 2022-09-03 17:43:07 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-09-03 17:47:57 +0200 | jinsun | (~jinsun@user/jinsun) |
| 2022-09-03 17:50:53 +0200 | APic | (apic@apic.name) (Quit: [TLS] Client upgrade) |
| 2022-09-03 17:51:05 +0200 | APic | (apic@apic.name) |
| 2022-09-03 17:52:44 +0200 | hgolden | (~Howard@cpe-172-251-233-141.socal.res.rr.com) |
| 2022-09-03 17:54:41 +0200 | squiffs | (~squiffs@host86-184-142-169.range86-184.btcentralplus.com) |
| 2022-09-03 17:58:13 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 17:58:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 18:00:26 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-09-03 18:00:47 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-09-03 18:01:25 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) (Remote host closed the connection) |
| 2022-09-03 18:01:39 +0200 | causal | (~user@2001:470:ea0f:3:329c:23ff:fe3f:1e0e) |
| 2022-09-03 18:02:56 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) |
| 2022-09-03 18:03:55 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 18:05:55 +0200 | Capn_Pic | (apic@brezn3.muc.ccc.de) |
| 2022-09-03 18:06:35 +0200 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) (Ping timeout: 268 seconds) |
| 2022-09-03 18:06:38 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) (Ping timeout: 240 seconds) |
| 2022-09-03 18:07:58 +0200 | <squiffs> | Hello, I'm trying to write a Category instance for (categorical) spans in Haskell. This is what I have so far: https://paste.tomsmeding.com/lCeyyyrf. Is it possible to write a category instance for Span? With some help from aspiwack I know that it may have to be a constrained category instance, but don't know what the constraint might be (see https://paste.tomsmeding.com/K1arMRLe for some ideas). Would I wri |
| 2022-09-03 18:07:58 +0200 | <squiffs> | te down an instance for Span directly, or for functions between Spans somehow? Thanks! |
| 2022-09-03 18:08:57 +0200 | Capn_Pic | (apic@brezn3.muc.ccc.de) (Client Quit) |
| 2022-09-03 18:12:16 +0200 | CAT_S | (apic@brezn3.muc.ccc.de) |
| 2022-09-03 18:15:30 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-09-03 18:15:30 +0200 | eikke | (~NicolasT@user/NicolasT) (Read error: Connection reset by peer) |
| 2022-09-03 18:15:38 +0200 | Vajb | (~Vajb@2001:999:705:3c86:e7ea:442b:1e01:22d8) |
| 2022-09-03 18:20:09 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-09-03 18:20:35 +0200 | stefan-_ | (~cri@42dots.de) (Ping timeout: 252 seconds) |
| 2022-09-03 18:25:09 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 18:26:17 +0200 | <[exa]> | squiffs: you can literally discard the "middle" 2 items of (x->b) right? |
| 2022-09-03 18:27:02 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-09-03 18:27:53 +0200 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 2022-09-03 18:31:29 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-09-03 18:33:54 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 18:34:18 +0200 | razetime_ | (~quassel@117.193.3.116) (Ping timeout: 240 seconds) |
| 2022-09-03 18:34:53 +0200 | razetime | (~quassel@117.254.35.42) |
| 2022-09-03 18:35:16 +0200 | <squiffs> | [exa]: Yes that's true, you can delete the middle if the "right" projection of s1 matches the "left" projection of s2 and keep the left/right projections of s1/s2 respectively. Is that all that's possible? Is there any way to keep the middle bits around? It would be interesting to inspect the resulting structure. Maybe it's just not possible since we've quantified it away? |
| 2022-09-03 18:37:52 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) (Quit: Leaving.) |
| 2022-09-03 18:37:56 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-09-03 18:40:04 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 18:40:20 +0200 | m1dnight | (~christoph@78-22-0-121.access.telenet.be) |
| 2022-09-03 18:41:10 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-09-03 18:41:52 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 18:42:25 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 244 seconds) |
| 2022-09-03 18:44:17 +0200 | <[exa]> | squiffs: if you kept it around you would somehow need to leave the `b` (and many other middles) in the type right? |
| 2022-09-03 18:45:59 +0200 | <[exa]> | anyway afaik you are pretty sure that both sides match (that's the assumption you can use from the type of (.) ) |
| 2022-09-03 18:46:02 +0200 | stefan-_ | (~cri@42dots.de) |
| 2022-09-03 18:47:57 +0200 | <squiffs> | [exa]: Yeah that's it - we need the 'b' around but also don't want it around in the resulting composed type. So it would seem impossible. |
| 2022-09-03 18:49:02 +0200 | <squiffs> | [exa]: I guess it's similar to composing functions (a -> b), (b -> c) - you don't get to keep the intermediate b value. |
| 2022-09-03 18:49:10 +0200 | razetime_ | (~quassel@117.193.0.45) |
| 2022-09-03 18:49:18 +0200 | razetime | (~quassel@117.254.35.42) (Ping timeout: 264 seconds) |
| 2022-09-03 18:49:23 +0200 | <[exa]> | likely. |
| 2022-09-03 18:50:23 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-09-03 18:50:52 +0200 | <squiffs> | [exa]: Thanks for your help. |
| 2022-09-03 18:51:34 +0200 | <[exa]> | as a slight counter-example, the arrows need to be associative |
| 2022-09-03 18:51:56 +0200 | <[exa]> | so if you just took a log of what the middle b's were, you might end up with something that is not a category |
| 2022-09-03 18:53:06 +0200 | <squiffs> | [exa]: Yes indeed, I've read (https://ncatlab.org/nlab/show/span#categories_of_spans) that it's a 2-category rather than a category, complicating matters. I don't know if there's any literature about 2-categories in Haskell. |
| 2022-09-03 18:53:20 +0200 | kayvank | (~user@52-119-115-185.PUBLIC.monkeybrains.net) (Remote host closed the connection) |
| 2022-09-03 18:55:31 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 18:55:37 +0200 | <[exa]> | yap it has a "simple" solution of making a ton of new spans that have linear pieces of history in them, but you'd need a particularly funky MkSpan |
| 2022-09-03 18:55:58 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-09-03 18:57:19 +0200 | pi2 | (~pi@173.209.64.74) |
| 2022-09-03 18:57:35 +0200 | <pi2> | hmm, i have questions about cabal but i don't know how to ask them |
| 2022-09-03 18:57:59 +0200 | <[exa]> | you can reimagine your span objects as arrows and try generate a monoid categry from them, not sure if that will be a category but it might be worth a shot |
| 2022-09-03 18:58:02 +0200 | <[exa]> | squiffs: ^ |
| 2022-09-03 18:58:05 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 18:58:18 +0200 | <[exa]> | pi2: describe your expectations and disappointment? :D |
| 2022-09-03 18:58:20 +0200 | razetime | (~quassel@117.193.1.7) |
| 2022-09-03 18:58:21 +0200 | razetime_ | (~quassel@117.193.0.45) (Ping timeout: 252 seconds) |
| 2022-09-03 18:58:42 +0200 | <pi2> | [exa]: well i have a project i downloaded and want to make the examples. it's the plfa agda book |
| 2022-09-03 18:58:54 +0200 | <squiffs> | [exa]: oh interesting, I'll have a think about that. Thanks again! |
| 2022-09-03 18:58:57 +0200 | <pi2> | but the makefile demands i have cabal. but i have ghc already. so i'm not sure if i'm doing it right |
| 2022-09-03 18:59:09 +0200 | <pi2> | does cabal have to be same version as ghc or linked to it? |
| 2022-09-03 18:59:19 +0200 | <[exa]> | not really.. how did you get your ghc? |
| 2022-09-03 18:59:21 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-09-03 18:59:26 +0200 | <pi2> | package manager |
| 2022-09-03 18:59:30 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 264 seconds) |
| 2022-09-03 18:59:39 +0200 | <[exa]> | cabal should have a package too, normally on most distros |
| 2022-09-03 18:59:41 +0200 | <pi2> | so i have /usr/bin/ghc and now i have /usr/bin/cabal as well |
| 2022-09-03 18:59:45 +0200 | <[exa]> | in debians it is cabal-install |
| 2022-09-03 18:59:50 +0200 | <[exa]> | afaik |
| 2022-09-03 18:59:53 +0200 | <pi2> | ok. i had a vague idea cabal depended on an exact verison of ghc |
| 2022-09-03 19:00:01 +0200 | <pi2> | yes i'm on debian |
| 2022-09-03 19:00:06 +0200 | <[exa]> | luckily not |
| 2022-09-03 19:00:15 +0200 | <[exa]> | I've had cabal 3.2 for ages |
| 2022-09-03 19:00:18 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 268 seconds) |
| 2022-09-03 19:00:23 +0200 | <pi2> | there's some ghcup script which i used before. but i thought that installed cabal to a local dir |
| 2022-09-03 19:00:24 +0200 | <[exa]> | kinda seeing I should finally upgrade it |
| 2022-09-03 19:00:44 +0200 | <pi2> | it says 3.0 here |
| 2022-09-03 19:01:05 +0200 | <[exa]> | yeah ghcup is slightly better if you need funky versions of packages -- for systemwide debian stuff, you get the versions that debian folks use to VERY RELIABLY package their things, mostly pandoc |
| 2022-09-03 19:01:14 +0200 | <[exa]> | but I'd give it a shot |
| 2022-09-03 19:01:45 +0200 | <[exa]> | if you get a bad message about completely messed up dependencies and/or versions too old, you might need the super-new versions from ghcup |
| 2022-09-03 19:01:55 +0200 | <sclv> | ghc's typically have a minimum version of cabal they are specced to work with (and earlier versions _may_ work but there may be issues) but newer cabals almost always work with older ghcs |
| 2022-09-03 19:02:22 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-09-03 19:02:26 +0200 | <[exa]> | (as another possibility, you can just download binary ghc and cabal from web, unpack them and run... I'm doing that) |
| 2022-09-03 19:02:45 +0200 | razetime | (~quassel@117.193.1.7) (Ping timeout: 252 seconds) |
| 2022-09-03 19:03:01 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-09-03 19:03:18 +0200 | razetime | (~quassel@117.254.34.51) |
| 2022-09-03 19:03:24 +0200 | img | (~img@user/img) |
| 2022-09-03 19:03:48 +0200 | <pi2> | hrm. so after installing cabal the makefile does proceed. it creates .cabal/config and then complains my version of cabal is too old |
| 2022-09-03 19:04:01 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 19:04:12 +0200 | <pi2> | then it cite a github issue about cabal 1.10 vs 2.0 vs 1.12 compatibility which seems irrelevant to this? i have cabal 3.0 |
| 2022-09-03 19:04:59 +0200 | <[exa]> | yeah that's hopefully faaaar behind us now |
| 2022-09-03 19:05:35 +0200 | <[exa]> | can you link the project repo, just to see what we're talking about? |
| 2022-09-03 19:06:10 +0200 | <pi2> | github.com/plfa/plfa.github.io |
| 2022-09-03 19:06:15 +0200 | <pi2> | i'm trying the make file in the root dir |
| 2022-09-03 19:06:15 +0200 | <c_wraith> | is it possible it's complaining about the cabal-version field in the cabal file? |
| 2022-09-03 19:06:57 +0200 | <c_wraith> | Oh, well, sort of. You need cabal 3.6 or newer |
| 2022-09-03 19:07:02 +0200 | <c_wraith> | 3.0 won't do |
| 2022-09-03 19:07:15 +0200 | <c_wraith> | Look at the first line of https://github.com/plfa/plfa.github.io/blob/dev/plfa.cabal |
| 2022-09-03 19:07:51 +0200 | <[exa]> | oooooh that is veeeery new. |
| 2022-09-03 19:07:57 +0200 | <pi2> | i have no idea how you found that so fast. but good |
| 2022-09-03 19:08:07 +0200 | <geekosaur> | hrm? 3.8 is out |
| 2022-09-03 19:08:20 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 19:08:24 +0200 | <c_wraith> | I ran into issues with that field (in the opposite direction) just a couple days ago on one of my projects, so it was fresh on my mind |
| 2022-09-03 19:09:12 +0200 | <pi2> | c_wraith: did you know to look for that already or was it mentioned in the main Makefile lol |
| 2022-09-03 19:09:41 +0200 | <c_wraith> | I knew to look for it as it's the main place version expectations are set. |
| 2022-09-03 19:09:56 +0200 | <pi2> | well regardless...what are my options |
| 2022-09-03 19:10:09 +0200 | <pi2> | can i get this to work somehow with my setup or do i need to reinstall cabal and ghc completely with ghcup |
| 2022-09-03 19:10:45 +0200 | <c_wraith> | you could change the version number there to 3.0 and see if it still works. You might need to make some other changes to that file to go along with, but I really don't know. |
| 2022-09-03 19:11:21 +0200 | razetime | (~quassel@117.254.34.51) (Ping timeout: 244 seconds) |
| 2022-09-03 19:11:37 +0200 | <c_wraith> | though... that cabal file looks like it's intended to build with stack |
| 2022-09-03 19:11:54 +0200 | <c_wraith> | There are almost no version bounds on the dependencies |
| 2022-09-03 19:11:56 +0200 | razetime | (~quassel@117.193.5.96) |
| 2022-09-03 19:12:05 +0200 | <pi2> | hmm i got an eror about plfa-22.6 and ImportQualifiedPost |
| 2022-09-03 19:12:37 +0200 | <pi2> | stack uses the same data as cabal? i know they're alternatives |
| 2022-09-03 19:12:50 +0200 | <c_wraith> | stack still generates a .cabal file |
| 2022-09-03 19:13:00 +0200 | <sclv> | its not designed for stack in this case, ignore that. the readme makes this clear |
| 2022-09-03 19:13:03 +0200 | <c_wraith> | because it still uses the underlying Cabal library |
| 2022-09-03 19:13:14 +0200 | <c_wraith> | ah, does it have versions pinned down elsewhere? |
| 2022-09-03 19:13:18 +0200 | <pi2> | somehow this feels like the worst of all worlds with dependencies. |
| 2022-09-03 19:13:27 +0200 | <sclv> | the reason the newer cabal is necessary is because there are new ghc extensions in the cabal file |
| 2022-09-03 19:13:39 +0200 | <geekosaur> | check for cabal.freeze? |
| 2022-09-03 19:13:40 +0200 | <pi2> | like. your project initially relies on libraries so new nobody has them. then eventually your project is old and depends on libraries so old nobody has them. |
| 2022-09-03 19:13:41 +0200 | <sclv> | like importqualifiedpost |
| 2022-09-03 19:13:49 +0200 | <c_wraith> | anyway... If the code is written to require ImportQualifiedPost, older versions of ghc just won't work |
| 2022-09-03 19:14:08 +0200 | <monochrom> | stack pins versions by a clause specifying stack resolver version |
| 2022-09-03 19:14:15 +0200 | <pi2> | older than what, 8.10? |
| 2022-09-03 19:14:43 +0200 | <monochrom> | ImportQualifiedPost is like 9.2 |
| 2022-09-03 19:14:54 +0200 | <pi2> | hrm. the readme said it was tested with ghc versions 8.x |
| 2022-09-03 19:15:03 +0200 | <pi2> | i guess the only safe way to proceed is to totally reinstall everything |
| 2022-09-03 19:15:15 +0200 | <c_wraith> | why does that extension even exist? |
| 2022-09-03 19:15:19 +0200 | <monochrom> | But if you know Haskell, you can easily remove it and change all "import" lines back to old syntax. |
| 2022-09-03 19:15:51 +0200 | <geekosaur> | ImportQualifiedPost is 8.10.1 according to the manual |
| 2022-09-03 19:15:55 +0200 | <sclv> | the readme describes pretty comprehensively what you need and how to install it. i personally would just believe it and follow it |
| 2022-09-03 19:16:11 +0200 | <monochrom> | Err oops, don't listen to me. :) |
| 2022-09-03 19:16:23 +0200 | <pi2> | ok running ghc script now |
| 2022-09-03 19:16:31 +0200 | <c_wraith> | Like.. I feel like MultiwayIf was bad enough in terms of trivial syntax changes. ImportQualifiedPost is way more trivial. |
| 2022-09-03 19:16:58 +0200 | <sclv> | the desire to change import syntax is one of those things thats minor but it made people insanely mad they couldn't get consensus to get it chained |
| 2022-09-03 19:17:08 +0200 | <geekosaur> | even better, you get an annoying warning if you use old style imports with it enabled |
| 2022-09-03 19:17:23 +0200 | <sclv> | the entire ghc proposals process partly grew out of people frustrated that they couldn't change the import syntax |
| 2022-09-03 19:17:37 +0200 | <pi2> | well. i don't care too too much if this plfa author is being reasonable or not with the version requirements |
| 2022-09-03 19:17:45 +0200 | <pi2> | as ghcup is not that difficult, i think i used it on mac |
| 2022-09-03 19:17:53 +0200 | <monochrom> | I like ImportQualifiedPost actually. |
| 2022-09-03 19:18:11 +0200 | <pi2> | it sounds like some kind of battle i have no stake in |
| 2022-09-03 19:18:49 +0200 | <monochrom> | Nicer vertical alignments for import lines. |
| 2022-09-03 19:19:28 +0200 | <monochrom> | If you want to fight against trivial syntax changes, you are fighting in the wrong theatre. |
| 2022-09-03 19:19:41 +0200 | <monochrom> | Fight the whole notion of plain text files instead. |
| 2022-09-03 19:20:01 +0200 | <c_wraith> | I also hate RecordDotSyntax, yes |
| 2022-09-03 19:20:28 +0200 | <monochrom> | Plain text file is why people spend time on surface syntax. |
| 2022-09-03 19:20:30 +0200 | Panahifar | (~Panahifar@93.119.209.136) |
| 2022-09-03 19:20:33 +0200 | <pi2> | idk. i feel like if you want your book/project/thing to get as much exposure it should build with the most minimal requirements |
| 2022-09-03 19:20:34 +0200 | <monochrom> | The only reason. |
| 2022-09-03 19:21:11 +0200 | <c_wraith> | I'm not particular happy with mandatory IDEs, either |
| 2022-09-03 19:21:18 +0200 | <geekosaur> | pi2, sadly you're in the minority these days. "move fast, break stuff" rules these days |
| 2022-09-03 19:21:22 +0200 | <c_wraith> | Fortunately, Haskell doesn't have those. |
| 2022-09-03 19:21:35 +0200 | <pi2> | ah i see. T_T |
| 2022-09-03 19:21:46 +0200 | <geekosaur> | and not only in Haskell |
| 2022-09-03 19:21:55 +0200 | <geekosaur> | (it's been the rule in webdev for years) |
| 2022-09-03 19:22:01 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 19:22:13 +0200 | <pi2> | ah i guess that's true. always seems like some new web framework with nonsense name is trendy |
| 2022-09-03 19:22:18 +0200 | <monochrom> | Oh you can have people agreeing on a binary interchange format. And then everyone can code up their own favourite ways of rendering code. |
| 2022-09-03 19:22:36 +0200 | <c_wraith> | I'm a huge fan of new features. I just want them to actually be new features. |
| 2022-09-03 19:22:52 +0200 | <pi2> | someone was telling me c gets a new standard every 5 years. lol |
| 2022-09-03 19:22:58 +0200 | <c_wraith> | (ok, I also want them to not break stuff) |
| 2022-09-03 19:23:10 +0200 | <pi2> | at some point i'd think you'd lose track of which year you're even on. is this c2015,c2010,c2020, etc |
| 2022-09-03 19:23:18 +0200 | <sclv> | i mean import syntax is simple, but percentagewise it can be a huge proportion of the lines in many modules, so improvements to it, proportionally, have a reasonable impact |
| 2022-09-03 19:23:47 +0200 | <geekosaur> | more like every 3 years |
| 2022-09-03 19:23:55 +0200 | <geekosaur> | c11 c14 c17 c20 |
| 2022-09-03 19:24:37 +0200 | <pi2> | everyone talks about the y2k crisis or the 2038 crisis. nobody talks about the c standard crisis of 2089 |
| 2022-09-03 19:24:51 +0200 | <monochrom> | Take for example how many spaces to use for indentation, and even whether tabs are allowed. |
| 2022-09-03 19:24:55 +0200 | <c_wraith> | nobody talks about because it's supposed to still be a secret! |
| 2022-09-03 19:25:20 +0200 | <monochrom> | The only reason such an issue could be disagreed upon at all is because plain text files. |
| 2022-09-03 19:25:45 +0200 | <monochrom> | But imagine a binary format that marks the inner-vs-outer block structure. |
| 2022-09-03 19:26:11 +0200 | <c_wraith> | I think you missed my point about editors. I don't want to have to have special code for every language in editors. |
| 2022-09-03 19:26:27 +0200 | <monochrom> | Then one renderer can show it as indented by 4 spaces, another can show it as indented by 1.5cm, and a third one that draws a nested diagram, what is indentation? |
| 2022-09-03 19:26:32 +0200 | <geekosaur> | you do anyway |
| 2022-09-03 19:26:49 +0200 | <c_wraith> | I assure you, I edit a lot of code my editors know *nothing* about |
| 2022-09-03 19:27:32 +0200 | <c_wraith> | I could teach them, but I like that I don't have to |
| 2022-09-03 19:27:52 +0200 | <pi2> | you mean like LSP and the hls? |
| 2022-09-03 19:28:02 +0200 | <c_wraith> | I don't even use those |
| 2022-09-03 19:28:03 +0200 | neceve | (~quassel@2.26.93.14) (Ping timeout: 268 seconds) |
| 2022-09-03 19:28:10 +0200 | <geekosaur> | even syntax coloring because it has to know how to parse the fle to color it |
| 2022-09-03 19:28:48 +0200 | <c_wraith> | yeah, syntax coloring is something I'm happy to do without in exchange for... not having to worry about it. |
| 2022-09-03 19:28:59 +0200 | <monochrom> | There are also people who prefer import lines to be like "import (length, size, tomato, potato) qualified from Data.Vector". And there are 3 variations of where to put that "qualified". |
| 2022-09-03 19:29:12 +0200 | <pi2> | fun fact, you can get rid of syntax coloring in vim with -C which forces vi mode |
| 2022-09-03 19:29:18 +0200 | <monochrom> | Are we going to make one more GHC proposal and extension for that? |
| 2022-09-03 19:29:28 +0200 | <c_wraith> | monochrom: ugh, I've used python. all that verbosity makes code really hard to write. |
| 2022-09-03 19:30:02 +0200 | <geekosaur> | hls really really badly wants me to import everything explicitly 😞 |
| 2022-09-03 19:30:29 +0200 | <c_wraith> | Though it's not as bad as AppleScript. Now there's a read-only language. |
| 2022-09-03 19:30:34 +0200 | <monochrom> | I am your friend, not your enemy, in eliminating trivial syntax feature proposal by proposing that there should be personal code renderers that show your favourite syntax. |
| 2022-09-03 19:30:37 +0200 | <geekosaur> | always fun when I pop open my xmonad config and it wants me to import 94 things from XMonad |
| 2022-09-03 19:30:47 +0200 | <monochrom> | s/personal/personalized/ |
| 2022-09-03 19:30:49 +0200 | <geekosaur> | I am not exaggerating. 94. |
| 2022-09-03 19:31:14 +0200 | <pi2> | why would a config file need new imports, isn't it just a static config |
| 2022-09-03 19:31:50 +0200 | <c_wraith> | no, xmonad's "config" is actually haskell code. |
| 2022-09-03 19:31:55 +0200 | <pi2> | ah |
| 2022-09-03 19:31:57 +0200 | <c_wraith> | It's confusingly named |
| 2022-09-03 19:32:08 +0200 | <c_wraith> | but it's kinda nice in practice. |
| 2022-09-03 19:32:21 +0200 | <c_wraith> | xmonad is a library that you build haskell programs to use. |
| 2022-09-03 19:32:21 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-09-03 19:32:31 +0200 | <pi2> | gnu grub does something similar. it has a main .conf file which is actually a script it runs |
| 2022-09-03 19:32:59 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 268 seconds) |
| 2022-09-03 19:33:07 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-09-03 19:33:26 +0200 | <pi2> | well this script is install ghc 8.10.7 for aarch64 and may take awhile. thanks for the help |
| 2022-09-03 19:33:31 +0200 | <pi2> | if i continue to have problems i may return |
| 2022-09-03 19:33:32 +0200 | <monochrom> | "(length, size, tomato, potato) qualified comesfrom Data.Vector" if you prefer it shorter. |
| 2022-09-03 19:34:18 +0200 | <monochrom> | Note that it has no more tokens than standard Haskell's equiv. |
| 2022-09-03 19:34:37 +0200 | <monochrom> | My point is that some people want that order of information. |
| 2022-09-03 19:35:23 +0200 | razetime | (~quassel@117.193.5.96) (Ping timeout: 268 seconds) |
| 2022-09-03 19:35:42 +0200 | <monochrom> | I might even be subconsciously one of them. |
| 2022-09-03 19:36:58 +0200 | <c_wraith> | huh. sometime in the last few years, GHC sped up template-haskell a lot. It no longer pauses compilation for multiple seconds to start up an interpreter. |
| 2022-09-03 19:37:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 19:37:28 +0200 | <c_wraith> | Maybe it's time to revisit my bias towards never using template-haskell for things that are one-liners without. |
| 2022-09-03 19:37:34 +0200 | <monochrom> | I might even justify "(length, size, tomato, potato) qualified import Data.Vector" by appealing to Japanese grammar. |
| 2022-09-03 19:37:37 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 19:37:50 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 258 seconds) |
| 2022-09-03 19:37:52 +0200 | <c_wraith> | Japanese grammar would put "import" at the end |
| 2022-09-03 19:38:07 +0200 | <monochrom> | Heh yeah. |
| 2022-09-03 19:38:23 +0200 | <monochrom> | {-# LANGUAGE JapanGrammar #-} |
| 2022-09-03 19:38:41 +0200 | <hpc> | wouldn't it just be {-# LANGUAGE Japanese #-} at that point? :D |
| 2022-09-03 19:38:52 +0200 | <c_wraith> | does that require putting the = at the end of the line in declarations? |
| 2022-09-03 19:39:02 +0200 | <darkling> | Sounds reasonable to me. |
| 2022-09-03 19:39:15 +0200 | <hpc> | automatically enables UnicodeSyntax too :D |
| 2022-09-03 19:39:18 +0200 | <darkling> | RPN everywhere. :) |
| 2022-09-03 19:40:58 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-09-03 19:43:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-09-03 19:44:25 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 244 seconds) |
| 2022-09-03 19:48:47 +0200 | squiffs | (~squiffs@host86-184-142-169.range86-184.btcentralplus.com) (Remote host closed the connection) |
| 2022-09-03 19:49:06 +0200 | neceve | (~quassel@2.26.93.14) |
| 2022-09-03 19:50:01 +0200 | Panahifar | (~Panahifar@93.119.209.136) (Quit: Leaving) |
| 2022-09-03 19:50:08 +0200 | Andreas | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) |
| 2022-09-03 19:50:19 +0200 | <rustisafungus> | are there any other pure functional nonstrict/lazy languages aside from haskell? |
| 2022-09-03 19:50:32 +0200 | Andreas | Guest1564 |
| 2022-09-03 19:50:38 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-09-03 19:51:41 +0200 | <c_wraith> | Haskell was created by a committee to standardize development of pure functional non-strict languages, consolidating several development efforts that had been ongoing with languages like Miranda |
| 2022-09-03 19:52:08 +0200 | <rustisafungus> | so this is the only game in town then? |
| 2022-09-03 19:52:11 +0200 | Panahifar | (~Panahifar@93.119.209.136) |
| 2022-09-03 19:52:49 +0200 | <c_wraith> | Well, you can still dig up Miranda. Sort of. (Did it get open-sourced recently, or am I misremembering?) |
| 2022-09-03 19:53:06 +0200 | <c_wraith> | But Haskell is certainly the largest ongoing effort |
| 2022-09-03 19:53:08 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 19:53:45 +0200 | <geekosaur> | It did |
| 2022-09-03 19:53:54 +0200 | <geekosaur> | I think Gofer's dead though |
| 2022-09-03 19:54:31 +0200 | <c_wraith> | Depending on how you interpret things, the nix language could be called pure, functional, and non-strict |
| 2022-09-03 19:55:43 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 19:56:09 +0200 | <Guest1564> | Can you post code here? I have a question on a small program (it uses alot of memory) |
| 2022-09-03 19:56:34 +0200 | <c_wraith> | You should use a pastebin. there's one in the topic that's good if you don't have a preference |
| 2022-09-03 19:58:13 +0200 | coot | (~coot@213.134.176.158) |
| 2022-09-03 20:00:31 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 20:01:01 +0200 | <Guest1564> | Thanks. It's here https://paste.tomsmeding.com/0cy1qPr3. It was for advent of code day 15. When run on a big input like from https://the-tk.com/project/aoc2021-bigboys.html it never finished and the memory just keeps growing |
| 2022-09-03 20:01:14 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2022-09-03 20:01:33 +0200 | <Guest1564> | Is this whats called a space leak? |
| 2022-09-03 20:02:22 +0200 | <geekosaur> | looks like it, yes |
| 2022-09-03 20:03:19 +0200 | <Guest1564> | I tried bang patterns but doesnt work. Sets are strict anyway |
| 2022-09-03 20:03:55 +0200 | <geekosaur> | the way that's written it's going to hold the whole file in memory. twice, I think |
| 2022-09-03 20:04:47 +0200 | Panahifar | (~Panahifar@93.119.209.136) (Quit: Leaving) |
| 2022-09-03 20:05:27 +0200 | <Guest1564> | But the file is not that big. The memory of the program becomes 4GB |
| 2022-09-03 20:05:37 +0200 | <davean> | It looks to actually need that memory not so much leak it? |
| 2022-09-03 20:05:46 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2022-09-03 20:06:34 +0200 | econo | (uid147250@user/econo) |
| 2022-09-03 20:06:52 +0200 | <Guest1564> | "Same" program in python uses about 1.5GB but finished in about 10 seconds on my laptop |
| 2022-09-03 20:07:04 +0200 | <davean> | Guest1564: Lists expand storage space a lot |
| 2022-09-03 20:07:09 +0200 | <c_wraith> | I'm not seeing anywhere in the loop that actually uses the heap you're creating. |
| 2022-09-03 20:07:14 +0200 | <c_wraith> | so that's leaking space, at least |
| 2022-09-03 20:08:01 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds) |
| 2022-09-03 20:08:13 +0200 | <davean> | Guest1564: A list is a single element, and a pointer |
| 2022-09-03 20:08:16 +0200 | <c_wraith> | in fact, I'm not seeing anywhere in the code that uses the heap at all... |
| 2022-09-03 20:08:43 +0200 | <c_wraith> | oh, there it is. line 31 |
| 2022-09-03 20:08:49 +0200 | <Guest1564> | It uses the heap to find next direction (line 27) |
| 2022-09-03 20:09:13 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 244 seconds) |
| 2022-09-03 20:09:37 +0200 | <c_wraith> | if line 27 was the only place using it, it'd be equivalent to not using it. But 31 exists. |
| 2022-09-03 20:09:57 +0200 | <davean> | Guest1564: you really need to move off lists if you don't want the storage size to be huge |
| 2022-09-03 20:09:59 +0200 | <c_wraith> | anyway, yeah. your foldl' is leaking the heap |
| 2022-09-03 20:10:04 +0200 | <davean> | Guest1564: python uses arrays, not lists |
| 2022-09-03 20:10:37 +0200 | <c_wraith> | If you want to solve it with a bang pattern, `maybeSeen (!heap, set) (x, y) =` on line 37 |
| 2022-09-03 20:11:07 +0200 | <Guest1564> | davean, the program is using an arrays and sets not listss |
| 2022-09-03 20:11:28 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 20:11:28 +0200 | <c_wraith> | davean: what list are you seeing, other than the list of directions? |
| 2022-09-03 20:11:48 +0200 | <davean> | c_wraith: when he's reading it in. He holds it twice first. |
| 2022-09-03 20:11:59 +0200 | <Guest1564> | c_wraith, I tried that it doesnt change anything |
| 2022-09-03 20:12:00 +0200 | <davean> | Its kinda minor, thats not his main problem but it will seriously slow down import |
| 2022-09-03 20:12:19 +0200 | <c_wraith> | Huh, I guess that foldl' isn't very relevant, as it's not folding over a very big set |
| 2022-09-03 20:13:10 +0200 | <Guest1564> | Is there a more idiomatic way to do graph search? |
| 2022-09-03 20:13:41 +0200 | <davean> | Guest1564: it doesn't seem terrible. There are certainly other approaches. |
| 2022-09-03 20:13:56 +0200 | <c_wraith> | this looks wrong, for Dijkstra's algorithm |
| 2022-09-03 20:14:20 +0200 | <c_wraith> | You're not allowing for the possibility of finding a new shorter path to something already in the seen set |
| 2022-09-03 20:15:47 +0200 | <Guest1564> | c_wraith: I don't need to when I've already seen that node. I think the algo is fine and it gives the right answer for different inputs |
| 2022-09-03 20:16:12 +0200 | <Guest1564> | Is it because it is copying the Set and the Heap on every iteration |
| 2022-09-03 20:16:12 +0200 | <Guest1564> | ? |
| 2022-09-03 20:16:39 +0200 | <c_wraith> | what heap library are you using? |
| 2022-09-03 20:19:49 +0200 | <Guest1564> | https://hackage.haskell.org/package/heaps-0.4/docs/Data-Heap.html |
| 2022-09-03 20:22:52 +0200 | <c_wraith> | I see. Your implementation of Dijkstra will give correct answers, but it will put a lot of duplicate elements in the heap that don't get discarded until later. |
| 2022-09-03 20:23:23 +0200 | <c_wraith> | It's possible with a sufficiently large graph that that waste is enough to explain the memory use |
| 2022-09-03 20:24:40 +0200 | <Guest1564> | Oh, that might be it. But the python program https://paste.tomsmeding.com/7bXw9PyJ does the same and runs very fast |
| 2022-09-03 20:25:31 +0200 | <c_wraith> | the only space leak I see in there is the heap during the foldl' |
| 2022-09-03 20:25:44 +0200 | <c_wraith> | and it's very minor, as the foldl' is over a small set |
| 2022-09-03 20:27:21 +0200 | Guest|81 | (~Guest|81@189.181.7.165) |
| 2022-09-03 20:27:23 +0200 | <Guest|81> | heya |
| 2022-09-03 20:28:16 +0200 | <c_wraith> | I'd suspect the problem is either an algorithmic mistake causing it to solve the wrong problem, or just memory use of the data structures involved. |
| 2022-09-03 20:28:32 +0200 | <c_wraith> | this doesn't look like it's laziness-related |
| 2022-09-03 20:29:39 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 20:29:39 +0200 | Guest|81 | (~Guest|81@189.181.7.165) (Client Quit) |
| 2022-09-03 20:30:12 +0200 | Guest|81 | (~Guest|81@189.181.7.165) |
| 2022-09-03 20:30:35 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-09-03 20:31:25 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-09-03 20:32:48 +0200 | acidjnk | (~acidjnk@p200300d6e7137a072978330082d08561.dip0.t-ipconnect.de) |
| 2022-09-03 20:33:06 +0200 | neceve | (~quassel@2.26.93.14) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-03 20:33:34 +0200 | neceve | (~quassel@2.26.93.14) |
| 2022-09-03 20:35:09 +0200 | rockymarine | (~rocky@user/rockymarine) |
| 2022-09-03 20:35:18 +0200 | Guest|81 | (~Guest|81@189.181.7.165) (Quit: Connection closed) |
| 2022-09-03 20:35:20 +0200 | <dolio> | Using 3x as much memory would be a pretty tame space leak, usually. |
| 2022-09-03 20:35:43 +0200 | <dolio> | People usually use the term for programs that use asymptotically more memory than expected. |
| 2022-09-03 20:35:57 +0200 | Topsi | (~Topsi@dyndsl-095-033-090-077.ewe-ip-backbone.de) |
| 2022-09-03 20:36:22 +0200 | <c_wraith> | I specifically use it for the case when nested thunks build up that all need to be evaluated together when the value is finally demanded. |
| 2022-09-03 20:36:29 +0200 | <dolio> | I guess 3x could be an extra log factor. :) |
| 2022-09-03 20:36:38 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-09-03 20:36:38 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-09-03 20:36:38 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-03 20:36:51 +0200 | <c_wraith> | everything else is space *use*, not a space *leak* |
| 2022-09-03 20:38:42 +0200 | Guest1564 | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) (Remote host closed the connection) |
| 2022-09-03 20:38:57 +0200 | neceve | (~quassel@2.26.93.14) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-03 20:38:58 +0200 | Andreas | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) |
| 2022-09-03 20:39:18 +0200 | neceve | (~quassel@2.26.93.14) |
| 2022-09-03 20:39:22 +0200 | Andreas | Guest6976 |
| 2022-09-03 20:40:06 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-09-03 20:40:13 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds) |
| 2022-09-03 20:41:43 +0200 | califax | (~califax@user/califx) |
| 2022-09-03 20:42:48 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-09-03 20:44:02 +0200 | neceve | (~quassel@2.26.93.14) (Client Quit) |
| 2022-09-03 20:44:23 +0200 | neceve | (~neceve@2.26.93.14) |
| 2022-09-03 20:44:34 +0200 | <Guest6976> | But if it's not a space leak then haskell is just inefficient in this case? The program never finishes... |
| 2022-09-03 20:45:11 +0200 | <c_wraith> | not a space leak doesn't mean not a memory use problem. |
| 2022-09-03 20:45:25 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds) |
| 2022-09-03 20:47:25 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) |
| 2022-09-03 20:51:56 +0200 | neceve | (~neceve@2.26.93.14) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-09-03 20:52:20 +0200 | neceve | (~neceve@2.26.93.14) |
| 2022-09-03 20:52:41 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-09-03 20:52:47 +0200 | <c_wraith> | I expect the big difference is the heap libraries. I'm betting the python one is array-based. The haskell one is tree-based |
| 2022-09-03 20:53:03 +0200 | <c_wraith> | that means a *lot* more pointer chasing |
| 2022-09-03 20:57:09 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-09-03 20:57:42 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-09-03 20:59:39 +0200 | Guest6976 | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) (Remote host closed the connection) |
| 2022-09-03 21:00:41 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 21:01:55 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds) |
| 2022-09-03 21:02:43 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 21:08:31 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2022-09-03 21:08:50 +0200 | <monochrom> | See this is the problem with choosing the wording "space leak". |
| 2022-09-03 21:09:08 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:d9e7:117d:c6bf:ca57) |
| 2022-09-03 21:09:19 +0200 | <Rembane> | The final fronteer |
| 2022-09-03 21:10:20 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-09-03 21:10:20 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-09-03 21:10:20 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-09-03 21:24:19 +0200 | mmhat | (~mmh@p200300f1c728cc1bee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-09-03 21:26:14 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 21:28:37 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 258 seconds) |
| 2022-09-03 21:30:23 +0200 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) (Quit: leaving) |
| 2022-09-03 21:33:06 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-09-03 21:40:28 +0200 | nahcetan | (~nate@98.45.169.16) |
| 2022-09-03 21:40:50 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 21:41:11 +0200 | n8chan | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-09-03 21:41:43 +0200 | <qrpnxz> | [exa]: Monads are straight up boring in how simple they are. The interface is either viewed as "callback" from a control view or "flatmap" from a data view. Every Monad I ever saw looks like: 1) algebraic data type (flatmap), 2) ((->) r (Algebraic datatype)) (callback+flatmap), or 3) church encoding of the former two, which is continuation based, which is just callbacks. Nothing out of left field |
| 2022-09-03 21:41:45 +0200 | <qrpnxz> | so far. Mysterious `IO` as you mention is just `RealWorld -> (RealWorld, a)`. All the instance does is mappend `Endo RealWorld` while we mess around with an extra output. That's Applicative, too, just a spicier version of Monoid. And Functor of course is just `map`. Where is the mass confusion in other languages about a type having `flatmap`, or passing a callback, or just doing a mappend on part |
| 2022-09-03 21:41:47 +0200 | <qrpnxz> | of a datatype? I think most of the confusion around Monad has got to be simply the name "Monad" and the name ">>=". Perhaps it's that in other languages the `((->) r)` sort of class of monads are more rare. But is that really such a leap? Perhaps it's that Haskell uses it more often for control flow. I don't know. Maybe I'm crazy and Monad is complicated than that, but how? It's a two method class |
| 2022-09-03 21:41:49 +0200 | <qrpnxz> | with a couple of laws. It can't be that complicated. |
| 2022-09-03 21:42:52 +0200 | <monochrom> | S -> (a, S) doesn't look algebraic or continuationic to me. |
| 2022-09-03 21:43:17 +0200 | <monochrom> | Instead, it looks... functional :) |
| 2022-09-03 21:44:14 +0200 | <monochrom> | But yeah the definition is pretty simple. |
| 2022-09-03 21:44:20 +0200 | <monochrom> | the definition of monad |
| 2022-09-03 21:45:14 +0200 | <monochrom> | But people can't work with definitions, axioms, and logical deductions. They can only work with metaphors. |
| 2022-09-03 21:45:15 +0200 | Panahifar | (~Panahifar@93.119.209.136) |
| 2022-09-03 21:45:33 +0200 | <monochrom> | Consider how FIFO queues are taught. |
| 2022-09-03 21:46:04 +0200 | <qrpnxz> | how are they taught |
| 2022-09-03 21:46:19 +0200 | <monochrom> | By appealing to metaphors. |
| 2022-09-03 21:46:26 +0200 | <monochrom> | By showing implementations. |
| 2022-09-03 21:46:45 +0200 | <monochrom> | No one teaches the axiomatic definition free of implementation concerns. |
| 2022-09-03 21:46:47 +0200 | <qrpnxz> | yeah, i was gonna bring that up about showing implementations. Maybe that's what we need more of? |
| 2022-09-03 21:47:18 +0200 | <monochrom> | Well here is a difficulty that monads suffer but queues don't. |
| 2022-09-03 21:47:50 +0200 | <monochrom> | Different implementations of queues look like doing the same thing and it doesn't matter which you choose. |
| 2022-09-03 21:48:02 +0200 | <monochrom> | Different implementations of monads look completely unrelated. |
| 2022-09-03 21:48:55 +0200 | <monochrom> | Queue has a unifying metaphor, just think of daily life lining up. Monads don't have a unifying metaphor. |
| 2022-09-03 21:49:14 +0200 | <monochrom> | Or it does but useless. |
| 2022-09-03 21:51:16 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 21:52:09 +0200 | Panahifar | (~Panahifar@93.119.209.136) (Quit: Leaving) |
| 2022-09-03 21:54:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 21:57:00 +0200 | <qrpnxz> | I think the essence of Monad is basically callbacks and monoid. I agree it's not as neat as queue, but I still am confused by what appears to be a double standard wrt monad instances in other languages. Perahps the difficulty of even writing `class Monad` in other languages makes it difficult to grok the abstraction in Haskell? I think you are right just studying a bunch of instances and |
| 2022-09-03 21:57:02 +0200 | <qrpnxz> | implementations and then pointing out "hey, see how this is the same thing?" is probably the best way. |
| 2022-09-03 21:57:12 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-09-03 21:57:42 +0200 | texasmynsted | (~texasmyns@99.96.221.112) (Remote host closed the connection) |
| 2022-09-03 21:58:09 +0200 | <qrpnxz> | I just remembered that pointers are "hard" as well. I never got that one either. |
| 2022-09-03 21:58:15 +0200 | <johnw> | Monad is monoid at the (endo-)functor level; it's bizarrely difficult to intuit this |
| 2022-09-03 21:58:41 +0200 | <hpc> | a more approachable "every instance is different" might be just algebra? |
| 2022-09-03 21:58:43 +0200 | <dolio> | monochrom: It is algebraic, though. |
| 2022-09-03 21:58:57 +0200 | <hpc> | use that to ease people into the idea |
| 2022-09-03 21:59:21 +0200 | <hpc> | the algebras of sets and linear transformations don't really have anything in common, for example |
| 2022-09-03 21:59:30 +0200 | <c_wraith> | pointers in C *are* hard. memory addresses aren't, but C adds a ton of additional semantics to the things they call "pointers", and modern compilers promise to silently break your code if you don't obey the rules. |
| 2022-09-03 21:59:42 +0200 | <hpc> | but the laws are much more approachable |
| 2022-09-03 21:59:57 +0200 | <johnw> | c_wraith: so true, I was reading a discussion about the semantic model for C++ pointers recently, and I was shocked at the layers of abstraction involved |
| 2022-09-03 22:00:03 +0200 | <dolio> | It's the free algebra generated by get, put, and the 3 natural equations on get and put. |
| 2022-09-03 22:00:25 +0200 | <qrpnxz> | c_wraith: example? |
| 2022-09-03 22:01:02 +0200 | <c_wraith> | no examples are small enough to fit in an irc message. |
| 2022-09-03 22:01:07 +0200 | <qrpnxz> | When i see someone confused about pointers it's never something so nuanced. Even just understanding what it is on a basic level seems to be the barrier. |
| 2022-09-03 22:01:20 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 244 seconds) |
| 2022-09-03 22:01:32 +0200 | <qrpnxz> | "additional semantics" aside |
| 2022-09-03 22:01:54 +0200 | <[Leary]> | qrpnxz: "It's the abstraction" should be correct. The abstract is the simplest possible thing when you already know how to deal with it, but learning that requires years of formal training or longer years of practice. |
| 2022-09-03 22:02:31 +0200 | <[Leary]> | Monad is too abstract for most programmers. |
| 2022-09-03 22:03:38 +0200 | <c_wraith> | qrpnxz: https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html is part of a series on what's going on. though if I remember right, it leaves a lot out too |
| 2022-09-03 22:04:59 +0200 | <qrpnxz> | the start of that blog is insane. That optimization sequence seems like a bug. |
| 2022-09-03 22:05:26 +0200 | <monochrom> | qrpnxz: Yes, other languages lack polymorphism for the *->* kind, our Monad class is inexpressible in them. |
| 2022-09-03 22:05:40 +0200 | <monochrom> | The only solution is butchering. |
| 2022-09-03 22:06:35 +0200 | <monochrom> | hpc, programmers flunked algebra, it's the whole point why they chose programming in the first place. |
| 2022-09-03 22:07:23 +0200 | <monochrom> | And here we follow Backus's advice and advise them to understand programs by doing algebra! |
| 2022-09-03 22:07:52 +0200 | <qrpnxz> | lol mono |
| 2022-09-03 22:08:01 +0200 | <monochrom> | dolio: Ah, that kind of algebra, rather than ADT. |
| 2022-09-03 22:08:55 +0200 | <monochrom> | The axiomatic definition of queue I alluded to does that kind of algebra too. There are equations constraining enqueue and dequeue. |
| 2022-09-03 22:09:02 +0200 | <dolio> | We'll have them once programming adopts quotient inductive types. |
| 2022-09-03 22:09:06 +0200 | <dolio> | Or higher inductive types. |
| 2022-09-03 22:09:09 +0200 | <hpc> | monochrom: my required computer ethics course had a bunch of art students that used it as a technical credit, and they were shocked when the midterm project was send a pgp email to the TA |
| 2022-09-03 22:09:19 +0200 | <hpc> | but their bad choice of class doesn't invalidate the lesson :P |
| 2022-09-03 22:09:43 +0200 | <c_wraith> | yeah, most of that post is about other issues with C. but there are a lot of additional rules on pointers in C. like a pointer into an array is fine, but moving that pointer to anything outside the array is UB. or casting a pointer to do type coercions is UB. or aliasing pointers in a function call can lead to all kinds of UB. |
| 2022-09-03 22:10:06 +0200 | <qrpnxz> | hpc: for a computer ethics course, that is really weird |
| 2022-09-03 22:10:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-09-03 22:11:24 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-09-03 22:11:47 +0200 | <dolio> | monochrom: https://hub.darcs.net/dolio/omega-sigma/browse/Omega.agda#29 |
| 2022-09-03 22:11:59 +0200 | <qrpnxz> | c_wraith: pointers outside of valid memory being bad makes perfect logical sense to me. The aliasing ones are pretty straight forward, too, but I wouldn't say that was evident. That one would definitely need to be pointed out :P |
| 2022-09-03 22:12:40 +0200 | <qrpnxz> | dolio: did you type this? |
| 2022-09-03 22:12:40 +0200 | <c_wraith> | the thing is, all of those operations are perfectly valid and well-defined if all you're thinking of is memory addresses |
| 2022-09-03 22:12:55 +0200 | <c_wraith> | Pointers are more complex. |
| 2022-09-03 22:13:03 +0200 | <dolio> | Yes, of course. |
| 2022-09-03 22:13:22 +0200 | <qrpnxz> | sure, but no beginner ever comes to me with "ah why is this program failing when i try to access memory i didn't allocate?!?!" no they are confused about how pointers work at all. |
| 2022-09-03 22:14:08 +0200 | Andreas | (~andreas@cpe-76-90-84-251.socal.res.rr.com) |
| 2022-09-03 22:14:32 +0200 | Andreas | Guest6336 |
| 2022-09-03 22:15:00 +0200 | geekosaur | has encountered what qrpnxz is talking about (and been completely flummoxed; pointers made sense to him immediately) |
| 2022-09-03 22:15:00 +0200 | <qrpnxz> | c_wraith: btw, do you know if gcc has a flag or something so it tells you "found UB here, gonna exploit it" |
| 2022-09-03 22:15:21 +0200 | <geekosaur> | read to the end of that article |
| 2022-09-03 22:15:24 +0200 | <qrpnxz> | thx |
| 2022-09-03 22:15:37 +0200 | <geekosaur> | tl;dr: no, nor does clang, nor any other compiler |
| 2022-09-03 22:16:12 +0200 | <geekosaur> | UB is difficult to spot, because it gets explouted in nonobvious ways by interacting optimizations |
| 2022-09-03 22:16:17 +0200 | <geekosaur> | *exploited |
| 2022-09-03 22:16:39 +0200 | <monochrom> | -O2 implies "found UB here, gonna exploit it". |
| 2022-09-03 22:16:50 +0200 | <monochrom> | -O1 a bit less so, -O3 very more so. |
| 2022-09-03 22:16:52 +0200 | <qrpnxz> | well, there's some helpful flags there that i didn't know about, so that's nice. Understandable if gcc can't 100% tell me everything, but more than zero pretty good. |
| 2022-09-03 22:17:48 +0200 | <qrpnxz> | monochrom: i mean that it tells you what exactly UB it found and where |
| 2022-09-03 22:17:49 +0200 | titibandit | (~titibandi@xdsl-84-44-227-248.nc.de) (Quit: Leaving.) |
| 2022-09-03 22:18:37 +0200 | <monochrom> | I once wrote "unsigned n = 1; int c = 0; while (n != 0) { n <<= 1 c++; }". -O3 compiled it into an infinite loop. |
| 2022-09-03 22:19:23 +0200 | <monochrom> | -O2 compiled it to "for (i=0; i<32; i++) {} c = 32;" |
| 2022-09-03 22:19:34 +0200 | <qrpnxz> | there a semicolon missing there? |
| 2022-09-03 22:19:48 +0200 | <monochrom> | Yeah |
| 2022-09-03 22:19:53 +0200 | <monochrom> | n<<=1; c++; |
| 2022-09-03 22:19:59 +0200 | <qrpnxz> | ah yeah, well it makes sense if you know math is UB in C :D |
| 2022-09-03 22:20:11 +0200 | <hpc> | kinda funny that it still keeps the loop |
| 2022-09-03 22:20:46 +0200 | <qrpnxz> | i think if you just incremented `n` it would be an infinite loop too |
| 2022-09-03 22:20:57 +0200 | <qrpnxz> | ah but it's unsigned, i forget in that case |
| 2022-09-03 22:21:36 +0200 | <monochrom> | Pretty sure if n is int the compiler can still find just cause to multilate my code. |
| 2022-09-03 22:21:37 +0200 | <qrpnxz> | wraith would know |
| 2022-09-03 22:21:58 +0200 | <monochrom> | Recently I discovered students' doofus buffer-overflowing code by just turning on -O2. |
| 2022-09-03 22:22:20 +0200 | <monochrom> | There was run time "buffer overflow detected" all over the place. |
| 2022-09-03 22:23:20 +0200 | <qrpnxz> | I wonder if there are companies out there that just run C with -O0 to avoid this kind of things. C with -O0, or -O0 with a few optimizations, is probably still pretty fast i bet. |
| 2022-09-03 22:23:59 +0200 | <monochrom> | There were also students writing "char *p; if (...) { p = something legit } else { char s[10] = "xxx"; p = s; } now deference p" |
| 2022-09-03 22:24:14 +0200 | <qrpnxz> | lol |
| 2022-09-03 22:24:14 +0200 | <monochrom> | -O2 ruined that one too. |
| 2022-09-03 22:24:32 +0200 | <qrpnxz> | i'm surprised -O0 didn't have that broken actually |
| 2022-09-03 22:25:07 +0200 | <monochrom> | If those companies don't already exist, I'm sure my students will go on to create some. |
| 2022-09-03 22:25:13 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 22:25:25 +0200 | <qrpnxz> | lol |
| 2022-09-03 22:29:12 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-09-03 22:29:45 +0200 | Guest6336 | (~andreas@cpe-76-90-84-251.socal.res.rr.com) (Remote host closed the connection) |
| 2022-09-03 22:29:57 +0200 | Andreas | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) |
| 2022-09-03 22:30:21 +0200 | Andreas | Guest7071 |
| 2022-09-03 22:31:01 +0200 | Guest7071 | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) (Client Quit) |
| 2022-09-03 22:32:44 +0200 | Hayek | (~andreas@2603-8000-cc01-3e3b-f45d-d05d-dc2d-c51a.res6.spectrum.com) |
| 2022-09-03 22:34:29 +0200 | Midjak | (~Midjak@82.66.147.146) (Read error: Connection reset by peer) |
| 2022-09-03 22:35:16 +0200 | fhn | (~fhn@2.58.185.24) |
| 2022-09-03 22:37:35 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 22:38:12 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-09-03 22:42:25 +0200 | toeffel | (~toeffel@user/toeffel) (Quit: quit) |
| 2022-09-03 22:43:38 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2022-09-03 22:44:37 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-09-03 22:55:40 +0200 | kenaryn | (~aurele@cre71-h03-89-88-44-27.dsl.sta.abo.bbox.fr) |
| 2022-09-03 22:59:05 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-09-03 23:02:40 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) |
| 2022-09-03 23:02:55 +0200 | rockymarine | (~rocky@user/rockymarine) (Ping timeout: 252 seconds) |
| 2022-09-03 23:09:55 +0200 | wonko_ | (~wjc@2a0e:1c80:2::130) (Ping timeout: 248 seconds) |
| 2022-09-03 23:09:56 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-09-03 23:13:18 +0200 | acidjnk | (~acidjnk@p200300d6e7137a072978330082d08561.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-09-03 23:14:19 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:d9e7:117d:c6bf:ca57) (Read error: Connection reset by peer) |
| 2022-09-03 23:15:44 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-09-03 23:17:38 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-09-03 23:18:43 +0200 | rburkholder | (~blurb@96.45.2.121) (Remote host closed the connection) |
| 2022-09-03 23:23:37 +0200 | <Franciman> | monochrom: how is it possible that it compiled it into an infinite loop? |
| 2022-09-03 23:23:43 +0200 | <Franciman> | it's because of UB? |
| 2022-09-03 23:28:44 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-09-03 23:31:53 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 252 seconds) |
| 2022-09-03 23:32:31 +0200 | <monochrom> | Yes. |
| 2022-09-03 23:33:07 +0200 | <monochrom> | It legit became "LABAL: jmp LABEL" |
| 2022-09-03 23:33:22 +0200 | <monochrom> | err I misspelled label heh |
| 2022-09-03 23:34:07 +0200 | <Franciman> | ahah |
| 2022-09-03 23:34:10 +0200 | <Franciman> | awesome |
| 2022-09-03 23:35:42 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-09-03 23:36:19 +0200 | <qrpnxz> | good ol C standard https://a.tmp.ninja/Dyhbjrmm.png |
| 2022-09-03 23:38:01 +0200 | <qrpnxz> | seems like for unsigned it shouldn't be infinite |
| 2022-09-03 23:38:27 +0200 | <qrpnxz> | but for signed it could be |
| 2022-09-03 23:38:50 +0200 | <Franciman> | lelling hard, tbqf |
| 2022-09-03 23:41:26 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 2022-09-03 23:43:41 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-09-03 23:55:22 +0200 | goldstein | (~goldstein@goldstein.rs) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-09-03 23:56:23 +0200 | GoldsteinQ | (~goldstein@goldstein.rs) |
