| 2024-07-21 00:09:28 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-07-21 00:09:45 +0200 | CiaoSen | (~Jura@2a05:5800:254:9700:e6b9:7aff:fe80:3d03) (Ping timeout: 252 seconds) |
| 2024-07-21 00:25:36 +0200 | squid32 | (squid64@user/squid64) |
| 2024-07-21 00:28:06 +0200 | squid32 | (squid64@user/squid64) (Client Quit) |
| 2024-07-21 00:28:19 +0200 | squid64 | (squid64@user/squid64) (Ping timeout: 245 seconds) |
| 2024-07-21 00:31:29 +0200 | ystael | (~ystael@user/ystael) |
| 2024-07-21 00:31:51 +0200 | squid64 | (squid64@user/squid64) |
| 2024-07-21 00:33:51 +0200 | squid64 | (squid64@user/squid64) (Remote host closed the connection) |
| 2024-07-21 00:37:30 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 260 seconds) |
| 2024-07-21 00:39:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 00:51:07 +0200 | xal | (~xal@mx1.xal.systems) (Quit: bye) |
| 2024-07-21 00:51:48 +0200 | squid64 | (squid64@user/squid64) |
| 2024-07-21 00:54:15 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-07-21 01:04:21 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 248 seconds) |
| 2024-07-21 01:06:58 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-21 01:07:39 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 01:12:05 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-07-21 01:12:21 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) |
| 2024-07-21 01:13:36 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-21 01:13:54 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 01:15:25 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich) |
| 2024-07-21 01:15:57 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 01:20:21 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2024-07-21 01:20:47 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) (Quit: ZNC 1.9.1+deb1 - https://znc.in) |
| 2024-07-21 01:21:51 +0200 | ash3en | (~Thunderbi@2a01:c22:888e:9900:1578:4a37:8e5e:967) |
| 2024-07-21 01:23:05 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-07-21 01:24:57 +0200 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2024-07-21 01:26:16 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 260 seconds) |
| 2024-07-21 01:26:44 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-07-21 01:28:58 +0200 | mhatta | (~mhatta@www21123ui.sakura.ne.jp) |
| 2024-07-21 01:30:44 +0200 | hiredman | (~hiredman@frontier1.downey.family) (Quit: Lost terminal) |
| 2024-07-21 01:32:10 +0200 | cayley56 | (~cayley5@user/phileasfogg) |
| 2024-07-21 01:32:19 +0200 | lambdap23710 | (~lambdap@static.167.190.119.168.clients.your-server.de) |
| 2024-07-21 01:32:23 +0200 | Lears | (~Leary@user/Leary/x-0910699) |
| 2024-07-21 01:32:36 +0200 | evanrelf_ | (3addc196af@2a03:6000:1812:100::f0) |
| 2024-07-21 01:32:37 +0200 | tnks_ | (sid412124@id-412124.helmsley.irccloud.com) |
| 2024-07-21 01:32:49 +0200 | titibandit_ | (e33ffbab65@user/titibandit) |
| 2024-07-21 01:32:49 +0200 | jleightcap_ | (7bc4014b62@user/jleightcap) |
| 2024-07-21 01:32:49 +0200 | ggb_ | (a62ffbaf4f@2a03:6000:1812:100::3ac) |
| 2024-07-21 01:32:50 +0200 | henrytill_ | (e0180937c3@2a03:6000:1812:100::e8c) |
| 2024-07-21 01:32:51 +0200 | ursa-major_ | (114efe6c39@2a03:6000:1812:100::11f3) |
| 2024-07-21 01:32:53 +0200 | aristid_ | (sid1599@id-1599.uxbridge.irccloud.com) |
| 2024-07-21 01:32:57 +0200 | edwardk_ | (sid47016@haskell/developer/edwardk) |
| 2024-07-21 01:33:02 +0200 | evanrelf | (3addc196af@2a03:6000:1812:100::f0) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:02 +0200 | ggb | (a62ffbaf4f@2a03:6000:1812:100::3ac) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:02 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:02 +0200 | evanrelf_ | evanrelf |
| 2024-07-21 01:33:02 +0200 | tnks | (sid412124@id-412124.helmsley.irccloud.com) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:02 +0200 | lambdap2371 | (~lambdap@static.167.190.119.168.clients.your-server.de) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:03 +0200 | lambdap23710 | lambdap2371 |
| 2024-07-21 01:33:03 +0200 | tnks_ | tnks |
| 2024-07-21 01:33:04 +0200 | swistak- | (~swistak@185.21.216.141) |
| 2024-07-21 01:33:04 +0200 | cayley5 | (~cayley5@user/phileasfogg) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:05 +0200 | cayley56 | cayley5 |
| 2024-07-21 01:33:06 +0200 | Fischmiep | (~Fischmiep@user/Fischmiep) (Remote host closed the connection) |
| 2024-07-21 01:33:07 +0200 | acro | (~acro@user/acro) (Quit: Bye.) |
| 2024-07-21 01:33:07 +0200 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-21 01:33:07 +0200 | tritlo_ | (sid58727@id-58727.hampstead.irccloud.com) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:08 +0200 | end | (~end@user/end/x-0094621) (Quit: end) |
| 2024-07-21 01:33:09 +0200 | constxd | (~constxd@user/constxd) (Remote host closed the connection) |
| 2024-07-21 01:33:09 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:09 +0200 | titibandit | (e33ffbab65@user/titibandit) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:09 +0200 | titibandit_ | titibandit |
| 2024-07-21 01:33:09 +0200 | catties | (~catties@user/meow/catties) (Quit: n_n) |
| 2024-07-21 01:33:09 +0200 | onliner10 | (~onliner10@user/onliner10) (Quit: ZNC 1.9.0 - https://znc.in) |
| 2024-07-21 01:33:17 +0200 | jleightcap | (7bc4014b62@user/jleightcap) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:17 +0200 | tritlo_ | (sid58727@id-58727.hampstead.irccloud.com) |
| 2024-07-21 01:33:17 +0200 | ursa-major | (114efe6c39@2a03:6000:1812:100::11f3) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:23 +0200 | constxd | (~constxd@user/constxd) |
| 2024-07-21 01:33:25 +0200 | onliner10 | (~onliner10@user/onliner10) |
| 2024-07-21 01:33:27 +0200 | jleightcap_ | jleightcap |
| 2024-07-21 01:33:28 +0200 | anpad | (~pandeyan@user/anpad) |
| 2024-07-21 01:33:29 +0200 | catties | (~catties@user/meow/catties) |
| 2024-07-21 01:33:30 +0200 | Fischmiep | (~Fischmiep@user/Fischmiep) |
| 2024-07-21 01:33:32 +0200 | gentauro | (~gentauro@user/gentauro) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:32 +0200 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:37 +0200 | ggb_ | ggb |
| 2024-07-21 01:33:41 +0200 | henrytill | (e0180937c3@2a03:6000:1812:100::e8c) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:41 +0200 | henrytill_ | henrytill |
| 2024-07-21 01:33:43 +0200 | swistak | (~swistak@185.21.216.141) (Read error: Connection reset by peer) |
| 2024-07-21 01:33:47 +0200 | gentauro | (~gentauro@user/gentauro) |
| 2024-07-21 01:33:54 +0200 | acro | (~acro@user/acro) |
| 2024-07-21 01:33:55 +0200 | comonad | (~comonad@p200300d02713750039791f6f93d07fb8.dip0.t-ipconnect.de) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:55 +0200 | kmein | (~weechat@user/kmein) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:55 +0200 | feetwind | (~mike@user/feetwind) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:55 +0200 | Hafydd | (~Hafydd@user/hafydd) (Ping timeout: 258 seconds) |
| 2024-07-21 01:33:55 +0200 | ggVGc | (~ggVGc@a.lowtech.earth) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:12 +0200 | comonad | (~comonad@p200300d02713750039791f6f93d07fb8.dip0.t-ipconnect.de) |
| 2024-07-21 01:34:13 +0200 | Hafydd | (~Hafydd@user/hafydd) |
| 2024-07-21 01:34:14 +0200 | feetwind | (~mike@user/feetwind) |
| 2024-07-21 01:34:17 +0200 | ggVGc | (~ggVGc@a.lowtech.earth) |
| 2024-07-21 01:34:18 +0200 | aristid | (sid1599@id-1599.uxbridge.irccloud.com) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:18 +0200 | micro | (~micro@user/micro) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:18 +0200 | edwardk | (sid47016@haskell/developer/edwardk) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:18 +0200 | mira | (~aranea@wireguard/contributorcat/mira) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:18 +0200 | ncf | (~n@monade.li) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:18 +0200 | aristid_ | aristid |
| 2024-07-21 01:34:18 +0200 | edwardk_ | edwardk |
| 2024-07-21 01:34:19 +0200 | kmein | (~weechat@user/kmein) |
| 2024-07-21 01:34:29 +0200 | micro | (~micro@user/micro) |
| 2024-07-21 01:34:36 +0200 | ncf | (~n@monade.li) |
| 2024-07-21 01:34:41 +0200 | riatre | (~quassel@2001:310:6000:f::5198:1) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:41 +0200 | Leary | (~Leary@user/Leary/x-0910699) (Ping timeout: 258 seconds) |
| 2024-07-21 01:34:42 +0200 | mira | (~aranea@wireguard/contributorcat/mira) |
| 2024-07-21 01:34:49 +0200 | riatre | (~quassel@2001:310:6000:f::5198:1) |
| 2024-07-21 01:35:23 +0200 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) |
| 2024-07-21 01:35:54 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) |
| 2024-07-21 01:37:07 +0200 | ursa-major_ | ursa-major |
| 2024-07-21 01:37:40 +0200 | dostoyevsky2 | (~sck@user/dostoyevsky2) (Quit: leaving) |
| 2024-07-21 01:37:44 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2024-07-21 01:38:04 +0200 | dostoyevsky2 | (~sck@user/dostoyevsky2) |
| 2024-07-21 01:40:30 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-07-21 01:41:25 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) |
| 2024-07-21 01:44:52 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-07-21 01:45:42 +0200 | end | (~end@user/end/x-0094621) |
| 2024-07-21 01:52:18 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2024-07-21 01:54:38 +0200 | <Unicorn_Princess> | trying to make my own super-basic compile-time dimensional analysis/units package. i need so very little from it that the type is just `data Quantity numerator denominator = Qty Float` |
| 2024-07-21 01:55:34 +0200 | <Unicorn_Princess> | (for brevity let's call it just Qty instead of Quantity) |
| 2024-07-21 01:57:33 +0200 | <Unicorn_Princess> | the problem is defining multiplication - my current definition is: qmul :: Qty a b -> Qty b c -> Qty a c -- i.e. a/b * b/c = a/c |
| 2024-07-21 01:58:01 +0200 | <Unicorn_Princess> | but also valid would be a/b * c/a = c/b |
| 2024-07-21 01:58:37 +0200 | <Unicorn_Princess> | but how can i have one function support both these type signatures? |
| 2024-07-21 02:00:34 +0200 | smiesner | (b0cf5acf8c@2a03:6000:1812:100::13b9) |
| 2024-07-21 02:04:40 +0200 | <Lears> | One is the other `flip`ped, so just choose one---it doesn't matter which. |
| 2024-07-21 02:04:50 +0200 | <Lears> | Better, give it a `Category` instance. |
| 2024-07-21 02:06:37 +0200 | <Unicorn_Princess> | flip would work for multiplication, albeit at slight user inconvenience, but not for division. curious about this Category thing tho, lemme look it up |
| 2024-07-21 02:07:09 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-21 02:07:20 +0200 | <Unicorn_Princess> | this thing? https://hackage.haskell.org/package/base-4.20.0.1/docs/Control-Category.html#t:Category |
| 2024-07-21 02:07:25 +0200 | <Lears> | Yes. |
| 2024-07-21 02:07:28 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 02:08:06 +0200 | <Unicorn_Princess> | thanks |
| 2024-07-21 02:08:33 +0200 | Square2 | (~Square@user/square) (Ping timeout: 252 seconds) |
| 2024-07-21 02:11:36 +0200 | <Lears> | Your needs are somewhat unclear, but I'd imagine `invert :: Qty a b -> Qty b a` and `qmul` would cover your bases for division. |
| 2024-07-21 02:16:42 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-21 02:16:53 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) |
| 2024-07-21 02:17:35 +0200 | euleritian | (~euleritia@dynamic-176-006-131-226.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-21 02:17:53 +0200 | sss | (~sss@dynamic-077-006-080-207.77.6.pool.telefonica.de) |
| 2024-07-21 02:17:58 +0200 | <sss> | hi |
| 2024-07-21 02:17:59 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 02:19:40 +0200 | ash3en | (~Thunderbi@2a01:c22:888e:9900:1578:4a37:8e5e:967) (Quit: ash3en) |
| 2024-07-21 02:21:01 +0200 | <Unicorn_Princess> | should i learn about arrows first before i go into the category typeclass? |
| 2024-07-21 02:21:54 +0200 | <Unicorn_Princess> | or is it the other way around.. |
| 2024-07-21 02:22:53 +0200 | <Lears> | You should forget Arrow exists. |
| 2024-07-21 02:23:34 +0200 | <Unicorn_Princess> | oh dear |
| 2024-07-21 02:24:19 +0200 | <Unicorn_Princess> | having a hard time finding explanations on how to use Category tho, save for https://wiki.haskell.org/Typeclassopedia#Category |
| 2024-07-21 02:26:12 +0200 | <Lears> | Probably because there's nothing much to it. It just generalises associative composition with identity. |
| 2024-07-21 02:26:32 +0200 | <Lears> | Which you have with multiplication and dimensionless 1. |
| 2024-07-21 02:26:51 +0200 | <sss> | why should one forget about arrows? |
| 2024-07-21 02:27:24 +0200 | <Lears> | Well, not "multiplication" in general, but your restricted /cancelling/ multiplication. |
| 2024-07-21 02:30:22 +0200 | <Lears> | sss: One shouldn't necessarily forget about arrows in general, just the typeclass `Arrow`. It's something of a failed abstraction, but not beyond saving---there are various modern takes on it if you really want to investigate, but I haven't found any of them too compelling. |
| 2024-07-21 02:31:17 +0200 | <ncf> | Arrow is just Strong Category (https://hackage.haskell.org/package/profunctors-5.6.2/docs/Data-Profunctor-Strong.html) |
| 2024-07-21 02:33:15 +0200 | sss | (~sss@dynamic-077-006-080-207.77.6.pool.telefonica.de) (Quit: leaving) |
| 2024-07-21 02:33:55 +0200 | sss | (~sss@dynamic-077-006-080-207.77.6.pool.telefonica.de) |
| 2024-07-21 02:34:19 +0200 | <sss> | Lears: ah I see |
| 2024-07-21 02:36:37 +0200 | squid64 | (squid64@user/squid64) (Quit: Leaving) |
| 2024-07-21 02:37:22 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 02:37:53 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit) |
| 2024-07-21 02:39:16 +0200 | squid64 | (squid64@user/squid64) |
| 2024-07-21 02:42:19 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-07-21 02:44:24 +0200 | squid64 | (squid64@user/squid64) (Quit: Leaving) |
| 2024-07-21 02:47:22 +0200 | sss | (~sss@dynamic-077-006-080-207.77.6.pool.telefonica.de) (Quit: leaving) |
| 2024-07-21 02:48:03 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-21 02:50:09 +0200 | ash3en | (~ash3en@2a01:c22:888e:9900:1578:4a37:8e5e:967) |
| 2024-07-21 02:50:51 +0200 | ash3en | (~ash3en@2a01:c22:888e:9900:1578:4a37:8e5e:967) (Remote host closed the connection) |
| 2024-07-21 03:11:22 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-07-21 03:27:03 +0200 | dysthesis | (~dysthesis@user/dysthesis) |
| 2024-07-21 03:38:26 +0200 | dysthesis | (~dysthesis@user/dysthesis) (Remote host closed the connection) |
| 2024-07-21 03:44:04 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 03:52:26 +0200 | EvanR | (~EvanR@user/evanr) (Quit: Leaving) |
| 2024-07-21 03:54:26 +0200 | EvanR | (~EvanR@user/evanr) |
| 2024-07-21 04:00:58 +0200 | kupi | (uid212005@id-212005.hampstead.irccloud.com) |
| 2024-07-21 04:05:04 +0200 | op_4 | (~tslil@user/op-4/x-9116473) (Remote host closed the connection) |
| 2024-07-21 04:05:34 +0200 | op_4 | (~tslil@user/op-4/x-9116473) |
| 2024-07-21 04:19:09 +0200 | td_ | (~td@i53870918.versanet.de) (Ping timeout: 276 seconds) |
| 2024-07-21 04:20:35 +0200 | td_ | (~td@i53870911.versanet.de) |
| 2024-07-21 04:21:22 +0200 | masui333333 | (~user@2601:646:8002:6ce0:2927:ebdb:a305:ef99) |
| 2024-07-21 04:44:12 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat) |
| 2024-07-21 04:47:06 +0200 | terrorjack | (~terrorjac@2a01:4f8:c17:87f8::) |
| 2024-07-21 05:02:26 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-79-84.fiber.dynamic.sonic.net) (Remote host closed the connection) |
| 2024-07-21 05:06:55 +0200 | Midjak | (~MarciZ@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2024-07-21 05:07:00 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-07-21 05:09:46 +0200 | masui333333 | (~user@2601:646:8002:6ce0:2927:ebdb:a305:ef99) (Remote host closed the connection) |
| 2024-07-21 05:20:50 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 05:29:40 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2024-07-21 05:33:55 +0200 | phma | (~phma@2001:5b0:210f:55a8:9fbe:3c54:a526:88c8) (Read error: Connection reset by peer) |
| 2024-07-21 05:34:19 +0200 | phma | (~phma@host-67-44-208-49.hnremote.net) |
| 2024-07-21 05:44:39 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 05:49:59 +0200 | hiredman | (~hiredman@frontier1.downey.family) |
| 2024-07-21 05:56:01 +0200 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) |
| 2024-07-21 05:59:39 +0200 | aforemny_ | (~aforemny@2001:9e8:6cd3:7e00:62f7:f9a2:3af8:50bb) |
| 2024-07-21 06:00:21 +0200 | aforemny | (~aforemny@2001:9e8:6cf3:7d00:7722:6259:6fe2:da4f) (Ping timeout: 248 seconds) |
| 2024-07-21 06:06:02 +0200 | murasaki | (~murasaki@104.234.142.145) |
| 2024-07-21 06:06:46 +0200 | murasaki | (~murasaki@104.234.142.145) (Client Quit) |
| 2024-07-21 06:07:02 +0200 | murasaki | (~murasaki@104.234.142.145) |
| 2024-07-21 06:07:23 +0200 | murasaki | (~murasaki@104.234.142.145) (Client Quit) |
| 2024-07-21 06:07:37 +0200 | murasaki | (~murasaki@104.234.142.145) |
| 2024-07-21 06:17:27 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 276 seconds) |
| 2024-07-21 06:24:03 +0200 | aaronv | (~aaronv@user/aaronv) (Remote host closed the connection) |
| 2024-07-21 06:24:22 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-07-21 06:30:40 +0200 | kupi | (uid212005@id-212005.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-21 06:36:18 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 276 seconds) |
| 2024-07-21 06:36:32 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-21 06:53:45 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds) |
| 2024-07-21 07:03:01 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 07:09:04 +0200 | aaronv | (~aaronv@user/aaronv) (Remote host closed the connection) |
| 2024-07-21 07:09:29 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-07-21 07:18:13 +0200 | img | (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-07-21 07:20:18 +0200 | img | (~img@user/img) |
| 2024-07-21 07:44:00 +0200 | mreh | (~matthew@lfbn-rou-1-646-109.w90-108.abo.wanadoo.fr) |
| 2024-07-21 07:47:40 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-07-21 07:48:05 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-07-21 07:52:20 +0200 | hiecaq | (~hiecaq@user/hiecaq) (Remote host closed the connection) |
| 2024-07-21 07:54:45 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-07-21 07:55:26 +0200 | rvalue- | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-07-21 08:14:19 +0200 | <jackdk> | Arrow is useful in some FRP contexts and in Opaleye but that's kinda about it. Many places where you might want to use Arrows hamstring you by requiring you to implement `arr`, which means you need to be able to arrow-ise arbitrary pure functions. There's some interesting work using linear functions with symmetric monoidal categories to get another take on "boxes and wires"-style diagrams, but it needs to mature a bit more. |
| 2024-07-21 08:14:29 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-07-21 08:16:20 +0200 | hiecaq | (~hiecaq@user/hiecaq) |
| 2024-07-21 08:18:37 +0200 | hiecaq | (~hiecaq@user/hiecaq) (Remote host closed the connection) |
| 2024-07-21 08:21:28 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-07-21 08:23:01 +0200 | rosco | (~rosco@175.136.155.137) |
| 2024-07-21 08:25:05 +0200 | rvalue | (~rvalue@user/rvalue) |
| 2024-07-21 08:47:11 +0200 | hiecaq | (~hiecaq@user/hiecaq) |
| 2024-07-21 09:00:02 +0200 | tt123109783 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) (Quit: The Lounge - https://thelounge.chat) |
| 2024-07-21 09:03:08 +0200 | tt123109783 | (~tt1231@2603:6010:8700:4a81:219f:50d3:618a:a6ee) |
| 2024-07-21 09:11:41 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 09:24:27 +0200 | tmr | (~tamer@5.2.74.82) (Quit: "") |
| 2024-07-21 09:28:57 +0200 | murasaki | (~murasaki@104.234.142.145) (Remote host closed the connection) |
| 2024-07-21 09:30:04 +0200 | mreh | (~matthew@lfbn-rou-1-646-109.w90-108.abo.wanadoo.fr) (Quit: Lost terminal) |
| 2024-07-21 09:36:06 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-07-21 09:37:45 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-07-21 09:56:32 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-07-21 09:57:09 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds) |
| 2024-07-21 09:57:09 +0200 | aaronv | (~aaronv@user/aaronv) (Ping timeout: 276 seconds) |
| 2024-07-21 09:57:54 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-07-21 10:05:05 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-07-21 10:08:57 +0200 | gmg | (~user@user/gehmehgeh) |
| 2024-07-21 10:11:27 +0200 | skyesoss1 | (~Thunderbi@c-73-208-45-119.hsd1.il.comcast.net) (Ping timeout: 252 seconds) |
| 2024-07-21 10:17:29 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) |
| 2024-07-21 10:28:06 +0200 | rosco | (~rosco@175.136.155.137) (Quit: Lost terminal) |
| 2024-07-21 10:34:43 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-21 10:38:34 +0200 | amisto | (~amisto@ec2-52-198-209-58.ap-northeast-1.compute.amazonaws.com) |
| 2024-07-21 10:40:05 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 260 seconds) |
| 2024-07-21 10:49:41 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-07-21 10:51:16 +0200 | amisto | (~amisto@ec2-52-198-209-58.ap-northeast-1.compute.amazonaws.com) (Quit: Client closed) |
| 2024-07-21 10:53:30 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-07-21 10:53:45 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 10:58:46 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) (Quit: ash3en) |
| 2024-07-21 10:59:01 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) |
| 2024-07-21 11:07:13 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-07-21 11:12:10 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-07-21 11:15:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 11:23:23 +0200 | Square2 | (~Square@user/square) |
| 2024-07-21 11:23:25 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 11:25:52 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-21 11:26:21 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 11:26:42 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-07-21 11:27:44 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Ping timeout: 260 seconds) |
| 2024-07-21 11:30:03 +0200 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) |
| 2024-07-21 11:31:24 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2024-07-21 11:35:44 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-07-21 11:37:29 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 245 seconds) |
| 2024-07-21 11:43:10 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-07-21 11:44:36 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-07-21 11:49:54 +0200 | tmr | (~tamer@5.2.74.82) |
| 2024-07-21 11:53:25 +0200 | xff0x | (~xff0x@2405:6580:b080:900:85a4:92a4:ce3d:c612) (Ping timeout: 248 seconds) |
| 2024-07-21 11:54:10 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2024-07-21 11:59:13 +0200 | xff0x | (~xff0x@2405:6580:b080:900:1ad7:bf8c:8156:7b85) |
| 2024-07-21 12:00:14 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-07-21 12:04:25 +0200 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) |
| 2024-07-21 12:05:10 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) |
| 2024-07-21 12:24:29 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) (Quit: oo_miguel) |
| 2024-07-21 12:24:45 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) |
| 2024-07-21 12:34:25 +0200 | Vajb | (~Vajb@n85jaspk9c2pfwcdhy6-1.v6.elisa-mobile.fi) (Ping timeout: 248 seconds) |
| 2024-07-21 12:36:01 +0200 | CiaoSen | (~Jura@2a05:5800:25c:2700:e6b9:7aff:fe80:3d03) |
| 2024-07-21 12:40:50 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) (Ping timeout: 260 seconds) |
| 2024-07-21 13:00:50 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 13:01:46 +0200 | mrmr1553343463 | (~mrmr@user/mrmr) (Quit: Bye, See ya later!) |
| 2024-07-21 13:11:08 +0200 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) (Ping timeout: 252 seconds) |
| 2024-07-21 13:14:00 +0200 | mrmr1553343463 | (~mrmr@user/mrmr) |
| 2024-07-21 13:14:39 +0200 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) |
| 2024-07-21 13:35:51 +0200 | lain` | (lain`@user/lain/x-9874679) (Remote host closed the connection) |
| 2024-07-21 13:38:07 +0200 | lain` | (lain`@user/lain/x-9874679) |
| 2024-07-21 13:39:10 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 260 seconds) |
| 2024-07-21 13:41:24 +0200 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) (Ping timeout: 276 seconds) |
| 2024-07-21 13:43:30 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-21 13:46:05 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) |
| 2024-07-21 14:00:37 +0200 | billchenchina- | (~billchenc@223.39.206.205) |
| 2024-07-21 14:03:05 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-07-21 14:04:34 +0200 | smalltalkman | (uid545680@id-545680.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-07-21 14:04:45 +0200 | euleritian | (~euleritia@dynamic-176-006-177-193.176.6.pool.telefonica.de) |
| 2024-07-21 14:05:42 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) |
| 2024-07-21 14:07:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 14:07:17 +0200 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2024-07-21 14:13:19 +0200 | euleritian | (~euleritia@dynamic-176-006-177-193.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-21 14:13:37 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-07-21 14:13:49 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-07-21 14:15:08 +0200 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) |
| 2024-07-21 14:20:33 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 14:28:10 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 260 seconds) |
| 2024-07-21 14:30:00 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) |
| 2024-07-21 14:35:31 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 260 seconds) |
| 2024-07-21 14:45:25 +0200 | kenran | (~user@user/kenran) |
| 2024-07-21 14:51:03 +0200 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2024-07-21 14:51:25 +0200 | puke | (~puke@user/puke) |
| 2024-07-21 15:00:01 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 252 seconds) |
| 2024-07-21 15:00:37 +0200 | euleritian | (~euleritia@dynamic-176-006-177-193.176.6.pool.telefonica.de) |
| 2024-07-21 15:03:31 +0200 | misterfish | (~misterfis@87.215.131.102) |
| 2024-07-21 15:03:44 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-07-21 15:06:09 +0200 | zero | zzz |
| 2024-07-21 15:11:25 +0200 | pavonia | (~user@user/siracusa) |
| 2024-07-21 15:16:46 +0200 | euleritian | (~euleritia@dynamic-176-006-177-193.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-07-21 15:17:04 +0200 | euleritian | (~euleritia@77.22.252.56) |
| 2024-07-21 15:20:57 +0200 | madhavanmiui | (~madhavanm@2409:40f4:101f:3e08:8000::) |
| 2024-07-21 15:22:16 +0200 | lain` | (lain`@user/lain/x-9874679) (Remote host closed the connection) |
| 2024-07-21 15:25:08 +0200 | lain` | (lain`@user/lain/x-9874679) |
| 2024-07-21 15:25:43 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2024-07-21 15:27:05 +0200 | madhavanmiui | (~madhavanm@2409:40f4:101f:3e08:8000::) (Remote host closed the connection) |
| 2024-07-21 15:28:03 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 15:29:52 +0200 | billchenchina- | (~billchenc@223.39.206.205) (Remote host closed the connection) |
| 2024-07-21 15:32:11 +0200 | lain` | (lain`@user/lain/x-9874679) (Remote host closed the connection) |
| 2024-07-21 15:34:02 +0200 | lain` | (lain`@user/lain/x-9874679) |
| 2024-07-21 15:39:59 +0200 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2024-07-21 15:43:23 +0200 | danza | (~francesco@151.57.181.229) |
| 2024-07-21 15:47:12 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-07-21 15:57:49 +0200 | lain` | (lain`@user/lain/x-9874679) (Ping timeout: 260 seconds) |
| 2024-07-21 16:07:18 +0200 | CrunchyFlakes | (~CrunchyFl@146.52.130.128) (Read error: Connection reset by peer) |
| 2024-07-21 16:10:06 +0200 | CrunchyFlakes | (~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) |
| 2024-07-21 16:11:04 +0200 | danza_ | (~francesco@151.57.181.229) |
| 2024-07-21 16:13:22 +0200 | danza | (~francesco@151.57.181.229) (Ping timeout: 252 seconds) |
| 2024-07-21 16:17:15 +0200 | misterfish | (~misterfis@87.215.131.102) (Ping timeout: 260 seconds) |
| 2024-07-21 16:18:43 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2024-07-21 16:19:06 +0200 | misterfish | (~misterfis@178.229.16.65) |
| 2024-07-21 16:27:38 +0200 | <zzz> | arrows are awesome, what are you talking about_ |
| 2024-07-21 16:28:27 +0200 | <Hecate> | I'm not that fond of them but perhaps I'm also not the intended audience |
| 2024-07-21 16:30:37 +0200 | danza_ | (~francesco@151.57.181.229) (Quit: Leaving) |
| 2024-07-21 16:33:45 +0200 | <zzz> | arrows remind me of how you think about control flow in array based languages |
| 2024-07-21 16:41:50 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) (Read error: Connection reset by peer) |
| 2024-07-21 17:00:45 +0200 | <EvanR> | symmetric monoidal categories are awesome |
| 2024-07-21 17:01:03 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) |
| 2024-07-21 17:01:03 +0200 | <EvanR> | then arrow jumps the shark in one place to make it not that |
| 2024-07-21 17:01:14 +0200 | <c_wraith> | as noted above, the big problem with Arrow as a class is that it requires you to implement `arr`, which means that all instances of it must contain haskell functions some way or another. |
| 2024-07-21 17:01:32 +0200 | <c_wraith> | which severely limits generality |
| 2024-07-21 17:02:54 +0200 | misterfish | (~misterfis@178.229.16.65) (Ping timeout: 276 seconds) |
| 2024-07-21 17:15:06 +0200 | noumenon | (~noumenon@113.51-175-156.customer.lyse.net) |
| 2024-07-21 17:16:03 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-07-21 17:18:57 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-21 17:32:09 +0200 | __monty__ | (~toonn@user/toonn) (Ping timeout: 276 seconds) |
| 2024-07-21 17:36:48 +0200 | <ash3en> | Can someone elaborate this?: "Because a parser combinator-based program is generally slower than a parser generator-based program, Parsec is normally used for small domain-specific languages, while Happy is used for compilers such as GHC." Where are the major or minor differences in parser combinators and parser generators? |
| 2024-07-21 17:36:50 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 17:36:50 +0200 | <ash3en> | https://en.wikipedia.org/wiki/Parsec_(parser) |
| 2024-07-21 17:36:56 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 260 seconds) |
| 2024-07-21 17:37:05 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-07-21 17:37:48 +0200 | <ash3en> | and tho Parsec is listed as a parser generator here: https://en.wikipedia.org/wiki/Category:Parser_generators and here https://en.wikipedia.org/wiki/Comparison_of_parser_generators |
| 2024-07-21 17:39:17 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2024-07-21 17:44:16 +0200 | <tomsmeding> | a "parser generator" such as happy is essentially a state machine; when compiled by a competent state machine generator and when written in such a way that the state machine executes efficiently in the target language (haskell in this case), they can be quite fast |
| 2024-07-21 17:44:56 +0200 | <tomsmeding> | Parsec is a parser combinator library and is not a "parser generator" in this sense; I would call it a parser library at most, though I can see how some people stretch the definition of "parser generator" to include parser combinator libraries |
| 2024-07-21 17:45:08 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 255 seconds) |
| 2024-07-21 17:45:35 +0200 | <tomsmeding> | parser combinator libraries (including parsec) are really nothing more than a collection of well-chosen helper functions for writing a recursive-descent parser |
| 2024-07-21 17:46:12 +0200 | <tomsmeding> | they can be approximately as fast as a recursive descent parser can be, but typically those helper functions are more general in certain way than you need, making it harder to get optimal performance |
| 2024-07-21 17:46:50 +0200 | <tomsmeding> | production-grade parsers like those in GCC and Clang (for C and C++) are recursive-descent parsers for optimal freedom in generating parse errors, and hence good quality parser errors and recovery (given sufficient engineering effort) |
| 2024-07-21 17:47:01 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-21 17:47:40 +0200 | <tomsmeding> | parsec is an abstraction over recursive-descent parsing so that it's easier and quicker to write one, but at the cost of quality of error messages (typically) and some performance |
| 2024-07-21 17:47:45 +0200 | <tomsmeding> | ash3en: hope that helps a bit |
| 2024-07-21 17:48:04 +0200 | <ash3en> | tomsmeding: thank you! so shortened recursive-descent parsers are more efficient, parser generators are more high level and paresr combinators sit somewhere in between? |
| 2024-07-21 17:48:16 +0200 | <ash3en> | it really does, tomsmeding! |
| 2024-07-21 17:49:07 +0200 | <tomsmeding> | I would say parser combinators are more high-level than parser generators like happy, because with parser generators you're bound to essentially a context-free grammar, whereas with parser combinators you can do whatever you want |
| 2024-07-21 17:49:28 +0200 | <tomsmeding> | but you could also say they aren't comparable, because some things that are easy with parser generators are harder with parser combinators, and vice-versa |
| 2024-07-21 17:50:39 +0200 | <Franciman> | is there a way to compute the shapley value of an haskell program |
| 2024-07-21 17:50:41 +0200 | <tomsmeding> | the state machine algorithms that parser generators typically use have been a classical topic for optimisation, so they can be plenty fast as well -- I'm not sure how parser generators and recursive descent compaer in terms of performance |
| 2024-07-21 17:50:47 +0200 | <Franciman> | in terms of inconsistencies? |
| 2024-07-21 17:50:55 +0200 | <tomsmeding> | ash3en: w.r.t. parser generators, a keyword for a common variant is LALR |
| 2024-07-21 17:52:05 +0200 | <monochrom> | I think the keyword is "generally", which is in the statistical sense, not the "for all" sense. |
| 2024-07-21 17:53:29 +0200 | <monochrom> | "Generally", parser combinator libraries far exceed CFG, therefore must be slower. |
| 2024-07-21 17:53:43 +0200 | <ash3en> | tomsmeding: thanks for the insights |
| 2024-07-21 17:54:40 +0200 | CiaoSen | (~Jura@2a05:5800:25c:2700:e6b9:7aff:fe80:3d03) (Ping timeout: 260 seconds) |
| 2024-07-21 17:54:54 +0200 | <ash3en> | monochrom: I have to think about this for a sec haha |
| 2024-07-21 17:57:34 +0200 | bastelfreak | (bastelfrea@libera/staff/VoxPupuli.bastelfreak) (Quit: WeeChat 4.1.0) |
| 2024-07-21 18:17:14 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 260 seconds) |
| 2024-07-21 18:17:28 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-21 18:22:06 +0200 | danza | (~francesco@151.57.161.108) |
| 2024-07-21 18:23:03 +0200 | bastelfreak | (bastelfrea@libera/staff/VoxPupuli.bastelfreak) |
| 2024-07-21 18:24:59 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) (Read error: Connection reset by peer) |
| 2024-07-21 18:35:47 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-07-21 18:37:03 +0200 | <Athas> | Hello Haskell people. In the near future, I will have to teach message passing-based concurrency using Haskell (but with principles similar to what you'd use in Erlang). Are there any good resources I should be aware of? I have written the following notes to demonstrate the kind of stuff I will want to talk about: https://github.com/diku-dk/ap-e2024-pub/blob/main/erlang.md |
| 2024-07-21 18:37:50 +0200 | Square2 | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2024-07-21 18:37:59 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 18:38:35 +0200 | <geekosaur> | aside from https://wiki.haskell.org/Cloud_Haskell? |
| 2024-07-21 18:39:05 +0200 | <Athas> | I did look at Cloud Haskell, but I discarded for a few reasons. |
| 2024-07-21 18:39:19 +0200 | <Athas> | One is that it is too complicated, and I don't need to teach production systems. It gets in the way of the concepts. |
| 2024-07-21 18:39:34 +0200 | <Athas> | Another is that the documentation isn't good enough to overcome the friction of using a production system. |
| 2024-07-21 18:43:59 +0200 | lain` | (lain`@user/lain/x-9874679) |
| 2024-07-21 18:46:31 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 18:50:00 +0200 | euleritian | (~euleritia@77.22.252.56) (Read error: Connection reset by peer) |
| 2024-07-21 18:50:42 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 18:51:26 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) |
| 2024-07-21 18:51:33 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) (Client Quit) |
| 2024-07-21 18:52:37 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-07-21 18:52:54 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) (Ping timeout: 245 seconds) |
| 2024-07-21 18:53:09 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 248 seconds) |
| 2024-07-21 18:54:02 +0200 | <srk> | Athas: ParConc is good resource https://simonmar.github.io/pages/pcph.html (you might want to talk about STM as well) |
| 2024-07-21 18:54:32 +0200 | oo_miguel | (~Thunderbi@78.10.207.46) |
| 2024-07-21 18:55:03 +0200 | <Athas> | I have considered talking about STM, if I can fit it in the curriculum, but right now my focus is on message passing, which that book doesn't talk much about. |
| 2024-07-21 18:55:33 +0200 | <srk> | Athas: in your document, you don't need explicit tail recursion but could use Control.Monad.forever |
| 2024-07-21 18:56:10 +0200 | <srk> | yeah, STM is quite generic |
| 2024-07-21 18:56:48 +0200 | <srk> | but similar patterns appear (request / response channels or t(m)vars) |
| 2024-07-21 18:57:27 +0200 | <Athas> | Control.Monad.forever means you can't shut down in response to a message. |
| 2024-07-21 18:57:40 +0200 | <Athas> | I prefer to keep it really explicit when writing teaching code, even if it does become very verbose. |
| 2024-07-21 18:58:19 +0200 | <Athas> | The better students will find concision on their own. |
| 2024-07-21 18:59:45 +0200 | <srk> | makes sense and yes you can't shut down based on message - you would need to terminate the thread. but erlang processes don't use shutdown-on-message functionality either iirc |
| 2024-07-21 19:00:35 +0200 | <Athas> | They do. |
| 2024-07-21 19:01:03 +0200 | <Athas> | Erlang processes are also just infinite loops. |
| 2024-07-21 19:01:09 +0200 | <Athas> | It's a nice operational model, really. |
| 2024-07-21 19:03:08 +0200 | mulk | (~mulk@p5b112b2e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2024-07-21 19:03:39 +0200 | <srk> | til! yes, it is, I often strugle to roll my own erlang in haskell :)) |
| 2024-07-21 19:04:36 +0200 | mulk | (~mulk@p5b112b2e.dip0.t-ipconnect.de) |
| 2024-07-21 19:05:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 19:05:50 +0200 | MadeleineSydney | (~Thunderbi@c-71-229-185-228.hsd1.co.comcast.net) (Ping timeout: 260 seconds) |
| 2024-07-21 19:09:55 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 260 seconds) |
| 2024-07-21 19:14:00 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 19:14:19 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 19:20:22 +0200 | lain` | (lain`@user/lain/x-9874679) (Ping timeout: 252 seconds) |
| 2024-07-21 19:22:51 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 19:23:01 +0200 | lain` | (lain`@user/lain/x-9874679) |
| 2024-07-21 19:25:03 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) |
| 2024-07-21 19:29:10 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 260 seconds) |
| 2024-07-21 19:29:26 +0200 | Achylles | (~Achylles@45.182.57.38) |
| 2024-07-21 19:29:57 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) (Quit: ash3en) |
| 2024-07-21 19:33:14 +0200 | <bwe> | hi! I've made some change to my code and now I encounter a stack overflow by mapping over a list; undoing the change lets the stack overflow disappear; I am basically reading htmls from sqlite and parsing them. what should I look out for to find the cause of the stack overflow? |
| 2024-07-21 19:33:40 +0200 | <bwe> | …I've tried to trace it back with ghci debugger yet to no avail. |
| 2024-07-21 19:34:14 +0200 | <geekosaur> | stack overflows are often (usually?) caused by left recursion |
| 2024-07-21 19:34:55 +0200 | <geekosaur> | that is, a function invokes itself (possibly intending recursion) before doing anything else |
| 2024-07-21 19:35:44 +0200 | <bwe> | …then I should be able to count the function calls with the profiler and see the culprit? |
| 2024-07-21 19:36:07 +0200 | AlexZenon | (~alzenon@94.233.241.102) (Ping timeout: 252 seconds) |
| 2024-07-21 19:36:22 +0200 | <geekosaur> | hopefully |
| 2024-07-21 19:37:07 +0200 | danza | (~francesco@151.57.161.108) (Quit: life calls) |
| 2024-07-21 19:37:46 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-07-21 19:37:58 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2024-07-21 19:38:35 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-07-21 19:38:45 +0200 | <bwe> | should I be able to trace it with ghci debugger? |
| 2024-07-21 19:40:01 +0200 | <geekosaur> | probably not |
| 2024-07-21 19:40:54 +0200 | <geekosaur> | the ghci debugger relies on the code allowing it to take control at some point, but this kind of recursion ends up being an uninterruptible loop |
| 2024-07-21 19:41:01 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) |
| 2024-07-21 19:41:30 +0200 | ash3en | (~Thunderbi@2a01:c22:8d6b:b900:2b29:c04c:3cab:7f93) (Client Quit) |
| 2024-07-21 19:41:47 +0200 | <geekosaur> | theoretically a STG-level debugger would work, but (a) there isn't one (at least, not one usable with ghc) (b) it'd be kinda horrid to use |
| 2024-07-21 19:43:06 +0200 | <dmj`> | geekosaur: there's an STG debugger |
| 2024-07-21 19:43:27 +0200 | <geekosaur> | the one with STGi? doesn't work with ghc, which was the point of my parentetical |
| 2024-07-21 19:44:12 +0200 | <dmj`> | https://github.com/haskell-debugger/haskell-estgi-debugger this one is GHC compatible |
| 2024-07-21 19:44:47 +0200 | <geekosaur> | huh |
| 2024-07-21 19:44:50 +0200 | <dmj`> | it passes like over 70% of GHC's tests |
| 2024-07-21 19:45:22 +0200 | <dmj`> | geekosaur: ? |
| 2024-07-21 19:46:01 +0200 | <geekosaur> | I've been trying to keep an eye on developments in STGI-land but apparently missed that 😞 |
| 2024-07-21 19:46:31 +0200 | <dmj`> | geekosaur: hasn't been advertised much tbh |
| 2024-07-21 19:46:42 +0200 | <monochrom> | Athas: MVar counts as message passing but very bounded queue (max length 1) >:). If you want unlimited length, can just use MChan or TChan. |
| 2024-07-21 19:46:57 +0200 | <monochrom> | or TQueue etc. |
| 2024-07-21 19:47:48 +0200 | <Athas> | monochrom: I use Control.Concurrent.Chan, and mostly because it's in base. |
| 2024-07-21 19:47:57 +0200 | <monochrom> | Yeah that works. |
| 2024-07-21 19:48:15 +0200 | <monochrom> | Oh! s/MChan/Chan/ heh, they never called it MChan. |
| 2024-07-21 19:48:25 +0200 | <geekosaur> | I was wondering… |
| 2024-07-21 19:48:40 +0200 | <dmj`> | geekosaur: it has a haskell implementation of the RTS too, includes a GC, scheduler, STM, most primops |
| 2024-07-21 19:49:16 +0200 | <geekosaur> | yeh, I looked it over quickly and I think I want to add that to my vscode setup 🙂 |
| 2024-07-21 19:52:11 +0200 | <dmj`> | it's pretty cool, the STG syntax was altered so it looks monadic, but its very hard to map it back to the surface level haskell syntax |
| 2024-07-21 19:52:47 +0200 | <dmj`> | also, you'd need a GHC plugin to dump the IRs during builld time so the debugger can find them, or you might have to use the ghc fork |
| 2024-07-21 19:52:52 +0200 | AlexZenon | (~alzenon@94.233.241.102) |
| 2024-07-21 19:53:10 +0200 | <monochrom> | Influenced by my thesis supervisor, I prefer messages instead of shared vars for concurrency, too. :) |
| 2024-07-21 19:54:20 +0200 | <geekosaur> | in my case, I blame Tanenbaum (OSDI featuring Minix) |
| 2024-07-21 19:55:06 +0200 | <monochrom> | But I guess that influence traces back to Hoare and/or Milner, e.g., CSP = [easy-to-reason-about algebra of] concurrent sequential processes = locally sequential, exchange messages with others. |
| 2024-07-21 19:56:07 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb2038b483e43bd9e2b7.dip0.t-ipconnect.de) |
| 2024-07-21 19:56:32 +0200 | <monochrom> | To some extent, imperative : functional :: shared vars : CSP or CCS or generally message passing |
| 2024-07-21 19:56:48 +0200 | <stefan-__> | any idea why an IHaskell kernel crashes with: 'ihaskell: No entry for "ld supports response files" in "~/.ghcup/ghc/9.6.4/lib/ghc-9.6.4/lib/settings"' ? |
| 2024-07-21 19:57:12 +0200 | <monochrom> | We know the right is the moral thing to do but the left is more obvious to people who are oh-so-close-to-bare-metal. |
| 2024-07-21 19:57:45 +0200 | <monochrom> | hell, s/more obvious/first instinct/ # and first instincts are usually wrong |
| 2024-07-21 19:58:15 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 19:58:45 +0200 | <monochrom> | Someone needs to copy Backus and write "can concurrent programming be liberated from the von-Neumann SMP model?" >:) |
| 2024-07-21 19:59:06 +0200 | <geekosaur> | stefan-__, I don't see that entry in 9.6.5 or 9.6.6 settings files either |
| 2024-07-21 20:00:01 +0200 | <geekosaur> | it's not in 9.4.8 either |
| 2024-07-21 20:00:26 +0200 | <Athas> | You can implement shared variables in terms of message passing and get the worst of all worlds. |
| 2024-07-21 20:00:34 +0200 | <Athas> | What, after call, is an IORef but a stateful process? |
| 2024-07-21 20:00:40 +0200 | <monochrom> | That's what my supervisor says too :) |
| 2024-07-21 20:01:23 +0200 | <stefan-__> | geekosaur: could it be a mismatch with ghc from ghcup and the ghc version IHaskell has been compiled with via stack? (I tried to match both versions) |
| 2024-07-21 20:01:58 +0200 | <geekosaur> | possibly, but seems unlikely |
| 2024-07-21 20:02:12 +0200 | <geekosaur> | that said, I don't use stack so my references are all ghcup installs |
| 2024-07-21 20:04:39 +0200 | misterfish | (~misterfis@84.53.85.146) |
| 2024-07-21 20:05:09 +0200 | <stefan-__> | geekosaur: grml, after matching the ghc versions and recompiling+installing IHaskell, I didnt do a "ihaskell install --stack", doing this fixed it :) |
| 2024-07-21 20:08:28 +0200 | smiesner | (b0cf5acf8c@2a03:6000:1812:100::13b9) (Remote host closed the connection) |
| 2024-07-21 20:14:59 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 255 seconds) |
| 2024-07-21 20:15:26 +0200 | puke | Guest327 |
| 2024-07-21 20:15:26 +0200 | pyooque | (~puke@user/puke) |
| 2024-07-21 20:15:26 +0200 | Guest327 | (~puke@user/puke) (Killed (erbium.libera.chat (Nickname regained by services))) |
| 2024-07-21 20:15:26 +0200 | pyooque | puke |
| 2024-07-21 20:17:15 +0200 | <[exa]> | is there some canonical tutorial for doing Generic instances for usual "convert&serialize" stuff? I managed to copy from aeson and from one SO post, but the ride wasn't very guided. So thought I could have a look to improve on things |
| 2024-07-21 20:17:49 +0200 | <[exa]> | s/Generic/Generic-using/ |
| 2024-07-21 20:19:15 +0200 | <dmj`> | there used to be a ghc generics zoo tutorial somewhere |
| 2024-07-21 20:19:32 +0200 | <dmj`> | or just examples of different generic deriving |
| 2024-07-21 20:19:52 +0200 | <dmj`> | https://www.stephendiehl.com/posts/generics.html |
| 2024-07-21 20:20:31 +0200 | smiesner | (b0cf5acf8c@2a03:6000:1812:100::13b9) |
| 2024-07-21 20:20:47 +0200 | <dmj`> | D is for data type, C is for constructor, S is for selector,. + is sum, * is product, etc. |
| 2024-07-21 20:21:49 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) |
| 2024-07-21 20:23:21 +0200 | Square2 | (~Square@user/square) |
| 2024-07-21 20:25:07 +0200 | <[exa]> | yeah that's okish, I was more confused about how to arrange the typeclasses |
| 2024-07-21 20:25:21 +0200 | <davean> | I mean there is also the GHC manual? |
| 2024-07-21 20:25:37 +0200 | <[exa]> | but yeah sdiehl one does it, thanks! |
| 2024-07-21 20:26:17 +0200 | <davean> | https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/generics.html |
| 2024-07-21 20:26:21 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) |
| 2024-07-21 20:26:24 +0200 | <[exa]> | uoooh the manual I missed completely, it even has the section there |
| 2024-07-21 20:26:27 +0200 | <[exa]> | very good to know |
| 2024-07-21 20:26:38 +0200 | <davean> | the manual is *always* where the detailed explanation is |
| 2024-07-21 20:26:44 +0200 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 260 seconds) |
| 2024-07-21 20:26:51 +0200 | <davean> | *always* |
| 2024-07-21 20:26:59 +0200 | <davean> | I do not get why people do not read it :( |
| 2024-07-21 20:28:02 +0200 | <davean> | I actually think Generics is one of the worst manual sections though |
| 2024-07-21 20:28:24 +0200 | <davean> | Its one of the few manual sections that leaves important details to a reference :( |
| 2024-07-21 20:29:23 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 20:30:07 +0200 | <bwe> | geekosaur: recompiled with profiling on; however cabal run my-app -- -p does not create a .hp file |
| 2024-07-21 20:30:28 +0200 | <bwe> | (nor .prof file) |
| 2024-07-21 20:30:37 +0200 | <haskellbridge> | <sm> people forget the tools have good manuals/user guides (maybe because not all tools do). We could do more to promote them and make them easier to consult, eg from the tools themselves. |
| 2024-07-21 20:33:41 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 252 seconds) |
| 2024-07-21 20:35:02 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-07-21 20:36:51 +0200 | aaronv | (~aaronv@user/aaronv) (Remote host closed the connection) |
| 2024-07-21 20:36:58 +0200 | <tomsmeding> | bwe: cabal run --enable-profiling my-app -- +RTS -p |
| 2024-07-21 20:37:13 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-07-21 20:37:17 +0200 | <tomsmeding> | (the --enable-profiling is unnecessary if you have 'profiling: True' in cabal.project or similar) |
| 2024-07-21 20:38:06 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2024-07-21 20:40:26 +0200 | tomku | (~tomku@user/tomku) |
| 2024-07-21 20:41:32 +0200 | <bwe> | tomsmeding: ok, that makes sense now and is better: my-app.prof gets created, however remains during execution at size of 0. |
| 2024-07-21 20:41:55 +0200 | <geekosaur> | yes, in general the profile isn't actually output until the program exits |
| 2024-07-21 20:42:06 +0200 | <bwe> | tomsmeding: I want to find the left recursion that is causing the stack overflow. |
| 2024-07-21 20:42:20 +0200 | <tomsmeding> | I probably missed the point of the previous discussion, but what about adding some Debug.Trace.trace calls? |
| 2024-07-21 20:42:28 +0200 | <geekosaur> | it used to be the case that some kind of normal exit was required for it to be written; I know that was changed for signal handlers, I'm not sure about exceptions |
| 2024-07-21 20:43:45 +0200 | <bwe> | geekosaur: so, is there any special option to let it write the .prof during execution? |
| 2024-07-21 20:46:02 +0200 | sawilagar | (~sawilagar@user/sawilagar) |
| 2024-07-21 20:46:30 +0200 | <geekosaur> | I think you need to switch to profiling via events instead of a .prof file |
| 2024-07-21 20:48:10 +0200 | <geekosaur> | https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/profiling.html#eventlog-profile-format |
| 2024-07-21 20:48:31 +0200 | <geekosaur> | that particular section doesn't say much but points to a section detailing the event log |
| 2024-07-21 20:48:53 +0200 | <geekosaur> | and there are RTS options controlling generation and output to the event log |
| 2024-07-21 20:52:47 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 255 seconds) |
| 2024-07-21 20:53:21 +0200 | tomsmeding | . o O ( Debug.Trace has never failed me ) |
| 2024-07-21 20:53:26 +0200 | destituion | (~destituio@83-243-191-191.fth.tafjordconnect.net) |
| 2024-07-21 20:54:04 +0200 | <geekosaur> | I still want `ctcr` for Haskell |
| 2024-07-21 20:54:48 +0200 | <bwe> | I've generated a html with eventlog2html. It's no help. It shows only under heap some diagram. no insight as to which function is running a circular loop. |
| 2024-07-21 20:55:04 +0200 | <bwe> | +RTS -l -hc as parameters |
| 2024-07-21 20:55:17 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 20:55:24 +0200 | aaronv | (~aaronv@user/aaronv) (Remote host closed the connection) |
| 2024-07-21 20:55:43 +0200 | aaronv | (~aaronv@user/aaronv) |
| 2024-07-21 20:55:46 +0200 | <bwe> | Can't I just break the execution with ctrl+c somehow and look at which location code execution stopped? in case of a loop I should be at the loop then. |
| 2024-07-21 20:56:13 +0200 | <c_wraith> | you might be able to get the ghci debugger to give you that info. I think it supports that. |
| 2024-07-21 20:56:16 +0200 | <bwe> | tomsmeding: I hear you :). Where to put them? It might be obvious for you but not for me... |
| 2024-07-21 20:56:44 +0200 | <tomsmeding> | at entry to every function that is potentially in the loop :p |
| 2024-07-21 20:56:53 +0200 | <sprout> | printf |
| 2024-07-21 20:57:05 +0200 | <tomsmeding> | hm, have you tried putting HasCallStack => on a bunch of functions and running with `+RTS -xc`? |
| 2024-07-21 20:57:13 +0200 | <tomsmeding> | maybe the HasCallStack is not even necessary |
| 2024-07-21 20:57:19 +0200 | <tomsmeding> | -xc will print tracebacks on exceptions |
| 2024-07-21 20:57:35 +0200 | <tomsmeding> | without HasCallStack the tracebacks will be very short, typically unusably short |
| 2024-07-21 20:57:42 +0200 | <tomsmeding> | but maybe you're lucky |
| 2024-07-21 20:57:43 +0200 | Achylles | (~Achylles@45.182.57.38) (Quit: Leaving) |
| 2024-07-21 20:58:06 +0200 | <tomsmeding> | maybe it even shows a traceback on Ctrl+C! |
| 2024-07-21 20:58:22 +0200 | <c_wraith> | honestly, it's usually faster to just find the place where you're using a value in its own definition incorrectly by inspection |
| 2024-07-21 20:59:09 +0200 | <geekosaur> | hm, eventlog doesn't seem to log function entry |
| 2024-07-21 20:59:38 +0200 | esph | (~weechat@user/esph) (Ping timeout: 258 seconds) |
| 2024-07-21 20:59:40 +0200 | <c_wraith> | does it log cost center entry? |
| 2024-07-21 21:00:14 +0200 | <geekosaur> | tbh I think I'd just annotate function entries with `trace` |
| 2024-07-21 21:00:27 +0200 | <geekosaur> | I'm uncertain, it might be https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/eventlog-formats.html#cost-centre-break-… |
| 2024-07-21 21:01:26 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 21:01:55 +0200 | <geekosaur> | hack to trace function entries https://paste.tomsmeding.com/mF5Mg7as |
| 2024-07-21 21:02:33 +0200 | <geekosaur> | unlike profiling or (usually) the event log, this will be streamed because `stderr` is usually unbuffered |
| 2024-07-21 21:03:22 +0200 | <tomsmeding> | I feel like that guard trick should just be there in the Debug.Trace docs |
| 2024-07-21 21:03:56 +0200 | <tomsmeding> | it's too useful and perhaps just a little to weird to think up if you haven't seen it before |
| 2024-07-21 21:04:17 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 21:04:19 +0200 | <tomsmeding> | *too weird |
| 2024-07-21 21:05:20 +0200 | <tomsmeding> | bwe: ^ |
| 2024-07-21 21:06:52 +0200 | <bwe> | tomsmeding: `+RTS -xc` is running now |
| 2024-07-21 21:08:18 +0200 | <bwe> | tomsmeding: https://paste.tomsmeding.com/lgbxw2Mg |
| 2024-07-21 21:08:54 +0200 | <bwe> | geekosaur: It appears to be the utf8 unicode function you supported me in the last days. |
| 2024-07-21 21:09:07 +0200 | <tomsmeding> | told you the stack trace would be too short |
| 2024-07-21 21:09:31 +0200 | <tomsmeding> | bwe: beware that even if the stack overflow happens in some function f, f might not itself loop |
| 2024-07-21 21:09:45 +0200 | <tomsmeding> | it may be that in every iteration of the loop, f is called, f returns, and then the loop continues |
| 2024-07-21 21:09:46 +0200 | <bwe> | geekosaur: https://paste.tomsmeding.com/E5eZqA1Y |
| 2024-07-21 21:09:58 +0200 | <bwe> | tomsmeding: I've added the HasCallStack :) |
| 2024-07-21 21:10:13 +0200 | <bwe> | (I pasted only an excerpt) |
| 2024-07-21 21:10:36 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-07-21 21:13:50 +0200 | <geekosaur> | hm. there's no particular reason that should loop, unless it's the function calling utf8OrLatin1ToText that's looping |
| 2024-07-21 21:13:54 +0200 | target_i | (~target_i@user/target-i/x-6023099) |
| 2024-07-21 21:14:22 +0200 | <geekosaur> | (or there's a bug in `text` but one would think someone else would have run into it by now; it's very heavily used) |
| 2024-07-21 21:14:43 +0200 | <c_wraith> | it can loop if bs is a bottom |
| 2024-07-21 21:14:48 +0200 | <c_wraith> | and that's the most likely |
| 2024-07-21 21:14:49 +0200 | <monochrom> | I teach my students the guard trick too. :) |
| 2024-07-21 21:15:06 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 276 seconds) |
| 2024-07-21 21:15:39 +0200 | <bwe> | c_wraith: can you elaborate, bs is a bottom? |
| 2024-07-21 21:15:58 +0200 | <tomsmeding> | c_wraith: then bs itself would loop, not this function, right? |
| 2024-07-21 21:16:10 +0200 | <c_wraith> | yes, but if this is the only place forcing bs.. |
| 2024-07-21 21:16:22 +0200 | <tomsmeding> | then still this function should not be at the top of the call stack |
| 2024-07-21 21:16:30 +0200 | <tomsmeding> | whatever produced bs should be |
| 2024-07-21 21:16:48 +0200 | <bwe> | (bs is html) |
| 2024-07-21 21:17:45 +0200 | <tomsmeding> | bwe: what if you put two traces at the start of this function: first say "entered foo", then with a second trace print the length of bs |
| 2024-07-21 21:17:47 +0200 | <bwe> | tomsmeding: how can I further trace it down to the actual thing that loops? it makes no sense to me that the utf8OrLatin1ToText is causing it. |
| 2024-07-21 21:17:59 +0200 | <tomsmeding> | s/foo/utf8OrLatin1ToText |
| 2024-07-21 21:18:18 +0200 | <tomsmeding> | if this function indeed loops, then you should see both many times |
| 2024-07-21 21:18:31 +0200 | <tomsmeding> | if the evaluation of bs loops, then you should see a stack overflow after the first trace |
| 2024-07-21 21:18:47 +0200 | <tomsmeding> | if the problem is not actually here, you should see both perhaps a few times and that's it |
| 2024-07-21 21:19:08 +0200 | <tomsmeding> | though if you see both many times it might still mean that the looping function calls this as a subroutine |
| 2024-07-21 21:20:00 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 260 seconds) |
| 2024-07-21 21:20:44 +0200 | <bwe> | tomsmeding: where would you like me to put the second trace? https://paste.tomsmeding.com/7XMCQfKf |
| 2024-07-21 21:21:08 +0200 | CiaoSen | (~Jura@2a05:5800:25c:2700:e6b9:7aff:fe80:3d03) |
| 2024-07-21 21:22:10 +0200 | <tomsmeding> | bwe: https://paste.tomsmeding.com/Lkz6i32O |
| 2024-07-21 21:22:26 +0200 | <tomsmeding> | oh BL, not BS |
| 2024-07-21 21:23:21 +0200 | <bwe> | tomsmeding: fixed |
| 2024-07-21 21:24:22 +0200 | <bwe> | here we go: https://paste.tomsmeding.com/g9j6YrPp |
| 2024-07-21 21:24:36 +0200 | <tomsmeding> | looking good |
| 2024-07-21 21:24:37 +0200 | <bwe> | it does not emit any new line after the one with 166 |
| 2024-07-21 21:24:51 +0200 | <tomsmeding> | any "entered" lines? |
| 2024-07-21 21:25:37 +0200 | <bwe> | only a single one right after the executable starts |
| 2024-07-21 21:25:45 +0200 | <tomsmeding> | oh meh |
| 2024-07-21 21:26:19 +0200 | <bwe> | decode "oh meh" pls :) |
| 2024-07-21 21:27:09 +0200 | <tomsmeding> | bwe: what if you do this https://paste.tomsmeding.com/zSj7QRhh |
| 2024-07-21 21:27:40 +0200 | <tomsmeding> | "oh meh" was "my trace trick didn't work, laziness was too clever" |
| 2024-07-21 21:27:51 +0200 | <tomsmeding> | I'm now trying to out-clever laziness |
| 2024-07-21 21:28:47 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 21:29:16 +0200 | <bwe> | c_wraith: I don't see anything that gives me the slightest idea of how to manually break the program with ghci at the loop and see the location then: https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/ghci.html#tracing-and-history -- is there? |
| 2024-07-21 21:29:42 +0200 | <bwe> | tomsmeding: laziness outclevered you :0 |
| 2024-07-21 21:29:57 +0200 | <bwe> | (same output, only single entered…) |
| 2024-07-21 21:31:40 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-07-21 21:31:52 +0200 | <c_wraith> | I still don't understand why you haven't just found it by inspecting the diff between the previously working code and the refactored broken code |
| 2024-07-21 21:34:08 +0200 | <tomsmeding> | bwe: add {-# OPTIONS -fno-full-laziness #-} to the top of the file containing this function, then you can also undo the entermsg trick |
| 2024-07-21 21:34:37 +0200 | <tomsmeding> | (if we can't outsmart laziness, let's disable it) |
| 2024-07-21 21:34:46 +0200 | <tomsmeding> | (partly) |
| 2024-07-21 21:35:29 +0200 | <tomsmeding> | bwe: how large is the diff between the working and non-working version of your code (re c_wraith's comment) |
| 2024-07-21 21:36:25 +0200 | <bwe> | c_wraith: Me neither. |
| 2024-07-21 21:37:05 +0200 | <bwe> | c_wraith: I went through the code by inspection already without success. Now adding traces to the functions I changed / created. |
| 2024-07-21 21:37:13 +0200 | <bwe> | tomsmeding: Didn't change a bit. |
| 2024-07-21 21:37:33 +0200 | <bwe> | tomsmeding: Let me double check. |
| 2024-07-21 21:37:52 +0200 | <tomsmeding> | https://play.haskell.org/saved/4ydRiXrh |
| 2024-07-21 21:39:08 +0200 | <bwe> | tomsmeding: https://paste.tomsmeding.com/PXv5sukl |
| 2024-07-21 21:40:30 +0200 | <tomsmeding> | add two more traces after the length one, one with `show (decodeUtf8' bs)` and one with `show (decodeLatin1 bs)` |
| 2024-07-21 21:40:52 +0200 | <tomsmeding> | likely you'll just see a pair of those for every call as well, meaning that the problem is not here |
| 2024-07-21 21:48:43 +0200 | <bwe> | I've found the two functions that are calling each other! |
| 2024-07-21 21:48:49 +0200 | <tomsmeding> | indefinitely? |
| 2024-07-21 21:48:54 +0200 | <bwe> | tomsmeding: It's not the decodeUtf8 |
| 2024-07-21 21:49:16 +0200 | <bwe> | tomsmeding: I've put a trace in each of them and they alternate once the loop is happening. |
| 2024-07-21 21:49:23 +0200 | <tomsmeding> | great |
| 2024-07-21 21:49:51 +0200 | <bwe> | c_wraith: thanks for re-inviting me into the manual inspection. and thanks to tomsmeding for the trace idea. I value this from hereon! |
| 2024-07-21 21:50:30 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2024-07-21 21:50:56 +0200 | <bwe> | I deeply miss a writeup of how experienced Haskellers debug their problems, like a cookbook. that wisdom seems to be buried in your heads - or did I miss a treasure trove online? |
| 2024-07-21 21:51:52 +0200 | <tomsmeding> | I don't think you missed anything |
| 2024-07-21 21:51:57 +0200 | puke | Guest3837 |
| 2024-07-21 21:51:57 +0200 | pyooque | (~puke@user/puke) |
| 2024-07-21 21:51:57 +0200 | Guest3837 | (~puke@user/puke) (Killed (copper.libera.chat (Nickname regained by services))) |
| 2024-07-21 21:51:57 +0200 | pyooque | puke |
| 2024-07-21 21:52:43 +0200 | ashleyNeedsAdvic | (~ashleyNee@216.209.150.45) |
| 2024-07-21 21:52:45 +0200 | <tomsmeding> | there are apparently some notes on using ghci for debugging loops here https://wiki.haskell.org/Debugging#Infinite_loops |
| 2024-07-21 21:52:54 +0200 | <tomsmeding> | (not sure how well that works in practice) |
| 2024-07-21 21:53:12 +0200 | puke | (~puke@user/puke) (Max SendQ exceeded) |
| 2024-07-21 21:53:58 +0200 | ashleyNeedsAdvic | (~ashleyNee@216.209.150.45) (Write error: Broken pipe) |
| 2024-07-21 21:54:22 +0200 | cassiopea | (~cassiopea@user/cassiopea) (Ping timeout: 252 seconds) |
| 2024-07-21 21:54:25 +0200 | puke | (~puke@user/puke) |
| 2024-07-21 21:55:09 +0200 | phma | (~phma@host-67-44-208-49.hnremote.net) (Read error: Connection reset by peer) |
| 2024-07-21 21:55:39 +0200 | puke | (~puke@user/puke) (Max SendQ exceeded) |
| 2024-07-21 21:56:12 +0200 | phma | (~phma@2001:5b0:212a:d468:e9b2:3bc1:1a12:92a8) |
| 2024-07-21 21:56:47 +0200 | <bwe> | tomsmeding: that was the thing I was doing and not getting any further, I got misled by the decode functions there… |
| 2024-07-21 21:56:55 +0200 | puke | (~puke@user/puke) |
| 2024-07-21 21:57:18 +0200 | <tomsmeding> | ah :) |
| 2024-07-21 21:57:41 +0200 | tomsmeding | is glad that the poor man's method of trace debugging still wins out |
| 2024-07-21 21:57:49 +0200 | tomsmeding | has rarely done anything else |
| 2024-07-21 21:59:01 +0200 | <Rembane> | I love that when things become a bit more complex, trace debugging is the only thing working |
| 2024-07-21 21:59:53 +0200 | smiesner | (b0cf5acf8c@2a03:6000:1812:100::13b9) (Changing host) |
| 2024-07-21 21:59:53 +0200 | smiesner | (b0cf5acf8c@user/smiesner) |
| 2024-07-21 22:02:20 +0200 | <bwe> | tomsmeding: Actually I recently felt like such a thing to print some stuff without IO…and am glad for learning about trace this way. |
| 2024-07-21 22:02:39 +0200 | <tomsmeding> | it's a bit difficult to handle in haskell sometimes because of laziness |
| 2024-07-21 22:02:48 +0200 | <tomsmeding> | but printf debugging still reigns |
| 2024-07-21 22:03:03 +0200 | <haskellbridge> | <mauke> "a refreshing desert in the oasis of referential transparency" |
| 2024-07-21 22:03:51 +0200 | <bwe> | tomsmeding: and the beauty is that I don't need to do profiling if I can resort to trace. |
| 2024-07-21 22:03:59 +0200 | <monochrom> | Not convinced "cookbook" is the right metphor for debugging. More like "repair manual". |
| 2024-07-21 22:04:13 +0200 | <bwe> | tomsmeding: now you make me interested in printf |
| 2024-07-21 22:04:28 +0200 | <bwe> | monochrom: of course. |
| 2024-07-21 22:04:41 +0200 | <tomsmeding> | ("printf debugging" is the name for this in C land, where the standard printing function is called 'printf') |
| 2024-07-21 22:04:52 +0200 | <tomsmeding> | (C is older than Haskell, so "printf debugging" stuck) |
| 2024-07-21 22:05:26 +0200 | <monochrom> | Like, if your cake comes out overburned, bitter, dry, and unfinished, a cookbook doesn't tell you how to repair the cake, a cookbook tells you "throw that away, now follow these proper steps properly to make a new one". |
| 2024-07-21 22:05:57 +0200 | <tomsmeding> | given reality, though, a cookbook for software had better teach you how to fix your software |
| 2024-07-21 22:07:01 +0200 | <__monty__> | I do wish I was skilled at the use of the GHCi debugger. It's probably a lot more ergonomic than adding trace calls in a bunch of places and generating yourself a ridiculously long log of things to sift through. |
| 2024-07-21 22:07:37 +0200 | <monochrom> | I do not always believe in ESR's bazaar model "release early, release often". However, debug early, debug often is always right. |
| 2024-07-21 22:07:38 +0200 | <bwe> | how much of your time in % do you spend on repairing? |
| 2024-07-21 22:08:11 +0200 | <monochrom> | I have never needed to debug my own 1000-line code because I never waited that long before testing. |
| 2024-07-21 22:08:50 +0200 | <bwe> | btw would rust detect the cause of the loop automagically or would I need to find it on my own? |
| 2024-07-21 22:09:08 +0200 | <geekosaur> | didn't Ritchie say something about more time spent debugging than writing code? |
| 2024-07-21 22:10:08 +0200 | <tomsmeding> | bwe: if it was a "value is defined in terms of itself" loop, then any non-lazy language would detect that |
| 2024-07-21 22:10:11 +0200 | <bwe> | so why no one writes those repair books? |
| 2024-07-21 22:10:28 +0200 | <bwe> | tomsmeding: so, laziness is the root of all evil? |
| 2024-07-21 22:10:31 +0200 | <tomsmeding> | if it was an "infinite recursion" loop, only languages with a termination checker such as Agda detect that -- at a price |
| 2024-07-21 22:10:32 +0200 | <monochrom> | Economics. |
| 2024-07-21 22:10:54 +0200 | <tomsmeding> | bwe: laziness has advantages and disadvantages |
| 2024-07-21 22:11:03 +0200 | <bwe> | tomsmeding: but still, I'd then need only a switch (turn all laziness off), then Haskell would find that, too? |
| 2024-07-21 22:11:05 +0200 | <tomsmeding> | it is also the root of a lot of good things |
| 2024-07-21 22:11:18 +0200 | <tomsmeding> | that's called {-# LANGUAGE Strict #-}, though it's not perfect |
| 2024-07-21 22:11:24 +0200 | <bwe> | I'd just turn that on if I am debugging a loop :) |
| 2024-07-21 22:11:26 +0200 | <tomsmeding> | (and only applies to that module) |
| 2024-07-21 22:11:41 +0200 | <tomsmeding> | it essentially adds lots of bang patterns everywhere |
| 2024-07-21 22:11:43 +0200 | <bwe> | tomsmeding: but Haskell is then not telling me about the loopV? |
| 2024-07-21 22:12:01 +0200 | <monochrom> | If you don't understand laziness than you don't understand Strict either. |
| 2024-07-21 22:12:04 +0200 | <tomsmeding> | bwe: if you really define a value directly in terms of itself, the runtime system will complain |
| 2024-07-21 22:12:10 +0200 | <tomsmeding> | % let x = x :: Int in x |
| 2024-07-21 22:12:12 +0200 | <yahb2> | <timeout> |
| 2024-07-21 22:12:14 +0200 | <tomsmeding> | oh |
| 2024-07-21 22:12:18 +0200 | <tomsmeding> | okay with optimisations then |
| 2024-07-21 22:12:23 +0200 | <tomsmeding> | ("<<loop>>") |
| 2024-07-21 22:12:29 +0200 | <monochrom> | here "understand" means you can make right-on predictions. |
| 2024-07-21 22:12:42 +0200 | <tomsmeding> | right, -XStrict is almost never what you want |
| 2024-07-21 22:12:42 +0200 | <haskellbridge> | <sm> __monty__: I don't think it is. Keep in mind you can insert and move tactical trace calls while reloading with ghci[d] |
| 2024-07-21 22:13:35 +0200 | <bwe> | tomsmeding: but two functions calling each other like in my case? |
| 2024-07-21 22:13:49 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 244 seconds) |
| 2024-07-21 22:14:03 +0200 | <bwe> | also, on debugging what bugs me is the absence of hot reloading |
| 2024-07-21 22:14:08 +0200 | <geekosaur> | I don't think anything can help with that, really |
| 2024-07-21 22:14:09 +0200 | <tomsmeding> | there are many cases of mutual recursion that are perfectly fine |
| 2024-07-21 22:14:09 +0200 | <monochrom> | But last time I had to debug someone else's code, I found that working backwards works better. |
| 2024-07-21 22:14:24 +0200 | <bwe> | I need to re run half of the history in ghci after I changed a bit on my code. |
| 2024-07-21 22:14:29 +0200 | <tomsmeding> | how's ghc to know that this particular case is bad? |
| 2024-07-21 22:14:31 +0200 | <bwe> | how do you approach that personally? |
| 2024-07-21 22:14:42 +0200 | <tomsmeding> | put your ghci commands in a file :p |
| 2024-07-21 22:15:02 +0200 | <monochrom> | That was C code. But still, I'm rusty with gdb, so I still used printf debugging. I would say even with gdb I would still be working backwards. |
| 2024-07-21 22:15:25 +0200 | <tomsmeding> | gdb also only shows you want you tell it to show you |
| 2024-07-21 22:15:35 +0200 | <tomsmeding> | if you don't know where to look, gdb (or any debugger) isn't going to tell you |
| 2024-07-21 22:15:36 +0200 | <geekosaur> | these days C even has a debugger that works that way: rr |
| 2024-07-21 22:15:48 +0200 | <geekosaur> | sadly, Haskell code generally confuses it too much and it crashes |
| 2024-07-21 22:15:53 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
| 2024-07-21 22:15:57 +0200 | <__monty__> | sm: Last time I ended up in this situation was AoC. And the problem did not occur until deep into the iterations but I did need a handful of lines of context for the problematic iteration. I think I made the tracing conditional on the iteration in the end. |
| 2024-07-21 22:16:13 +0200 | <monochrom> | Basically gdb saves you from "every time I add/change a printf I have to recompile". :) |
| 2024-07-21 22:16:35 +0200 | <monochrom> | OTOH gdb is great for stack trace after segfault and coredump. |
| 2024-07-21 22:17:26 +0200 | <bwe> | tomsmeding: but that's not really ergonomic at all, isn't it? that's the one thing I find myself doing over and over again. it's just wasting time. |
| 2024-07-21 22:17:38 +0200 | <bwe> | any chance for hot reloading coming to Haskell? |
| 2024-07-21 22:17:44 +0200 | <__monty__> | Debuggers can also move the decision of where to put traces to in the middle of execution time, which can be pretty nice. |
| 2024-07-21 22:17:56 +0200 | <tomsmeding> | bwe: probably not |
| 2024-07-21 22:18:03 +0200 | <tomsmeding> | but you can copy a single function into ghci |
| 2024-07-21 22:18:12 +0200 | <tomsmeding> | :{ starts a multiline ghci command, :} ends it |
| 2024-07-21 22:18:29 +0200 | <tomsmeding> | the function won't be picked up by other things already in the module, though |
| 2024-07-21 22:20:16 +0200 | <bwe> | __monty__: for ghci I know of `:trace fun` syntax -- how can I give it a name that gets printed when its reached? |
| 2024-07-21 22:23:03 +0200 | <__monty__> | I *know* the answer to this quiz, give me just a second. |
| 2024-07-21 22:23:49 +0200 | <bwe> | thanks for your support tomsmeding geekosaur c_wraith monochrom -- we finally traced it with trace :) |
| 2024-07-21 22:24:56 +0200 | <tomsmeding> | :) |
| 2024-07-21 22:25:00 +0200 | <tomsmeding> | have fun haskelling |
| 2024-07-21 22:25:43 +0200 | <monochrom> | Hot take: A "debugging cookbook" or "code repair manual" is otherwise known as "a course on the scientific method" or "a course on the philosophy of science". |
| 2024-07-21 22:26:08 +0200 | <monochrom> | For starters, most programmers don't yet know to fight their own confirmation bias in the first place. |
| 2024-07-21 22:26:22 +0200 | <monochrom> | (That would be like 80% of the battle already.) |
| 2024-07-21 22:26:22 +0200 | <bwe> | monochrom: there you already have a title and subtitle for your book :). |
| 2024-07-21 22:26:27 +0200 | <__monty__> | Hmm, `:set stop :list` is the example from the manual I was thinking of. That tells GHCi to run `:list` every time it stops at a breakpoint. You might be able to coerce that into what you want maybe, somehow? Problem is it may not actually work with tracing, I'm not sure. |
| 2024-07-21 22:27:02 +0200 | <bwe> | tomsmeding: thanks for making it possible |
| 2024-07-21 22:28:37 +0200 | <monochrom> | Those courses already exist. No one needs write one more book. |
| 2024-07-21 22:29:38 +0200 | <monochrom> | One just needs to not disdain course codes that begin with PHL. |
| 2024-07-21 22:29:50 +0200 | <tomsmeding> | I doubt one needs a whole book or course to get enough of the idea of testing hypotheses and countering biases to proceed into "how to I practically debug in this language" |
| 2024-07-21 22:30:07 +0200 | <tomsmeding> | like, I'm not saying that this content is not useful |
| 2024-07-21 22:30:25 +0200 | <monochrom> | Oh, you mean s/one/one who already has a scientific mind/ |
| 2024-07-21 22:30:35 +0200 | <tomsmeding> | but I suspect that a book or course on the subject will give you many details that are not useful for learning debugging |
| 2024-07-21 22:30:48 +0200 | <bwe> | monochrom: So what's then the subtle yet potential impactful difference between "how to debug in this language" vs. "course on the scientific method"? |
| 2024-07-21 22:31:24 +0200 | <haskellbridge> | <sm> be aware of the breakpoint lib also, it's in between trace and an interactive debugger |
| 2024-07-21 22:31:31 +0200 | <monochrom> | What difference? I even use the scientific method to learn those languages in the first place. |
| 2024-07-21 22:31:33 +0200 | <bwe> | for me the recurring pattern is making things visible that haven't been before. and that's exactly what trace does. |
| 2024-07-21 22:32:15 +0200 | <tomsmeding> | bwe: I think what monochrom means is that there is an underlying philosophy of debugging that transcends languages |
| 2024-07-21 22:32:31 +0200 | <tomsmeding> | and that is essentially "don't think you know a thing before you've tested it experimentally" |
| 2024-07-21 22:32:52 +0200 | <tomsmeding> | after that, you still have to figure out that e.g. ':trace' exists |
| 2024-07-21 22:32:59 +0200 | <bwe> | <sm> "While GHCi has built-in support for setting breakpoints, it is not actively maintained and suffers from several critical limitations:" |
| 2024-07-21 22:33:09 +0200 | <tomsmeding> | but those are two different competencies |
| 2024-07-21 22:33:10 +0200 | <bwe> | tomsmeding: ofc |
| 2024-07-21 22:33:23 +0200 | <tomsmeding> | and you need both |
| 2024-07-21 22:33:34 +0200 | <tomsmeding> | the latter you can get from a manual, the former is harder to get from a manual |
| 2024-07-21 22:34:05 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-07-21 22:34:18 +0200 | <bwe> | tomsmeding: that reminds me of rubber ducking. if you explain everything to a random guy, you do start from zero, including re-expressing the basics of the basics, those you wouldn't question. and by the very fact of expressing them you uncover your own flawed assumptions. |
| 2024-07-21 22:34:23 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-07-21 22:34:36 +0200 | <bwe> | ^^ regarding bias busting |
| 2024-07-21 22:34:47 +0200 | <tomsmeding> | I have a collection of literal rubber ducks |
| 2024-07-21 22:35:09 +0200 | <bwe> | tomsmeding: pictures! |
| 2024-07-21 22:35:17 +0200 | tomsmeding | grumbles |
| 2024-07-21 22:35:41 +0200 | <bwe> | <sm> do you speak from your experience using it? |
| 2024-07-21 22:36:00 +0200 | <haskellbridge> | <sm> bwe: (I wasn't speaking of those, to be clear) |
| 2024-07-21 22:36:34 +0200 | [_________] | (~oos95GWG@user/oos95GWG) (Quit: [_________]) |
| 2024-07-21 22:36:45 +0200 | <haskellbridge> | <sm> bwe the breakpoint lib ? yes I tried it a little |
| 2024-07-21 22:37:12 +0200 | <bwe> | <sm> so has it become your default? when are you using it, still? |
| 2024-07-21 22:37:22 +0200 | <tomsmeding> | bwe: https://tomsmeding.com/vang/adlAkQ/PXL_20240721_203612023.jpg |
| 2024-07-21 22:37:57 +0200 | <bwe> | tomsmeding: do they have names? which do you speak to at which debugging situation? |
| 2024-07-21 22:38:14 +0200 | <tomsmeding> | unfortunately no they do not have names :p |
| 2024-07-21 22:38:33 +0200 | <monochrom> | One of them ought to be called Mr. Penguin. :) |
| 2024-07-21 22:38:45 +0200 | <haskellbridge> | <sm> no, trace (souped up by my own helpers) is my default, which I use often. breakpoint had some problem for me which I've forgotten |
| 2024-07-21 22:38:59 +0200 | <tomsmeding> | there is indeed a penguin duck in there, but on the far right there's also a glass puffin |
| 2024-07-21 22:39:07 +0200 | <bwe> | tomsmeding: just look at the five? tiny ones! |
| 2024-07-21 22:39:28 +0200 | <bwe> | <sm> trace rulez |
| 2024-07-21 22:39:31 +0200 | <tomsmeding> | https://tomsmeding.com/ss/get/tomsmeding/nqSTKP |
| 2024-07-21 22:40:00 +0200 | <bwe> | tomsmeding: you could create emojis from those…duck only |
| 2024-07-21 22:40:22 +0200 | <bwe> | tomsmeding: I like that shark duck. |
| 2024-07-21 22:40:25 +0200 | [_________] | (~oos95GWG@user/oos95GWG) |
| 2024-07-21 22:40:43 +0200 | <bwe> | where did you get that from? |
| 2024-07-21 22:41:25 +0200 | <tomsmeding> | https://www.badeendwinkel.nl/nl/lilalu/1733-badeend-haai-lilalu.html |
| 2024-07-21 22:42:44 +0200 | <monochrom> | I didn't know that ducks celebrate halloween too >:) |
| 2024-07-21 22:42:47 +0200 | bwe | observes the remaining stock to see how many in this channel will silently order it. |
| 2024-07-21 22:43:10 +0200 | <tomsmeding> | lol, the "lilalu" is a brand name so presumably it's also sold elsewhere |
| 2024-07-21 22:44:48 +0200 | cpressey | (~weechat@176.254.71.203) (Ping timeout: 276 seconds) |
| 2024-07-21 22:45:12 +0200 | cpressey | (~weechat@176.254.71.203) |
| 2024-07-21 22:45:52 +0200 | <bwe> | interesting, the NL shop is way cheaper than the producer's online shop |
| 2024-07-21 22:47:16 +0200 | <tomsmeding> | this is the kind of thing that drops down in price hugely when you buy it in bulk |
| 2024-07-21 22:49:54 +0200 | <bwe> | wishing you good night in bathing ducks world… |
| 2024-07-21 22:56:26 +0200 | dysthesis | (~dysthesis@user/dysthesis) |
| 2024-07-21 22:57:05 +0200 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2024-07-21 22:57:25 +0200 | puke | (~puke@user/puke) |
| 2024-07-21 23:02:22 +0200 | dysthesis | (~dysthesis@user/dysthesis) (Remote host closed the connection) |
| 2024-07-21 23:05:51 +0200 | dysthesis | (~dysthesis@user/dysthesis) |
| 2024-07-21 23:11:11 +0200 | dysthesis | (~dysthesis@user/dysthesis) (Ping timeout: 260 seconds) |
| 2024-07-21 23:12:57 +0200 | dysthesis | (~dysthesis@user/dysthesis) |
| 2024-07-21 23:21:26 +0200 | Midjak | (~MarciZ@82.66.147.146) |
| 2024-07-21 23:22:29 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb2038b483e43bd9e2b7.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2024-07-21 23:34:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-07-21 23:39:08 +0200 | omentic | (~apropos@104.193.135.206) |
| 2024-07-21 23:40:09 +0200 | <omentic> | hi all, total beginner at haskell |
| 2024-07-21 23:40:28 +0200 | <ddellacosta> | omentic: welcome |
| 2024-07-21 23:41:13 +0200 | <omentic> | i'm trying to debug print a term to figure out what it's doing. is there some sort of `dbg` function i can use without running into purity issues, and is there some sort of `todo` function so i can debug print and then quit? |
| 2024-07-21 23:41:41 +0200 | <ddellacosta> | omome |
| 2024-07-21 23:41:57 +0200 | <ddellacosta> | d'oh mistake, sorry |
| 2024-07-21 23:42:13 +0200 | <ddellacosta> | omentic: take a look at trace or traceM, depending on context https://hackage.haskell.org/package/base-4.20.0.1/docs/Debug-Trace.html#v:trace |
| 2024-07-21 23:42:31 +0200 | <ddellacosta> | I'm also fond of https://hackage.haskell.org/package/pretty-simple-4.1.2.0/docs/Debug-Pretty-Simple.html |
| 2024-07-21 23:42:41 +0200 | <ddellacosta> | adds a bit of nice formatting to the mix |
| 2024-07-21 23:42:52 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-07-21 23:43:10 +0200 | <ddellacosta> | omentic: elixir programmer btw? :-D |
| 2024-07-21 23:43:26 +0200 | <omentic> | ddellacosta: ah ty - i found trace but it seems to only take a String and i've been having trouble converting an arbitrary type to it |
| 2024-07-21 23:43:35 +0200 | <omentic> | ddellacosta: rust :-D |
| 2024-07-21 23:43:39 +0200 | <ddellacosta> | omentic: you're still going to need stuff that you can `show`, to be clear |
| 2024-07-21 23:43:44 +0200 | <mauke> | trace (show x) |
| 2024-07-21 23:43:51 +0200 | <ddellacosta> | ^ |
| 2024-07-21 23:44:03 +0200 | <ddellacosta> | ah gotcha |
| 2024-07-21 23:44:08 +0200 | <omentic> | ooh ty |
| 2024-07-21 23:44:30 +0200 | <mauke> | :t error |
| 2024-07-21 23:44:31 +0200 | <lambdabot> | [Char] -> a |
| 2024-07-21 23:44:55 +0200 | <mauke> | > error (show 2) + 3 |
| 2024-07-21 23:44:56 +0200 | <lambdabot> | *Exception: 2 |
| 2024-07-21 23:44:57 +0200 | <monochrom> | See my https://www.vex.net/~trebla/haskell/tracing.html for more ways to use Debug.Trace |
| 2024-07-21 23:46:00 +0200 | <omentic> | is there a Bottom term or smth to immediately panic a function? like a todo or a hole |
| 2024-07-21 23:46:19 +0200 | <ddellacosta> | that's what mauke was showing w/error ^ |
| 2024-07-21 23:47:30 +0200 | <omentic> | ohh thanks |
| 2024-07-21 23:47:32 +0200 | <ddellacosta> | https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelude.html#v:error |
| 2024-07-21 23:50:27 +0200 | aaronv | (~aaronv@user/aaronv) (Ping timeout: 276 seconds) |
| 2024-07-21 23:50:42 +0200 | <omentic> | oh dang "no instance for show X". unfortunate |
| 2024-07-21 23:50:54 +0200 | <omentic> | is there an autoderive or do i need to implement it directly? |
| 2024-07-21 23:51:07 +0200 | <ddellacosta> | want to share some code? Depends on what you're trying to derive |
| 2024-07-21 23:51:54 +0200 | <omentic> | yeah, i'm just working with hakyll |
| 2024-07-21 23:52:01 +0200 | <omentic> | trying to debug print this Context https://hackage.haskell.org/package/hakyll-4.16.2.2/docs/src/Hakyll.Web.Template.Context.html#Cont… |
| 2024-07-21 23:52:10 +0200 | <ddellacosta> | but you can try deriving (Show) |
| 2024-07-21 23:52:30 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-07-21 23:52:47 +0200 | <ddellacosta> | you probably can't derive that without clobbering a somehow |
| 2024-07-21 23:52:58 +0200 | <ddellacosta> | er, the type variable I mean |
| 2024-07-21 23:53:24 +0200 | <omentic> | somehow? is that a type |
| 2024-07-21 23:53:46 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 260 seconds) |
| 2024-07-21 23:54:23 +0200 | <omentic> | also is deriving (Show) only for locally defined types? |
| 2024-07-21 23:55:26 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-07-21 23:55:52 +0200 | <ddellacosta> | oh yeah, I was thinking of this as if you were writing it which of course is not the case |
| 2024-07-21 23:56:19 +0200 | <ddellacosta> | you can create an orphan instance locally I guess, which I think is fine as long as it's not library code you're releasing |
| 2024-07-21 23:56:22 +0200 | <omentic> | ah yeah i probably should have opened with that |
| 2024-07-21 23:56:35 +0200 | <omentic> | hmm ok will try |
| 2024-07-21 23:56:44 +0200 | <ddellacosta> | but before that I'd ask what you're trying to debug, because there may be a better way to approach it without that |
| 2024-07-21 23:57:42 +0200 | <omentic> | rn i'm basically just mucking about trying to figure out how hakyll works |
| 2024-07-21 23:58:00 +0200 | <omentic> | the default hakyll template provided is almost everything i want out of a static site generator, but not quite |
| 2024-07-21 23:58:35 +0200 | <omentic> | i have a bunch of markdown files with front matter like `--- layout: post\n title: XXX\n ---` |
| 2024-07-21 23:59:36 +0200 | <omentic> | somewhere in the hakyll engine that front matter is parsed as metadata by pandoc and so should be inspectable, so i should be able to pick an html template by matching on it (the hakyll default assumes ppl want different templates based on file paths) |
| 2024-07-21 23:59:59 +0200 | tomku | (~tomku@user/tomku) (Ping timeout: 245 seconds) |
