| 2022-08-17 00:04:07 +0200 | [Leary] | (~Leary]@122-58-224-198-vdsl.sparkbb.co.nz) (Ping timeout: 252 seconds) |
| 2022-08-17 00:09:07 +0200 | acidjnk | (~acidjnk@p200300d6e7137a99ecb826a5293fa5e0.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-08-17 00:12:11 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 252 seconds) |
| 2022-08-17 00:12:40 +0200 | king_gs | (~Thunderbi@2806:103e:29:da7a:955f:c3b4:36c4:4b7d) (Ping timeout: 256 seconds) |
| 2022-08-17 00:19:08 +0200 | djanatyn1 | djanatyn |
| 2022-08-17 00:20:35 +0200 | mmhat | (~mmh@p200300f1c719923bee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-08-17 00:28:15 +0200 | <qrpnxz> | if foo is not found, then foo never ran, so the exception is not caused by foo failing. foo never ran, so any output at all from that function would be non-sense, exception is the only thing that makes sense for that type |
| 2022-08-17 00:29:25 +0200 | <qrpnxz> | and it happens in IO, so it's a matter of course it could throw if some realworld thing prevents it doing it's purpose |
| 2022-08-17 00:34:11 +0200 | alp_ | (~alp@user/alp) |
| 2022-08-17 00:40:07 +0200 | mmhat | (~mmh@p200300f1c719923bee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 3.6) |
| 2022-08-17 00:40:46 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.5) |
| 2022-08-17 00:42:04 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-08-17 00:42:26 +0200 | <geekosaur> | actually it looks like child-side actions are expected to produce something from `waitpid()`. I kinda lost track of where all the stuff was happening when tracing the POSIX side of `createProcess_` |
| 2022-08-17 00:42:50 +0200 | <geekosaur> | but it was getting back separate errno information from the child and throwing an exception based on it |
| 2022-08-17 00:43:34 +0200 | <geekosaur> | so in fact ghcrts is doing something nonstandard. would have to discuss that with whoever's maintaining the process library |
| 2022-08-17 00:45:00 +0200 | <geekosaur> | (from `c_createInteractiveProcess` in (I think) System.Posix.Process.Internal) |
| 2022-08-17 00:46:45 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-08-17 00:51:57 +0200 | <geekosaur> | actually it's a foreign import |
| 2022-08-17 00:52:34 +0200 | arkeet | (arkeet@moriya.ca) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-08-17 00:53:11 +0200 | <geekosaur> | in System.Process.Posix (not to be confused with System.Posix.Process) |
| 2022-08-17 00:54:09 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-08-17 00:54:10 +0200 | <geekosaur> | I've done similar when I needed more detail than an exit code of -1, so I assume someone needs that |
| 2022-08-17 00:55:05 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 268 seconds) |
| 2022-08-17 00:55:25 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 01:04:58 +0200 | PiDelport | (uid25146@id-25146.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-08-17 01:06:56 +0200 | dsrt^ | (~dsrt@50.231.67.43) |
| 2022-08-17 01:11:36 +0200 | fserucas|eod | (~fserucas|@46.50.4.9) (Ping timeout: 256 seconds) |
| 2022-08-17 01:11:57 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) (Ping timeout: 252 seconds) |
| 2022-08-17 01:14:24 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2022-08-17 01:16:21 +0200 | zachel | (~zachel@user/zachel) (Ping timeout: 252 seconds) |
| 2022-08-17 01:18:20 +0200 | chomwitt | (~chomwitt@2a02:587:dc06:ee00:4f0b:15e9:107f:312) (Ping timeout: 255 seconds) |
| 2022-08-17 01:20:21 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-08-17 01:20:56 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-08-17 01:21:08 +0200 | luffy | (~chenqisu1@183.217.201.23) |
| 2022-08-17 01:23:47 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) (Remote host closed the connection) |
| 2022-08-17 01:29:00 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-08-17 01:29:49 +0200 | vysn | (~vysn@user/vysn) |
| 2022-08-17 01:41:04 +0200 | ddellacosta | (~ddellacos@143.244.47.100) (Ping timeout: 256 seconds) |
| 2022-08-17 01:44:23 +0200 | arkeet | (~arkeet@moriya.ca) |
| 2022-08-17 01:49:21 +0200 | tomboy64 | (~tomboy64@user/tomboy64) (Ping timeout: 268 seconds) |
| 2022-08-17 01:54:07 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-08-17 01:57:03 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2022-08-17 02:02:29 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 02:18:07 +0200 | sudden | (~cat@user/sudden) |
| 2022-08-17 02:21:36 +0200 | xff0x_ | (~xff0x@2405:6580:b080:900:55a5:3141:91aa:3e87) (Ping timeout: 244 seconds) |
| 2022-08-17 02:22:20 +0200 | Guest9035 | (~Guest90@221x252x204x99.ap221.ftth.ucom.ne.jp) |
| 2022-08-17 02:23:02 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 02:24:19 +0200 | Guest9035 | (~Guest90@221x252x204x99.ap221.ftth.ucom.ne.jp) (Client Quit) |
| 2022-08-17 02:25:01 +0200 | snak | (~snak@221x252x204x99.ap221.ftth.ucom.ne.jp) |
| 2022-08-17 02:28:19 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 248 seconds) |
| 2022-08-17 02:32:12 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2022-08-17 02:32:30 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-08-17 02:32:30 +0200 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-08-17 02:32:30 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2022-08-17 02:32:45 +0200 | <dragestil> | are there any tools / scripts cleaning up space used by ghcup/cabal/stack/dist-newstyle etc |
| 2022-08-17 02:33:51 +0200 | <dragestil> | they can take up rather large space and grow fast as I do dev work, and i cannot just rm -rf them because there are things i still want |
| 2022-08-17 02:34:35 +0200 | <hpc> | the unserious answer is nix-store --gc :D |
| 2022-08-17 02:34:59 +0200 | <dragestil> | ha |
| 2022-08-17 02:35:43 +0200 | <hpc> | pretty sure all those files exist in a few dotfile directories so you don't have to go searching everywhere |
| 2022-08-17 02:36:12 +0200 | <hpc> | but i don't remember how much of it you need to keep to not lose configs and such |
| 2022-08-17 02:36:36 +0200 | <hpc> | oh, you said that |
| 2022-08-17 02:36:55 +0200 | <dragestil> | for me it's not really the configs, but if i delete the wrong thing then there will be repeated work / compiling / downloading etc. |
| 2022-08-17 02:37:27 +0200 | <hpc> | ah, that i definitely don't know |
| 2022-08-17 02:38:43 +0200 | <dragestil> | ~/.ghcup/ghc ~/.cabal/store and ~/.stack/{programs,pantry,snapshots} have some of the biggest appetite for diskspace |
| 2022-08-17 02:38:44 +0200 | <hpc> | i don't think anything saves reverse dependencies of all those files, so you might just need to deal with repeat work |
| 2022-08-17 02:39:02 +0200 | <hpc> | or do some kind of find -atime | xargs rm |
| 2022-08-17 02:39:43 +0200 | <hpc> | and let it be a timed cache rather than a reference-counted cache, as it were |
| 2022-08-17 02:39:51 +0200 | PiDelport | (uid25146@id-25146.lymington.irccloud.com) |
| 2022-08-17 02:45:37 +0200 | ystael | (~ystael@user/ystael) (Ping timeout: 268 seconds) |
| 2022-08-17 02:46:04 +0200 | <dragestil> | found https://gist.github.com/filterfish/d138fa6cafd515399a54747976da7cc5 |
| 2022-08-17 02:48:01 +0200 | king_gs | (~Thunderbi@187.201.216.244) |
| 2022-08-17 02:52:00 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) |
| 2022-08-17 02:53:07 +0200 | xff0x_ | (~xff0x@2405:6580:b080:900:de8c:bb7c:e24e:39b8) |
| 2022-08-17 02:58:26 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-08-17 03:00:24 +0200 | xff0x_ | (~xff0x@2405:6580:b080:900:de8c:bb7c:e24e:39b8) (Ping timeout: 256 seconds) |
| 2022-08-17 03:04:35 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2022-08-17 03:07:27 +0200 | king_gs | (~Thunderbi@187.201.216.244) (Read error: Connection reset by peer) |
| 2022-08-17 03:07:34 +0200 | king_gs1 | (~Thunderbi@2806:103e:29:da7a:c1c9:7ec0:dc35:1f68) |
| 2022-08-17 03:09:53 +0200 | king_gs1 | king_gs |
| 2022-08-17 03:10:24 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-08-17 03:15:01 +0200 | Wstfgl0 | (~me-me@tunnel690570-pt.tunnel.tserv12.mia1.ipv6.he.net) |
| 2022-08-17 03:16:32 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-08-17 03:16:42 +0200 | Me-me | (~Me-me@146.102.215.218.dyn.iprimus.net.au) (Quit: Going offline, see ya! (www.adiirc.com)) |
| 2022-08-17 03:16:50 +0200 | Wstfgl0 | Me-me |
| 2022-08-17 03:17:10 +0200 | Me-me | (~me-me@tunnel690570-pt.tunnel.tserv12.mia1.ipv6.he.net) (Changing host) |
| 2022-08-17 03:17:10 +0200 | Me-me | (~me-me@user/me-me) |
| 2022-08-17 03:18:05 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2022-08-17 03:20:16 +0200 | Allio84 | (~Android@79-74-233-27.dynamic.dsl.as9105.com) (Remote host closed the connection) |
| 2022-08-17 03:27:24 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-08-17 03:30:29 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 03:32:26 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection) |
| 2022-08-17 03:34:38 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2022-08-17 03:34:52 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-08-17 03:37:57 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 03:40:12 +0200 | [Leary] | (~Leary]@122-58-223-158-adsl.sparkbb.co.nz) |
| 2022-08-17 03:49:23 +0200 | dsrt^ | (~dsrt@50.231.67.43) (Ping timeout: 248 seconds) |
| 2022-08-17 03:52:27 +0200 | Teacup | (~teacup@user/teacup) (Quit: No Ping reply in 180 seconds.) |
| 2022-08-17 03:53:57 +0200 | Teacup | (~teacup@user/teacup) |
| 2022-08-17 03:54:43 +0200 | vglfr | (~vglfr@145.224.94.221) (Ping timeout: 248 seconds) |
| 2022-08-17 03:59:31 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-08-17 04:00:03 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 248 seconds) |
| 2022-08-17 04:00:31 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-08-17 04:01:06 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-17 04:01:34 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-08-17 04:06:42 +0200 | jespada | (~jespada@2803:9800:9842:8ca9:697e:9a9e:7c3a:1937) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-08-17 04:09:21 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-08-17 04:09:21 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-17 04:09:21 +0200 | finn_elija | FinnElija |
| 2022-08-17 04:15:27 +0200 | dsrt^ | (~dsrt@50.231.67.43) |
| 2022-08-17 04:17:10 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-08-17 04:20:31 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 04:24:49 +0200 | td_ | (~td@muedsl-82-207-238-061.citykom.de) (Ping timeout: 252 seconds) |
| 2022-08-17 04:26:44 +0200 | td_ | (~td@94.134.91.250) |
| 2022-08-17 04:27:51 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-17 04:37:45 +0200 | vglfr | (~vglfr@145.224.94.221) |
| 2022-08-17 04:39:07 +0200 | stef204 | (~stef204@user/stef204) (Quit: WeeChat 3.6) |
| 2022-08-17 04:51:45 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 04:51:51 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 05:01:01 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 05:04:13 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-08-17 05:05:39 +0200 | vysn | (~vysn@user/vysn) (Ping timeout: 256 seconds) |
| 2022-08-17 05:08:51 +0200 | dsrt^ | (~dsrt@50.231.67.43) (Ping timeout: 248 seconds) |
| 2022-08-17 05:09:53 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 05:14:35 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 05:25:24 +0200 | dsrt^ | (~dsrt@50.231.67.43) |
| 2022-08-17 05:25:32 +0200 | aeka | (~aeka@2606:6080:1002:8:3285:30e:de43:8809) (Ping timeout: 244 seconds) |
| 2022-08-17 05:34:41 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) (Remote host closed the connection) |
| 2022-08-17 05:39:20 +0200 | texasmynsted | (~texasmyns@99.96.221.112) (Ping timeout: 255 seconds) |
| 2022-08-17 05:39:59 +0200 | dsrt^ | (~dsrt@50.231.67.43) (Ping timeout: 268 seconds) |
| 2022-08-17 05:40:18 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 05:44:44 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 05:47:26 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 255 seconds) |
| 2022-08-17 05:47:49 +0200 | dsrt^ | (~dsrt@50.231.67.43) |
| 2022-08-17 05:55:59 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 06:03:47 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 248 seconds) |
| 2022-08-17 06:05:07 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-08-17 06:05:44 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-17 06:08:58 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-08-17 06:12:52 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 06:15:26 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 06:17:12 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 06:19:44 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) |
| 2022-08-17 06:19:47 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 248 seconds) |
| 2022-08-17 06:25:00 +0200 | dsrt^ | (~dsrt@50.231.67.43) (Ping timeout: 268 seconds) |
| 2022-08-17 06:30:08 +0200 | snak | (~snak@221x252x204x99.ap221.ftth.ucom.ne.jp) (Quit: Client closed) |
| 2022-08-17 06:30:33 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-08-17 06:36:53 +0200 | luffy | (~chenqisu1@183.217.201.23) (Ping timeout: 256 seconds) |
| 2022-08-17 06:41:38 +0200 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-08-17 06:45:26 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-08-17 06:46:03 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 268 seconds) |
| 2022-08-17 06:48:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 06:48:21 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 06:48:25 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2022-08-17 06:52:41 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 06:53:41 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-08-17 06:53:55 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 248 seconds) |
| 2022-08-17 06:54:02 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-17 06:56:31 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 06:59:11 +0200 | abraham | (~abraham@159.89.183.132) |
| 2022-08-17 06:59:30 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-08-17 07:00:03 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-17 07:01:23 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-08-17 07:09:59 +0200 | mbuf | (~Shakthi@122.165.55.71) |
| 2022-08-17 07:13:23 +0200 | jargon | (~jargon@184.101.168.117) (Remote host closed the connection) |
| 2022-08-17 07:17:05 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 07:19:14 +0200 | abraham | (~abraham@159.89.183.132) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-08-17 07:20:11 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 07:20:30 +0200 | king_gs | (~Thunderbi@2806:103e:29:da7a:c1c9:7ec0:dc35:1f68) (Ping timeout: 256 seconds) |
| 2022-08-17 07:22:14 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 07:25:02 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-08-17 07:26:44 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 256 seconds) |
| 2022-08-17 07:27:25 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 07:27:59 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds) |
| 2022-08-17 07:30:33 +0200 | king_gs | (~Thunderbi@187.201.216.244) |
| 2022-08-17 07:31:04 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds) |
| 2022-08-17 07:35:55 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 07:39:01 +0200 | jargon | (~jargon@184.101.168.117) |
| 2022-08-17 07:40:20 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-08-17 07:42:15 +0200 | tompaw | (~tompaw@static-47-206-100-136.tamp.fl.frontiernet.net) (Ping timeout: 255 seconds) |
| 2022-08-17 07:45:38 +0200 | chomwitt | (~chomwitt@2a02:587:dc06:ee00:4e2b:7ca9:316d:45c) |
| 2022-08-17 07:49:12 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2022-08-17 07:49:13 +0200 | tompaw | (~tompaw@static-47-206-100-136.tamp.fl.frontiernet.net) |
| 2022-08-17 07:49:39 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-17 07:50:33 +0200 | chomwitt | (~chomwitt@2a02:587:dc06:ee00:4e2b:7ca9:316d:45c) (Ping timeout: 256 seconds) |
| 2022-08-17 07:52:04 +0200 | zachel | (~zachel@user/zachel) |
| 2022-08-17 07:55:24 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 07:55:46 +0200 | <sm> | dragestil: stack-clean-old |
| 2022-08-17 07:55:52 +0200 | <sm> | also ncdu |
| 2022-08-17 07:57:24 +0200 | <dragestil> | sm: thanks |
| 2022-08-17 07:58:50 +0200 | aviladev[m] | (~aviladevm@2001:470:69fc:105::1:cbc7) |
| 2022-08-17 07:59:44 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 08:03:32 +0200 | gurkenglas | (~gurkengla@p548ac72e.dip0.t-ipconnect.de) |
| 2022-08-17 08:05:08 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-08-17 08:05:15 +0200 | coot | (~coot@213.134.176.158) |
| 2022-08-17 08:05:25 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 08:06:21 +0200 | coot | (~coot@213.134.176.158) (Client Quit) |
| 2022-08-17 08:06:48 +0200 | coot | (~coot@213.134.176.158) |
| 2022-08-17 08:08:35 +0200 | jargon | (~jargon@184.101.168.117) (Remote host closed the connection) |
| 2022-08-17 08:14:58 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 08:17:22 +0200 | jargon | (~jargon@184.101.168.117) |
| 2022-08-17 08:19:15 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 248 seconds) |
| 2022-08-17 08:26:50 +0200 | jargon | (~jargon@184.101.168.117) (Remote host closed the connection) |
| 2022-08-17 08:28:19 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 08:31:27 +0200 | MajorBiscuit | (~MajorBisc@c-001-030-027.client.tudelft.eduvpn.nl) |
| 2022-08-17 08:32:34 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 08:32:53 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 08:33:01 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) |
| 2022-08-17 08:36:52 +0200 | sus | (zero@user/zeromomentum) (Quit: the lounge - https://webirc.envs.net) |
| 2022-08-17 08:39:06 +0200 | jargon | (~jargon@184.101.168.117) |
| 2022-08-17 08:39:07 +0200 | king_gs | (~Thunderbi@187.201.216.244) (Read error: Connection reset by peer) |
| 2022-08-17 08:40:15 +0200 | chele | (~chele@user/chele) |
| 2022-08-17 08:40:30 +0200 | king_gs | (~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec) |
| 2022-08-17 08:41:13 +0200 | king_gs | (~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec) (Client Quit) |
| 2022-08-17 08:41:52 +0200 | Guest87 | (~Guest87@cpc77311-basf12-2-0-cust212.12-3.cable.virginm.net) |
| 2022-08-17 08:41:56 +0200 | jargon | (~jargon@184.101.168.117) (Remote host closed the connection) |
| 2022-08-17 08:42:20 +0200 | Guest87 | (~Guest87@cpc77311-basf12-2-0-cust212.12-3.cable.virginm.net) (Client Quit) |
| 2022-08-17 08:43:29 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) (Read error: Connection reset by peer) |
| 2022-08-17 08:43:56 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) |
| 2022-08-17 08:44:13 +0200 | acidjnk | (~acidjnk@p200300d6e7137a0595bd943540671dc0.dip0.t-ipconnect.de) |
| 2022-08-17 08:46:50 +0200 | lottaquestions | (~nick@104.221.24.83) |
| 2022-08-17 08:47:52 +0200 | jargon | (~jargon@184.101.168.117) |
| 2022-08-17 08:48:47 +0200 | lottaquestions_ | (~nick@2607:fa49:503e:7100:6db8:6536:53f:14df) (Ping timeout: 255 seconds) |
| 2022-08-17 08:49:30 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 08:58:05 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) |
| 2022-08-17 09:00:30 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 09:02:20 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-08-17 09:04:12 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-08-17 09:04:42 +0200 | ddellacosta | (~ddellacos@143.244.47.84) |
| 2022-08-17 09:04:59 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 09:05:22 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-08-17 09:05:41 +0200 | mmhat | (~mmh@p200300f1c712fb1cee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-08-17 09:07:31 +0200 | yvan-sraka | (~yvan-srak@57.red-81-44-3.dynamicip.rima-tde.net) |
| 2022-08-17 09:07:59 +0200 | gdown | (~gavin@h69-11-149-231.kndrid.broadband.dynamic.tds.net) (Remote host closed the connection) |
| 2022-08-17 09:08:37 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-08-17 09:09:17 +0200 | snak | (~snak@221x252x204x99.ap221.ftth.ucom.ne.jp) |
| 2022-08-17 09:10:09 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:82fa:1061:3168:3965) |
| 2022-08-17 09:10:12 +0200 | riverside | (~riverside@213.205.241.143) |
| 2022-08-17 09:10:16 +0200 | ddellacosta | (~ddellacos@143.244.47.84) (Ping timeout: 268 seconds) |
| 2022-08-17 09:10:41 +0200 | <riverside> | hello morning people |
| 2022-08-17 09:10:49 +0200 | <riverside> | SO |
| 2022-08-17 09:10:55 +0200 | <riverside> | i know what it is now |
| 2022-08-17 09:10:57 +0200 | <riverside> | its got |
| 2022-08-17 09:10:59 +0200 | <riverside> | goto |
| 2022-08-17 09:11:06 +0200 | <riverside> | on a graph |
| 2022-08-17 09:11:18 +0200 | <riverside> | as a morphism in a gategory of objects |
| 2022-08-17 09:11:32 +0200 | <riverside> | in programing |
| 2022-08-17 09:12:01 +0200 | ddellacosta | (~ddellacos@89.45.224.34) |
| 2022-08-17 09:12:06 +0200 | <riverside> | functional programing by variable dereferencing |
| 2022-08-17 09:12:20 +0200 | <riverside> | acheives a nonlinear program graph |
| 2022-08-17 09:12:25 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) (Read error: Connection reset by peer) |
| 2022-08-17 09:13:40 +0200 | <riverside> | easyest way to explain it is notionally as a "turing graph" by analogy to the "turing tape" style line numbered programming languages like bbc basic |
| 2022-08-17 09:14:15 +0200 | <riverside> | and im yammering on because we have lists and not graphs as a language primative! |
| 2022-08-17 09:14:44 +0200 | <riverside> | so i cant express it within itself, which is annoying me into articulating this |
| 2022-08-17 09:15:58 +0200 | <riverside> | point being about index algebra and pointers |
| 2022-08-17 09:16:11 +0200 | <riverside> | which we get by default by abstracting over lenses |
| 2022-08-17 09:17:15 +0200 | alp_ | (~alp@user/alp) |
| 2022-08-17 09:17:49 +0200 | <riverside> | and i think there is a correspondence between a nutszoid re-phrasing of what a graph is, as a monadically tailed list, and a monadically encapsulated deconstructor-reconstructor pair |
| 2022-08-17 09:17:56 +0200 | ccntrq | (~Thunderbi@172.209.94.92.rev.sfr.net) |
| 2022-08-17 09:18:10 +0200 | <riverside> | such as to retain reconstructional positional data as data retained during deconstruction |
| 2022-08-17 09:18:36 +0200 | <riverside> | which i think is just a pair of ints for a tree as a free list, modulo something to do with cycles |
| 2022-08-17 09:18:41 +0200 | <riverside> | ("just dig") |
| 2022-08-17 09:18:55 +0200 | <riverside> | or just, dug |
| 2022-08-17 09:20:08 +0200 | <ski> | riverside : lists are not a language primitive. they just have some convenient syntactic sugar |
| 2022-08-17 09:20:40 +0200 | <ski> | (and i think most of what you said make little sense to other people in here) |
| 2022-08-17 09:20:48 +0200 | <riverside> | and then because toList exists from the traversable implementation, and we need to tackle these damn cycles, you end up with solving a sparks matrix at type level to add connectivity like a wire switchboard |
| 2022-08-17 09:21:08 +0200 | <riverside> | between positions in the list |
| 2022-08-17 09:21:30 +0200 | <riverside> | and that type level explication by constructor annotation is the thing i think should be primitivised |
| 2022-08-17 09:21:56 +0200 | <riverside> | ski it is as union in GADT |
| 2022-08-17 09:22:13 +0200 | <riverside> | choice being multiple constructors |
| 2022-08-17 09:22:14 +0200 | <ski> | i've no idea what you're talking about, at this point |
| 2022-08-17 09:22:29 +0200 | <riverside> | i mean the generic abstraction over cons is a language primative |
| 2022-08-17 09:22:37 +0200 | <riverside> | but cant be annotated to explicate cycles |
| 2022-08-17 09:22:47 +0200 | <riverside> | ski: thanks for that! |
| 2022-08-17 09:22:49 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) |
| 2022-08-17 09:22:54 +0200 | <ski> | np |
| 2022-08-17 09:22:55 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 256 seconds) |
| 2022-08-17 09:23:13 +0200 | <Franciman> | do you think that teaching functional programming to young people can be effective and useful? |
| 2022-08-17 09:23:33 +0200 | <merijn> | Franciman: Sure, why not? |
| 2022-08-17 09:23:36 +0200 | <riverside> | im not sure thats the kind of thing you should be asking |
| 2022-08-17 09:23:39 +0200 | <merijn> | Also, define "young" |
| 2022-08-17 09:23:54 +0200 | <riverside> | awkward |
| 2022-08-17 09:23:55 +0200 | <ski> | @quote rules.of.Go |
| 2022-08-17 09:23:55 +0200 | <lambdabot> | sarah says: "But I don't _want_ functional programming!" -- Sarah Peyton Jones, age 11, upon hearing the rules of Go |
| 2022-08-17 09:24:11 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) (Read error: Connection reset by peer) |
| 2022-08-17 09:24:16 +0200 | <Franciman> | merijn: hm sure, i think around 11yo yeah ahha |
| 2022-08-17 09:24:28 +0200 | <riverside> | sounds like it was being offered as food |
| 2022-08-17 09:25:03 +0200 | <riverside> | what are the rules of Go? |
| 2022-08-17 09:25:11 +0200 | <riverside> | "run away!" |
| 2022-08-17 09:25:32 +0200 | <Franciman> | it's really interesting how for young people you must find simple semantics, which is basically what the ultra advanced research does to explain super hard programs |
| 2022-08-17 09:26:26 +0200 | <riverside> | boring! |
| 2022-08-17 09:27:10 +0200 | <merijn> | You can teach 11 year olds basically anything IFF you can get their interest |
| 2022-08-17 09:27:12 +0200 | <riverside> | anyway, who else are you going to teach functional programming to? |
| 2022-08-17 09:27:33 +0200 | <earthy> | everyone? :) |
| 2022-08-17 09:27:38 +0200 | <riverside> | you lot already know the answers |
| 2022-08-17 09:27:53 +0200 | <riverside> | wheres my gofur? |
| 2022-08-17 09:28:08 +0200 | <Franciman> | eheh that's why i was thinking about frp, so they can make videogames and animations |
| 2022-08-17 09:28:09 +0200 | <riverside> | "hes pointing at a graph!" |
| 2022-08-17 09:28:25 +0200 | cosimone | (~user@93-44-186-171.ip98.fastwebnet.it) |
| 2022-08-17 09:28:29 +0200 | <Franciman> | but frp implementations i found are technically challenging, it would require like 1 year of ball busting |
| 2022-08-17 09:28:33 +0200 | <riverside> | and all the functions and the programs flowing on the graph, etc. |
| 2022-08-17 09:29:01 +0200 | <riverside> | i need connectivity! |
| 2022-08-17 09:29:27 +0200 | <riverside> | i think its a list language |
| 2022-08-17 09:29:38 +0200 | <riverside> | er, how you implement it, uses union gadt |
| 2022-08-17 09:29:59 +0200 | <riverside> | like, its ends up functional by on a datatype its constructed linearly |
| 2022-08-17 09:30:10 +0200 | <riverside> | you have to match up the connectivity at the constructor |
| 2022-08-17 09:30:27 +0200 | <riverside> | having listified the program graph |
| 2022-08-17 09:30:33 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-08-17 09:31:28 +0200 | <riverside> | i tried to write it - but i broke both my wrists and the steering wheel came off in my hands, with the rest of the car disintegrated on the road around me |
| 2022-08-17 09:31:48 +0200 | <riverside> | a type error! |
| 2022-08-17 09:31:58 +0200 | <riverside> | bastard list language constructors |
| 2022-08-17 09:32:18 +0200 | <riverside> | i want an interface to write those without getting so much type error wrist cramp |
| 2022-08-17 09:32:27 +0200 | <riverside> | such that matches the compiler |
| 2022-08-17 09:32:34 +0200 | <riverside> | now i should really understand what i mean |
| 2022-08-17 09:32:36 +0200 | <riverside> | it evaluates |
| 2022-08-17 09:32:47 +0200 | <riverside> | program in a datatype, run it as a function |
| 2022-08-17 09:33:04 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 09:33:10 +0200 | <riverside> | lexer parser, compiler thing |
| 2022-08-17 09:33:48 +0200 | <riverside> | i cant usually get the constraints at the constructor and the recursion which consumes the function list to match up nicely |
| 2022-08-17 09:34:07 +0200 | <riverside> | different linear languages being specified by the constraint and evaluation |
| 2022-08-17 09:34:39 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-08-17 09:34:54 +0200 | <riverside> | simplest on is just a function list of a->a which folds with . for evaluation with id as a basecase |
| 2022-08-17 09:35:03 +0200 | <riverside> | thats the specification of a linear language |
| 2022-08-17 09:35:53 +0200 | <riverside> | generally you have functions taking several arguments, with branching and variable reuse for cycles |
| 2022-08-17 09:36:22 +0200 | <riverside> | reuse *within itself* *requiering reuse* (which is what the linear types thing is all about) |
| 2022-08-17 09:36:30 +0200 | ddellacosta | (~ddellacos@89.45.224.34) (Ping timeout: 256 seconds) |
| 2022-08-17 09:36:47 +0200 | polyphem | (~rod@2a02:810d:840:8754:224e:f6ff:fe5e:bc17) |
| 2022-08-17 09:37:40 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 09:37:50 +0200 | <riverside> | recursive function definitions in functional programing, by reusing variables defined in the recursive call, are nonlinear by nature |
| 2022-08-17 09:38:12 +0200 | <riverside> | which defines what we mean by linear types |
| 2022-08-17 09:38:21 +0200 | ddellacosta | (~ddellacos@143.244.47.71) |
| 2022-08-17 09:38:22 +0200 | <riverside> | now, since this is not recursive |
| 2022-08-17 09:38:34 +0200 | <riverside> | if we do have linear types |
| 2022-08-17 09:38:52 +0200 | <riverside> | then no recursive function definitions, and no nonlinear program graphs |
| 2022-08-17 09:39:03 +0200 | <riverside> | which is whats up with all these annotations at the constructor |
| 2022-08-17 09:39:22 +0200 | <riverside> | nonlinear languages arising from linear programs |
| 2022-08-17 09:39:37 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) |
| 2022-08-17 09:39:47 +0200 | <riverside> | nonlinear languages arising from linear programing languages such as haskell with linear types |
| 2022-08-17 09:40:15 +0200 | <riverside> | or defining program graphs linearly via gadt union constructors |
| 2022-08-17 09:41:20 +0200 | <riverside> | this forms the basecase and recursive step elluding to a higherarchy of higher nonlinear languages |
| 2022-08-17 09:41:38 +0200 | <riverside> | nonlinear languages arising from linear ones |
| 2022-08-17 09:41:49 +0200 | <riverside> | but i need these damn graph primatives!! |
| 2022-08-17 09:45:06 +0200 | <riverside> | idk about trying to teach haskell, but i wish someone would do that for me |
| 2022-08-17 09:45:09 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-08-17 09:45:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 09:46:56 +0200 | <riverside> | i want nonlinear types |
| 2022-08-17 09:47:26 +0200 | <riverside> | which i have because gadt syntax can be recursive, binding types *linearly* at top level |
| 2022-08-17 09:49:15 +0200 | <riverside> | nonlinearly* |
| 2022-08-17 09:49:31 +0200 | <riverside> | raising the question of linear kinds# |
| 2022-08-17 09:49:41 +0200 | <Axman6> | what on earth is going on |
| 2022-08-17 09:49:46 +0200 | <riverside> | idk |
| 2022-08-17 09:50:09 +0200 | <riverside> | i think haskell is here |
| 2022-08-17 09:51:51 +0200 | <riverside> | basically everything i demand of the type system is here, except higher levity linearity |
| 2022-08-17 09:52:15 +0200 | <riverside> | does it make sense? |
| 2022-08-17 09:52:24 +0200 | <riverside> | i mean, i motivated it well sure |
| 2022-08-17 09:52:32 +0200 | <riverside> | but i cant envisage it |
| 2022-08-17 09:52:35 +0200 | <riverside> | what would it be |
| 2022-08-17 09:52:55 +0200 | <riverside> | "types you can only use once" doesnt sound right to me |
| 2022-08-17 09:53:16 +0200 | <riverside> | its supposed to preclude some nonlinear pointer on a type level program graph |
| 2022-08-17 09:53:18 +0200 | <riverside> | oh! |
| 2022-08-17 09:53:20 +0200 | <riverside> | cool |
| 2022-08-17 09:53:45 +0200 | <riverside> | i swear im onto something! |
| 2022-08-17 09:54:14 +0200 | <riverside> | (irony is i think because its such a centeral thing this graph monad in programing languages as programs monad) |
| 2022-08-17 09:54:47 +0200 | <riverside> | makes too much sense not to be the thing |
| 2022-08-17 09:54:59 +0200 | <riverside> | thats whats doing my head in about it |
| 2022-08-17 09:55:03 +0200 | yvan-sraka | (~yvan-srak@57.red-81-44-3.dynamicip.rima-tde.net) (Remote host closed the connection) |
| 2022-08-17 09:55:08 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2022-08-17 09:55:38 +0200 | <riverside> | "todo with nonlinear programming at higher levity" |
| 2022-08-17 09:55:55 +0200 | <riverside> | "something something language monad" |
| 2022-08-17 09:56:34 +0200 | <riverside> | and its going pointers which is cool |
| 2022-08-17 09:56:39 +0200 | <riverside> | starts with goto also |
| 2022-08-17 09:57:17 +0200 | <riverside> | variable names instead of line numbers is the thing that does it |
| 2022-08-17 09:57:22 +0200 | <riverside> | go functional programs! |
| 2022-08-17 09:57:28 +0200 | <riverside> | (lambda man away!) |
| 2022-08-17 09:58:38 +0200 | <riverside> | so something about kind level polymorphism, according to the name of the language extension |
| 2022-08-17 09:58:55 +0200 | <riverside> | PolyKinds? right? |
| 2022-08-17 09:58:57 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 09:59:34 +0200 | <riverside> | even gives variable re-use (the central thing of linearity) *through* levities |
| 2022-08-17 09:59:54 +0200 | <riverside> | then you get dependent programming, yeah im going to smoke |
| 2022-08-17 10:00:15 +0200 | <riverside> | linear polykinds? proposal? |
| 2022-08-17 10:01:12 +0200 | fserucas|eod | (~fserucas|@46.50.4.9) |
| 2022-08-17 10:01:26 +0200 | <riverside> | now i just need robots that teach themselves how to imagine reality |
| 2022-08-17 10:01:51 +0200 | fserucas|eod | (~fserucas|@46.50.4.9) (Client Quit) |
| 2022-08-17 10:02:06 +0200 | fserucas|eod | (~fserucas|@46.50.4.9) |
| 2022-08-17 10:04:48 +0200 | <riverside> | kind of scared of dying when i hit compile though as reality spawns |
| 2022-08-17 10:05:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 10:05:11 +0200 | <riverside> | its a compile time simulation monad! |
| 2022-08-17 10:05:24 +0200 | <riverside> | *argh my mind* |
| 2022-08-17 10:05:49 +0200 | <riverside> | "give him less functions" |
| 2022-08-17 10:05:52 +0200 | <riverside> | im going... |
| 2022-08-17 10:05:53 +0200 | riverside | (~riverside@213.205.241.143) (Remote host closed the connection) |
| 2022-08-17 10:07:01 +0200 | jmorris | (uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-08-17 10:07:05 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 268 seconds) |
| 2022-08-17 10:07:37 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-17 10:09:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 10:13:42 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-17 10:14:22 +0200 | <tdammers> | whoa. |
| 2022-08-17 10:14:31 +0200 | benin0 | (~benin@183.82.30.34) |
| 2022-08-17 10:17:50 +0200 | vysn | (~vysn@user/vysn) |
| 2022-08-17 10:18:37 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::a1ec) |
| 2022-08-17 10:23:57 +0200 | ubert | (~Thunderbi@178.165.179.220.wireless.dyn.drei.com) |
| 2022-08-17 10:24:36 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) |
| 2022-08-17 10:25:30 +0200 | arjun | (~arjun@user/arjun) |
| 2022-08-17 10:25:35 +0200 | <arjun> | hi |
| 2022-08-17 10:26:01 +0200 | <arjun> | where can i read more about newtype wrapping types for orphan instances ? |
| 2022-08-17 10:26:31 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-08-17 10:26:52 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-17 10:27:54 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 10:29:08 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds) |
| 2022-08-17 10:29:57 +0200 | <chreekat> | arjun: do you mean making a newtype for a 3rd party type (something defined in a dependency) so that you can give it a non-orphan instance? |
| 2022-08-17 10:32:36 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-08-17 10:33:20 +0200 | nilradical | (~nilradica@user/naso) (Remote host closed the connection) |
| 2022-08-17 10:34:08 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 10:34:12 +0200 | <arjun> | chreekat not exactly but i'd be happy to read that as well. imagine TH thing that automatically makes some boilerplate instances for some types. some more complicated record types end up having some common member types, which end up having multiple instances defined. i was wondering if i could wrap them in a newtype and how would that work ? |
| 2022-08-17 10:35:47 +0200 | <arjun> | but the Typeclasses being boilerplated are almost always a third party dep, so you might be right. |
| 2022-08-17 10:36:46 +0200 | CiaoSen | (~Jura@p200300c95738a5002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-08-17 10:37:56 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 10:38:50 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 256 seconds) |
| 2022-08-17 10:40:39 +0200 | <dminuoso> | tdammers: Oh I bet its just what-was-this-markov-chain-persons-name-again |
| 2022-08-17 10:42:15 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 10:48:34 +0200 | <ski> | they've used multiple nicks |
| 2022-08-17 10:51:10 +0200 | alp_ | alpm |
| 2022-08-17 10:52:40 +0200 | alpm | (~alp@user/alp) (Quit: Leaving) |
| 2022-08-17 10:53:33 +0200 | alp- | (~alp@user/alp) |
| 2022-08-17 10:53:35 +0200 | Me-me | (~me-me@user/me-me) (Quit: Disconnecting on purpose.) |
| 2022-08-17 10:54:05 +0200 | Me-me | (~me-me@v.working.name) |
| 2022-08-17 10:55:22 +0200 | Me-me | (~me-me@v.working.name) (Changing host) |
| 2022-08-17 10:55:22 +0200 | Me-me | (~me-me@user/me-me) |
| 2022-08-17 10:57:31 +0200 | vglfr | (~vglfr@145.224.94.221) (Ping timeout: 252 seconds) |
| 2022-08-17 11:00:23 +0200 | vglfr | (~vglfr@145.224.94.221) |
| 2022-08-17 11:00:24 +0200 | CiaoSen | (~Jura@p200300c95738a5002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Quit: CiaoSen) |
| 2022-08-17 11:03:26 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) (Remote host closed the connection) |
| 2022-08-17 11:03:28 +0200 | vglfr | (~vglfr@145.224.94.221) (Read error: Connection reset by peer) |
| 2022-08-17 11:03:39 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) |
| 2022-08-17 11:04:00 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 11:05:21 +0200 | ardell | (~ardell@user/ardell) |
| 2022-08-17 11:06:49 +0200 | ddellacosta | (~ddellacos@143.244.47.71) (Ping timeout: 268 seconds) |
| 2022-08-17 11:08:10 +0200 | <tdammers> | "drugs" or "youthfulness" seem more plausible explanations to me than "markov chain" in this particular case |
| 2022-08-17 11:08:22 +0200 | shriekingnoise | (~shrieking@186.137.167.202) (Quit: Quit) |
| 2022-08-17 11:08:45 +0200 | ddellacosta | (~ddellacos@89.45.224.216) |
| 2022-08-17 11:08:46 +0200 | <dminuoso> | Maybe a regression in their markov chain code? :) |
| 2022-08-17 11:09:06 +0200 | <dminuoso> | At times their output was even more gibberish |
| 2022-08-17 11:09:25 +0200 | <[exa]> | drugs, youthfulness and monads |
| 2022-08-17 11:11:08 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 11:11:25 +0200 | luffy | (~chenqisu1@183.217.201.23) |
| 2022-08-17 11:11:30 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-08-17 11:15:29 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 11:23:55 +0200 | <merijn> | tdammers: I mean, it's like "beaky, but less likable" |
| 2022-08-17 11:25:12 +0200 | nilradical | (~nilradica@user/naso) (Remote host closed the connection) |
| 2022-08-17 11:26:00 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 11:30:43 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 248 seconds) |
| 2022-08-17 11:34:22 +0200 | <tdammers> | I'd file "monads" under "drugs" |
| 2022-08-17 11:36:59 +0200 | CiaoSen | (~Jura@p200300c95738a5002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-08-17 11:37:56 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 11:42:18 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 256 seconds) |
| 2022-08-17 11:45:44 +0200 | <int-e> | Hey I can get out of this monad any time I want! |
| 2022-08-17 11:45:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 11:47:16 +0200 | <tdammers> | int-e: unsafePerformIO, not even once |
| 2022-08-17 11:48:55 +0200 | <merijn> | tdammers: You mean "unsafePerformIO, maybe once maybe more" :p |
| 2022-08-17 11:49:46 +0200 | <dminuoso> | Maybe we should include `unsafePerform :: Monad m => m a -> a` to Monad, that would address so many beginner problems. |
| 2022-08-17 11:49:56 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 11:56:10 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:82fa:1061:3168:3965) (Quit: WeeChat 2.8) |
| 2022-08-17 11:56:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 11:57:28 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 268 seconds) |
| 2022-08-17 11:58:00 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-17 11:58:44 +0200 | kuribas | (~user@ptr-17d51eo65n4u3gc42wc.18120a2.ip6.access.telenet.be) |
| 2022-08-17 11:59:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 11:59:40 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8880:3b7c:b31c:90c0) |
| 2022-08-17 12:00:11 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 12:00:58 +0200 | arjun_ | (~arjun@user/arjun) |
| 2022-08-17 12:01:51 +0200 | arjun_ | (~arjun@user/arjun) (Remote host closed the connection) |
| 2022-08-17 12:03:09 +0200 | arjun | (~arjun@user/arjun) (Ping timeout: 252 seconds) |
| 2022-08-17 12:04:47 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 268 seconds) |
| 2022-08-17 12:05:29 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 268 seconds) |
| 2022-08-17 12:07:11 +0200 | <tdammers> | while we're at it, how about making types optional, allowing destructive variable updates, and automatically injecting unsafePerform as needed |
| 2022-08-17 12:07:52 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-08-17 12:09:39 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-08-17 12:10:20 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-08-17 12:10:22 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8880:3b7c:b31c:90c0) (Ping timeout: 268 seconds) |
| 2022-08-17 12:10:39 +0200 | <ski> | we already have `-fdefer-type-errors', i guess .. but we could ask to get our linear implicit parameters back ? |
| 2022-08-17 12:10:42 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-17 12:10:43 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:603f:e09d:dbc1:db0a) |
| 2022-08-17 12:12:09 +0200 | mvk | (~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 244 seconds) |
| 2022-08-17 12:13:53 +0200 | <kuribas> | linear implicit parameters as in idris? |
| 2022-08-17 12:14:52 +0200 | <dminuoso> | tdammers: Oh beautiful, so is `f x = x + x where x = 2` going to behave differently depending on optimization level? |
| 2022-08-17 12:15:41 +0200 | <kuribas> | dminuoso: where does RHS x refer to? |
| 2022-08-17 12:16:44 +0200 | <dminuoso> | We're doing destructive updates, dont ask. |
| 2022-08-17 12:16:52 +0200 | <kuribas> | > let f x = x + x where x = 2 in f 3 |
| 2022-08-17 12:16:53 +0200 | <lambdabot> | 4 |
| 2022-08-17 12:17:07 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:603f:e09d:dbc1:db0a) (Ping timeout: 248 seconds) |
| 2022-08-17 12:17:16 +0200 | <kuribas> | ok, I stumbled into some crazy discussion... |
| 2022-08-17 12:18:02 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 12:20:49 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds) |
| 2022-08-17 12:21:32 +0200 | <tdammers> | dminuoso: yes, of course. It will also produce different results depending on how often you have called f before. |
| 2022-08-17 12:23:37 +0200 | <dminuoso> | tdammers: Also, will calling `f 10` affect a local variable x that is in scope? |
| 2022-08-17 12:23:49 +0200 | <dminuoso> | I think making all variables global will avoid scope confusion. |
| 2022-08-17 12:24:22 +0200 | <ski> | kuribas : as in e.g. "Fun with Linear Implicit Parameters" by TheHunter in 2005-05 at <https://wiki.haskell.org/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters> (also see <https://downloads.haskell.org/~ghc/6.4.2/docs/html/users_guide/type-extensions.html#linear-implici…>) |
| 2022-08-17 12:24:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 12:25:29 +0200 | <tdammers> | ah yes, let's get rid of this stupid "scope" thing, too, and just create variables dynamically when they are first assigned, and then we'll invent some keywords you can use to create them in containing scopes insteads |
| 2022-08-17 12:26:35 +0200 | <ski> | i remember, very early on, when learning Haskell, i wondered whether function evaluation was "like CPP macros" (i concluded "no" after testing). what i was wondering was whether it used static/lexical or dynamic scope |
| 2022-08-17 12:29:20 +0200 | <ski> | > let f xs | xs <- 0:xs = xs where xs = 1:xs in f (repeat 1) |
| 2022-08-17 12:29:22 +0200 | <lambdabot> | [0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1... |
| 2022-08-17 12:30:20 +0200 | <dminuoso> | ski: When I taught Haskell to my girlfriend and I explained substitution, she had some similar thoughts. |
| 2022-08-17 12:32:16 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-08-17 12:35:52 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 12:38:59 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 12:42:33 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:82b2:3f67:b114:9dcf) |
| 2022-08-17 12:43:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-08-17 12:47:13 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-08-17 12:47:38 +0200 | vglfr | (~vglfr@145.224.94.221) |
| 2022-08-17 12:49:07 +0200 | ubert | (~Thunderbi@178.165.179.220.wireless.dyn.drei.com) (Ping timeout: 248 seconds) |
| 2022-08-17 12:51:10 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 12:51:30 +0200 | ubert | (~Thunderbi@178.165.179.220.wireless.dyn.drei.com) |
| 2022-08-17 12:55:01 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-08-17 12:55:15 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-08-17 12:55:24 +0200 | nilradical | (~nilradica@user/naso) (Ping timeout: 256 seconds) |
| 2022-08-17 12:55:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 12:57:45 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-08-17 12:58:48 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) (Ping timeout: 256 seconds) |
| 2022-08-17 13:05:02 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 256 seconds) |
| 2022-08-17 13:05:24 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-08-17 13:07:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 13:10:15 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 252 seconds) |
| 2022-08-17 13:10:27 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 248 seconds) |
| 2022-08-17 13:10:45 +0200 | jinsun__ | (~jinsun@user/jinsun) |
| 2022-08-17 13:10:45 +0200 | jinsun | Guest4337 |
| 2022-08-17 13:10:45 +0200 | Guest4337 | (~jinsun@user/jinsun) (Killed (tantalum.libera.chat (Nickname regained by services))) |
| 2022-08-17 13:10:45 +0200 | jinsun__ | jinsun |
| 2022-08-17 13:12:29 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 13:13:51 +0200 | Feuermagier_ | (~Feuermagi@213.149.82.60) |
| 2022-08-17 13:15:15 +0200 | xff0x | (~xff0x@ap007189.d.east.v6connect.net) |
| 2022-08-17 13:15:23 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Ping timeout: 252 seconds) |
| 2022-08-17 13:17:43 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 13:21:28 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 13:22:35 +0200 | <qrpnxz> | haskell application is like *hygenic* macros :) |
| 2022-08-17 13:24:07 +0200 | <hpc> | i just remember that functions are like functions, and it's everyone else that's wrong :D |
| 2022-08-17 13:26:34 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-08-17 13:31:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 13:37:02 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-08-17 13:38:58 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-08-17 13:40:40 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 13:41:18 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 256 seconds) |
| 2022-08-17 13:41:19 +0200 | vglfr | (~vglfr@145.224.94.221) (Read error: Connection reset by peer) |
| 2022-08-17 13:42:07 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) |
| 2022-08-17 13:42:09 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 13:42:30 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Remote host closed the connection) |
| 2022-08-17 13:43:35 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 13:44:57 +0200 | nilradical | (~nilradica@user/naso) (Client Quit) |
| 2022-08-17 13:45:07 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:82b2:3f67:b114:9dcf) (Ping timeout: 248 seconds) |
| 2022-08-17 13:45:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 244 seconds) |
| 2022-08-17 13:46:23 +0200 | vglfr | (~vglfr@145.224.94.221) |
| 2022-08-17 13:46:33 +0200 | instantaphex | (~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds) |
| 2022-08-17 13:48:01 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-08-17 13:52:18 +0200 | ardell | (~ardell@user/ardell) (Quit: Leaving) |
| 2022-08-17 13:54:01 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 268 seconds) |
| 2022-08-17 13:57:58 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-08-17 14:06:16 +0200 | maerwald | (~maerwald@user/maerwald) (Ping timeout: 268 seconds) |
| 2022-08-17 14:10:45 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2022-08-17 14:10:47 +0200 | luffy | (~chenqisu1@183.217.201.23) (Ping timeout: 256 seconds) |
| 2022-08-17 14:11:21 +0200 | nattiestnate | (~nate@180.243.14.130) |
| 2022-08-17 14:14:05 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 14:15:23 +0200 | snak | (~snak@221x252x204x99.ap221.ftth.ucom.ne.jp) (Quit: Client closed) |
| 2022-08-17 14:15:26 +0200 | maerwald | (~maerwald@mail.hasufell.de) |
| 2022-08-17 14:17:16 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-17 14:18:37 +0200 | luffy | (~chenqisu1@183.217.201.23) |
| 2022-08-17 14:18:42 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 256 seconds) |
| 2022-08-17 14:19:31 +0200 | jespada | (~jespada@2803:9800:9842:8ca9:c4f5:ee5c:649d:9f1f) |
| 2022-08-17 14:23:29 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:76d2:ba9c:ee52:a684) |
| 2022-08-17 14:26:17 +0200 | chomwitt | (~chomwitt@2a02:587:dc16:4100:bf02:bf7d:726d:6c5b) |
| 2022-08-17 14:26:29 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-08-17 14:27:23 +0200 | nattiestnate | (~nate@180.243.14.130) (Quit: WeeChat 3.6) |
| 2022-08-17 14:27:53 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 14:28:59 +0200 | benin04 | (~benin@183.82.31.103) |
| 2022-08-17 14:30:20 +0200 | luffy | (~chenqisu1@183.217.201.23) (Ping timeout: 268 seconds) |
| 2022-08-17 14:30:36 +0200 | benin0 | (~benin@183.82.30.34) (Ping timeout: 256 seconds) |
| 2022-08-17 14:30:37 +0200 | benin04 | benin0 |
| 2022-08-17 14:30:56 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 268 seconds) |
| 2022-08-17 14:31:20 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-08-17 14:34:50 +0200 | chomwitt | (~chomwitt@2a02:587:dc16:4100:bf02:bf7d:726d:6c5b) (Ping timeout: 255 seconds) |
| 2022-08-17 14:35:33 +0200 | nattiestnate | (~nate@180.243.14.130) |
| 2022-08-17 14:45:56 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:9186:336c:b8e1:3e66) |
| 2022-08-17 14:47:15 +0200 | kuribas | (~user@ptr-17d51eo65n4u3gc42wc.18120a2.ip6.access.telenet.be) (Read error: Connection reset by peer) |
| 2022-08-17 14:51:33 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) |
| 2022-08-17 14:53:34 +0200 | Feuermagier_ | (~Feuermagi@213.149.82.60) (Quit: Leaving) |
| 2022-08-17 14:53:46 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-08-17 14:56:24 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-08-17 14:56:39 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Remote host closed the connection) |
| 2022-08-17 14:57:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 14:57:14 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-08-17 14:58:07 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) |
| 2022-08-17 14:59:08 +0200 | Feuermagier | (~Feuermagi@user/feuermagier) (Max SendQ exceeded) |
| 2022-08-17 14:59:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 14:59:17 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 14:59:47 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-08-17 15:02:53 +0200 | coot | (~coot@213.134.176.158) |
| 2022-08-17 15:09:38 +0200 | aeka | (~aeka@2606:6080:1002:8:3285:30e:de43:8809) |
| 2022-08-17 15:09:52 +0200 | luffy | (~chenqisu1@183.217.201.23) |
| 2022-08-17 15:12:09 +0200 | <qrpnxz> | stackoverflow cannot be searched without running proprietary javascript :( |
| 2022-08-17 15:13:20 +0200 | geekosaur | doesn't trust stackoverflow much anyway |
| 2022-08-17 15:13:48 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 15:13:56 +0200 | <geekosaur> | the way their system works, it always seems like newcomers answer newcomers often with incorrect answers… |
| 2022-08-17 15:14:22 +0200 | <geekosaur> | (because the experts have to balance answers with moderation) |
| 2022-08-17 15:15:50 +0200 | alp- | alp |
| 2022-08-17 15:18:13 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-08-17 15:19:18 +0200 | ski | . o O ( "Why I no longer contribute to StackOverflow" by ttmrichter (aka Michael T. Richter) in 2013-12 at <https://web.archive.org/web/20140104210553/http://michael.richter.name/blogs/why-i-no-longer-contr…> ) |
| 2022-08-17 15:19:21 +0200 | luffy | (~chenqisu1@183.217.201.23) (Ping timeout: 256 seconds) |
| 2022-08-17 15:20:54 +0200 | riverside | (~riverside@213.205.241.143) |
| 2022-08-17 15:21:07 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2022-08-17 15:21:07 +0200 | waldo | (~waldo@user/waldo) |
| 2022-08-17 15:21:09 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 15:22:29 +0200 | cheater | (~Username@user/cheater) |
| 2022-08-17 15:22:50 +0200 | <tdammers> | for me, SO stopped being fun pretty early on |
| 2022-08-17 15:25:14 +0200 | <geekosaur> | my experience is pretty much ttmrichter's. I still have an account but I pulled back a couple weeks after getting elevated to a moderator in a number of stackexchange communities |
| 2022-08-17 15:27:16 +0200 | <geekosaur> | (although my tags are mostly accurate because I refused to lmgtfy) |
| 2022-08-17 15:27:17 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 256 seconds) |
| 2022-08-17 15:27:57 +0200 | ystael | (~ystael@user/ystael) |
| 2022-08-17 15:31:05 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 15:31:13 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-08-17 15:36:54 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 256 seconds) |
| 2022-08-17 15:37:29 +0200 | <riverside> | can i get key data? |
| 2022-08-17 15:37:51 +0200 | <riverside> | like, without having to press enter |
| 2022-08-17 15:38:11 +0200 | <riverside> | does it require frp? |
| 2022-08-17 15:38:11 +0200 | <geekosaur> | hSetBuffering stdin NoBuffering |
| 2022-08-17 15:38:18 +0200 | <riverside> | tried that, it went mental |
| 2022-08-17 15:38:32 +0200 | <riverside> | i think the NoBuffering was up too high |
| 2022-08-17 15:38:42 +0200 | <geekosaur> | (sadly the ghc runtime conflates buffering with terminal modes; this occasionally breaks programs that expect or need them to be separate) |
| 2022-08-17 15:38:59 +0200 | <riverside> | can do aye |
| 2022-08-17 15:39:08 +0200 | <riverside> | good ol' IO |
| 2022-08-17 15:39:44 +0200 | <riverside> | i guess it needs some keyboard driver? |
| 2022-08-17 15:39:54 +0200 | <riverside> | recalling OpenGL had drivers |
| 2022-08-17 15:40:30 +0200 | <riverside> | though no buffering stdin is exactly what i was trying to do |
| 2022-08-17 15:40:53 +0200 | <riverside> | its supposed to do a command line call depending on what key is pressed |
| 2022-08-17 15:40:56 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-08-17 15:41:02 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-08-17 15:41:13 +0200 | <riverside> | or something like that, idk how to play sound loops otherwise |
| 2022-08-17 15:41:39 +0200 | <riverside> | "turn my keyboard literally into a keyboard" |
| 2022-08-17 15:41:44 +0200 | <geekosaur> | works fine in programs like ghcup (see `ghcup tui`, although it doesn't play sound) |
| 2022-08-17 15:41:56 +0200 | <maerwald> | geekosaur: we can fix that |
| 2022-08-17 15:42:19 +0200 | <riverside> | how would ghcup beat normal ghci repl? |
| 2022-08-17 15:42:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 15:42:27 +0200 | <riverside> | should be the same right? |
| 2022-08-17 15:42:29 +0200 | <maerwald> | I mean wrt playing sounds |
| 2022-08-17 15:42:29 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-08-17 15:42:37 +0200 | <maerwald> | piano mode |
| 2022-08-17 15:42:49 +0200 | <riverside> | so, OpenGl opens a window, as its running the exe |
| 2022-08-17 15:43:05 +0200 | <riverside> | dont actually need the stdio there as they probably have keybaord drivers |
| 2022-08-17 15:43:32 +0200 | <jean-paul[m]> | You don't need to get anywhere near keyboard drivers for this |
| 2022-08-17 15:43:34 +0200 | <jean-paul[m]> | At least on POSIX |
| 2022-08-17 15:43:45 +0200 | <jean-paul[m]> | Your process has a pty, you can do stuff to it. |
| 2022-08-17 15:44:29 +0200 | <riverside> | i should just use opengl right? |
| 2022-08-17 15:44:37 +0200 | <riverside> | i wonder how i get sound though |
| 2022-08-17 15:44:48 +0200 | <riverside> | (basically needs keyboard drivers!) |
| 2022-08-17 15:45:05 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-08-17 15:45:10 +0200 | <riverside> | OpenGL and OpenCL? |
| 2022-08-17 15:46:15 +0200 | <jean-paul[m]> | Should you use OpenGL to read key strokes in a terminal application? No, certainly not. |
| 2022-08-17 15:47:07 +0200 | <riverside> | well how else am i going to get the unbuffered stdio? |
| 2022-08-17 15:47:17 +0200 | <jean-paul[m]> | You just want a library like https://hackage.haskell.org/package/posix-pty-0.2.2/docs/System-Posix-Pty.html but for being on the other side of the pty |
| 2022-08-17 15:47:29 +0200 | <geekosaur[m]> | I'd have one thread for reading from the terminal and another for the sound |
| 2022-08-17 15:47:46 +0200 | <jean-paul[m]> | Oh right it's probably available via a curses wrapper |
| 2022-08-17 15:48:03 +0200 | <jean-paul[m]> | https://hackage.haskell.org/package/hscurses maybe |
| 2022-08-17 15:48:11 +0200 | <geekosaur[m]> | Don't need a pty, you already have one |
| 2022-08-17 15:48:42 +0200 | <riverside> | geekosaur, how would you comunicate between the threads? |
| 2022-08-17 15:48:45 +0200 | <jean-paul[m]> | https://hackage.haskell.org/package/hscurses-1.4.2.0/docs/UI-HSCurses-Curses.html#v:getCh |
| 2022-08-17 15:49:15 +0200 | <jean-paul[m]> | geekosaur: Sure. I meant a library for using your pty to do interesting things. |
| 2022-08-17 15:49:28 +0200 | <jean-paul[m]> | I don't _love_ "curses" as the answer but ... it is an answer. |
| 2022-08-17 15:49:36 +0200 | <geekosaur[m]> | And a Chan connecting them |
| 2022-08-17 15:50:12 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2022-08-17 15:50:52 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-08-17 15:51:46 +0200 | <geekosaur[m]> | But then I'm thinking of the sound thread doing things like sound shaping (e.g. decay) |
| 2022-08-17 15:52:56 +0200 | finsternis | (~X@23.226.237.192) (Read error: Connection reset by peer) |
| 2022-08-17 15:53:53 +0200 | <tomsmeding> | maerwald: elevator music while it's installing ghc? |
| 2022-08-17 15:53:58 +0200 | finsternis | (~X@23.226.237.192) |
| 2022-08-17 15:54:11 +0200 | <tomsmeding> | or crappy phone-line-compressed waiting music |
| 2022-08-17 15:55:18 +0200 | <sm> | could someone explain point 2 at https://github.com/haskell/core-libraries-committee/blob/main/guides/no-monadfail-st-inst.md#how ? I see that it makes GHC happy, but I'm not sure why |
| 2022-08-17 15:56:45 +0200 | <riverside> | i need the dll for windows |
| 2022-08-17 15:57:09 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 15:57:50 +0200 | <tomsmeding> | sm: GHC desugars a (<-) pattern match in do-notation to using `fail` if it fails |
| 2022-08-17 15:58:23 +0200 | <tomsmeding> | `xs' <- someFunc` clearly never fails, and partial matches in a let-binding are always allowed anyway, and will throw a runtime `error` |
| 2022-08-17 15:58:46 +0200 | <riverside> | a makefile, really? https://pdcurses.org/wincon/ |
| 2022-08-17 15:58:47 +0200 | <tomsmeding> | @undo do { x:xs <- l ; return x } |
| 2022-08-17 15:58:47 +0200 | <lambdabot> | l >>= \ a -> case a of { x : xs -> return x; _ -> fail ""} |
| 2022-08-17 15:58:51 +0200 | <tomsmeding> | sm: ^ |
| 2022-08-17 15:58:58 +0200 | <sm> | failed partial matches in a let binding call error, not fail ? Ah I see, thanks tomsmeding |
| 2022-08-17 15:59:03 +0200 | <jean-paul[m]> | riverside: Eh... I did say "POSIX". |
| 2022-08-17 15:59:15 +0200 | <riverside> | to the wsl! |
| 2022-08-17 15:59:25 +0200 | <tomsmeding> | sm: I guess it makes sense that the semantics of failed let bindings do not depend on where said let bindings occur :p |
| 2022-08-17 15:59:27 +0200 | <jean-paul[m]> | riverside: If you're on Windows you're not writing a terminal app, you're writing something else. |
| 2022-08-17 15:59:32 +0200 | <riverside> | its on spt-get? |
| 2022-08-17 15:59:35 +0200 | <riverside> | apt* |
| 2022-08-17 15:59:42 +0200 | <sm> | what error message do they show, I wonder |
| 2022-08-17 15:59:52 +0200 | <riverside> | they say X11 |
| 2022-08-17 15:59:55 +0200 | <tomsmeding> | > let x:_ = [] in x |
| 2022-08-17 15:59:56 +0200 | <lambdabot> | *Exception: <interactive>:3:5-12: Non-exhaustive patterns in x : _ |
| 2022-08-17 15:59:57 +0200 | <sm> | I'd better use a case and set my own message |
| 2022-08-17 15:59:59 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 16:00:23 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-08-17 16:00:25 +0200 | <tomsmeding> | > do { x:_ <- Just [] ; return x } |
| 2022-08-17 16:00:27 +0200 | <lambdabot> | Nothing |
| 2022-08-17 16:00:31 +0200 | <tomsmeding> | oh heh |
| 2022-08-17 16:00:37 +0200 | <tomsmeding> | MonadFail for Maybe is kinda boring |
| 2022-08-17 16:00:42 +0200 | o-90 | (~o-90@gateway/tor-sasl/o-90) |
| 2022-08-17 16:01:03 +0200 | <tomsmeding> | % do { x:_ <- return [] ; return x } |
| 2022-08-17 16:01:03 +0200 | <yahb2> | *** Exception: user error (Pattern match failure in do expression at <interactive>:66:6-8) |
| 2022-08-17 16:01:31 +0200 | o-90 | (~o-90@gateway/tor-sasl/o-90) (Remote host closed the connection) |
| 2022-08-17 16:01:50 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-08-17 16:02:19 +0200 | <riverside> | sudo yum install ncurses-devel |
| 2022-08-17 16:02:36 +0200 | <riverside> | sudo apt-get install libncurses5-dev libncursesw5-dev |
| 2022-08-17 16:02:51 +0200 | <riverside> | should work for windows under wsl |
| 2022-08-17 16:04:19 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 248 seconds) |
| 2022-08-17 16:04:19 +0200 | <riverside> | ok, so then if that works dont need opengl for the window and keyboard interface |
| 2022-08-17 16:04:24 +0200 | <riverside> | but then what about the soundcard? |
| 2022-08-17 16:04:27 +0200 | cheater | (~Username@user/cheater) |
| 2022-08-17 16:10:17 +0200 | <jean-paul[m]> | OpenAL maybe (saying this with a full 10 years since the last time I tried to write a program that plays sound) |
| 2022-08-17 16:11:57 +0200 | riverside | (~riverside@213.205.241.143) (Remote host closed the connection) |
| 2022-08-17 16:12:43 +0200 | <qrpnxz> | for audio i've used pulseaudio, dunno what to use in windows, openal maybe, but something like SDL seem simpler? |
| 2022-08-17 16:12:58 +0200 | waldo | (~waldo@user/waldo) (Quit: quit) |
| 2022-08-17 16:13:21 +0200 | Henson | (~kvirc@207.136.101.195) |
| 2022-08-17 16:14:02 +0200 | <jean-paul[m]> | pulseaudio probably being replaced by pipewire now right? |
| 2022-08-17 16:14:07 +0200 | kuribas | (~user@ptr-17d51em3ydspl0uuwo7.18120a2.ip6.access.telenet.be) |
| 2022-08-17 16:14:18 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 16:14:40 +0200 | snak | (~snak@221x252x204x99.ap221.ftth.ucom.ne.jp) |
| 2022-08-17 16:14:51 +0200 | <Henson> | I've got a bit of an obscure question. I'm using Haskell to call into C++ to perform a computation. The C++ has been compiled using OpenMP support and does computations in parallel. OpenMP seems to work when I call the function in Haskell as a thread using "async" and makes use of my computer's multiple cores, but when I call the function without spawning it a separate thread, OpenMP.... |
| 2022-08-17 16:15:50 +0200 | <qrpnxz> | jean-paul[m]: pretty much yes. I wrote my program just when pipewire was becoming a thing |
| 2022-08-17 16:16:13 +0200 | <Henson> | only thinks there's 1 CPU core and does not parallelize. Does anybody have any ideas as to why this might be? The executable is compiled with "+RTS -N" so it's able to make use of multiple cores. I thought this might be irrelevant, though, as OpenMP at the C++ layer should do its own thing, but that doesn't seem to be the case. |
| 2022-08-17 16:17:48 +0200 | Furor | (~colere@about/linux/staff/sauvin) |
| 2022-08-17 16:17:51 +0200 | <tomsmeding> | Henson: that probably depends mostly on how exactly OpenMP decides how many threads to start |
| 2022-08-17 16:18:19 +0200 | Henson | tries something |
| 2022-08-17 16:18:32 +0200 | <qrpnxz> | no idea, but if it works with async you could make a little wrapper that runs it in async but it looks like just another IO action |
| 2022-08-17 16:18:39 +0200 | <tomsmeding> | sounds very fishy though |
| 2022-08-17 16:19:31 +0200 | <lortabac> | Henson: maybe it's related to bound/unbound threads? https://hackage.haskell.org/package/base-4.16.2.0/docs/Control-Concurrent.html#g:8 |
| 2022-08-17 16:20:11 +0200 | Colere | (~colere@about/linux/staff/sauvin) (Ping timeout: 252 seconds) |
| 2022-08-17 16:20:12 +0200 | <sm> | riverside: I had good luck using the sox command line tool for cross platform sound |
| 2022-08-17 16:20:24 +0200 | <sm> | "To enable sound effects, install sox in PATH: do apt install sox, brew install sox, choco install sox.portable or similar." |
| 2022-08-17 16:20:26 +0200 | <geekosaur> | openmp shouldn't care unless there's a setup function involved plus TLS, and even then it sounds backwards because the async would be using an unbound thread |
| 2022-08-17 16:21:14 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 16:21:21 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 16:22:42 +0200 | <Henson> | hmm, something fishy /is/ going on. Now it seems to be working properly when called directly. |
| 2022-08-17 16:22:43 +0200 | <qrpnxz> | to me it makes a little more sense because bound thread may mean that it just sees that one thread? |
| 2022-08-17 16:23:00 +0200 | <qrpnxz> | ah well it may just be openmp doesn't always init threads then |
| 2022-08-17 16:23:08 +0200 | <qrpnxz> | which make sense |
| 2022-08-17 16:23:12 +0200 | <qrpnxz> | because parallel has overhead |
| 2022-08-17 16:23:40 +0200 | <Henson> | lortabac: could potentially be related. When using "async" the following non-async direct call was not parallelizing. When switching to "asyncBound" for the parallel test (which worked) the following non-async direct call suddenly was parallelized. |
| 2022-08-17 16:24:20 +0200 | <qrpnxz> | if the first threads were still active it may have decided that making more threads was not worth it because they were already put to work? |
| 2022-08-17 16:24:24 +0200 | <Henson> | I'll see if I can get the old behaviour back and then force the non-async version to use multiple threads instead of auto-detecting the number of threads, and see what happens |
| 2022-08-17 16:25:07 +0200 | <geekosaur> | bound thread just means that the rts always runs the haskell thread on the same cpu thread |
| 2022-08-17 16:25:11 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) |
| 2022-08-17 16:25:14 +0200 | <geekosaur> | doesn't change cpu thread visibility |
| 2022-08-17 16:25:16 +0200 | <Henson> | qrpnxz: I was simply calling omp_get_num_threads() within a parallel section, which should tell me how many threads OpenMP thinks are available for use. |
| 2022-08-17 16:25:37 +0200 | <geekosaur> | and the c++ side will have no clue about the haskell side |
| 2022-08-17 16:25:48 +0200 | <qrpnxz> | geekosaur: makes sense |
| 2022-08-17 16:26:12 +0200 | <Henson> | geekosaur: yeah, I don't see how the switch from async to asyncBound could affect the non-async call, but it was just an observation. There definitely seems to be something non-deterministic happening, so I'll see if I can figure it out. |
| 2022-08-17 16:28:19 +0200 | <geekosaur> | are you making any other calls? visibility (or not) of data in thread-local storage may matter, and that's what bound threads are about is making sure TLS is maintained for foreign calls |
| 2022-08-17 16:28:42 +0200 | <Henson> | hmm, could one thing be that the function I'm calling is an IO function that's behind an "unsafePerformIO"? The foreign import is called as "safe" though, and I'm using no-cse and NO-INLINE on the "pure" version of the function, so I think I'm following best-practices for calling this function. The C++ function is also properly referentially-transparent, so I don't think I'm violating any... |
| 2022-08-17 16:29:03 +0200 | <Henson> | immutability requirements by using unsafePerformIO. But that's another avenue I can track down to see where the non-determinism is coming from. |
| 2022-08-17 16:29:21 +0200 | <geekosaur> | unsafePerformIO shouldn't matter if it's safe and referentially transparent |
| 2022-08-17 16:29:27 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds) |
| 2022-08-17 16:29:40 +0200 | <geekosaur> | unless you're wrong about the latter, which can happen all too easily |
| 2022-08-17 16:30:35 +0200 | <geekosaur> | oh, it's not allowed to block for any reason and I find that invariant somewhat unlikely if it's managing other threads |
| 2022-08-17 16:30:36 +0200 | <Henson> | geekosaur: I don't know if OpenMP makes use of TLS, though. I'm using OpenCV function calls within the parallel sections on the C++ functions. Nonetheless, this wouldn't explain how OpenMP suddenly thinks there are more CPUs available. |
| 2022-08-17 16:31:01 +0200 | <geekosaur> | but that shouldn't affect the OpenMP side of things, only the ghc runtime |
| 2022-08-17 16:31:46 +0200 | <Henson> | geekosaur: it wouldn't block in a way that will cause a deadlock, as it's just parallelizing over a couple expensive embarrasingly-parallel for loops. |
| 2022-08-17 16:32:03 +0200 | ubert | (~Thunderbi@178.165.179.220.wireless.dyn.drei.com) (Ping timeout: 248 seconds) |
| 2022-08-17 16:33:19 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:76d2:ba9c:ee52:a684) (Quit: WeeChat 2.8) |
| 2022-08-17 16:33:31 +0200 | <geekosaur> | mm, actually the blocking constraint comes from "unsafe" which you;re not doing. unsafePerformIO should be fine if the function is actually pure and referentially transparent |
| 2022-08-17 16:33:45 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 2022-08-17 16:34:58 +0200 | <Henson> | ok, I'll keep smashing this with some hammers and see what happens. You've all given me some ideas of avenues to investigate. Thank you. |
| 2022-08-17 16:37:33 +0200 | jero98772 | (~jero98772@2800:484:1d80:d8ce:efcc:cbb3:7f2a:6dff) |
| 2022-08-17 16:39:21 +0200 | maerwald | (~maerwald@mail.hasufell.de) (Changing host) |
| 2022-08-17 16:39:21 +0200 | maerwald | (~maerwald@user/maerwald) |
| 2022-08-17 16:40:13 +0200 | <tomsmeding> | Henson: I would also be curious whether std::thread::hardware_concurrency() ever disagrees with omp_get_num_threads() |
| 2022-08-17 16:40:24 +0200 | <geekosaur> | the real risk from unsafePerformIO is that ghc might enter the extern call twice from different threads, believing that the result can't change regardless of which one returns |
| 2022-08-17 16:40:57 +0200 | <geekosaur> | that might conceivably affect the number of visible threads openmp sees, but it also requires that your haskell code admit that possibility to begin with |
| 2022-08-17 16:41:00 +0200 | snak | (~snak@221x252x204x99.ap221.ftth.ucom.ne.jp) (Quit: Client closed) |
| 2022-08-17 16:41:01 +0200 | Furor | Colere |
| 2022-08-17 16:41:20 +0200 | <geekosaur> | (i.e. is capable of entering the foreign call twice) |
| 2022-08-17 16:43:23 +0200 | <geekosaur> | what might conceivably matter here is that the main thread is special (not merely bound) in all OSes and language runtimes. but that would be an odd restriction to affect openMP |
| 2022-08-17 16:43:44 +0200 | <tomsmeding> | I would hope that openmp cares not about that |
| 2022-08-17 16:43:58 +0200 | <geekosaur> | seeing as how the point of them is to escape those restrictions |
| 2022-08-17 16:44:57 +0200 | <Henson> | tomsmeding: I'll add a call to that function as well |
| 2022-08-17 16:46:08 +0200 | riverside | (~riverside@213.205.241.143) |
| 2022-08-17 16:47:37 +0200 | examors_ | examors |
| 2022-08-17 16:47:44 +0200 | <Henson> | tomsmeding: ok, so now the problem has manifested again, and OpenMP and harware_concurrency disagree. OpenMP is wrong, hardware_concurrency is right. |
| 2022-08-17 16:47:53 +0200 | <tomsmeding> | interesting! |
| 2022-08-17 16:48:14 +0200 | <tomsmeding> | luckily hardware_concurrency() doesn't do anything fishy |
| 2022-08-17 16:50:50 +0200 | <tomsmeding> | Henson: is it just omp_get_num_threads() that is wrong, or does the program actually only use one core? |
| 2022-08-17 16:51:02 +0200 | <tomsmeding> | in any case, omp_set_num_threads() apparently exists |
| 2022-08-17 16:51:44 +0200 | <Henson> | tomsmeding: just tested that. omp_get_num_threads is wrong, and the program does use one core. Even when explicitly instructed to use 2 cores, it only seems to be able to use 1. |
| 2022-08-17 16:51:46 +0200 | <tomsmeding> | I'm looking at the openmp spec ( https://www.openmp.org/spec-html/5.0/openmpsu32.html#x51-710002.5.3 ) and I'm realising that knowing nothing about openmp is _not_ conducive to understanding what's going on |
| 2022-08-17 16:51:56 +0200 | <tomsmeding> | "The value of the nthreads-var ICV is a list. The runtime call omp_set_num_threads sets the value of the first element of this list, and omp_get_max_threads retrieves the value of the first element of this list." ??????? |
| 2022-08-17 16:52:37 +0200 | <tomsmeding> | also stuff like: nthreads-var: "There is one copy of this ICV per data environment." -- I wonder, how many data environments do you have? |
| 2022-08-17 16:53:22 +0200 | tomsmeding | is completely confused and closes the website |
| 2022-08-17 16:53:35 +0200 | hippoid | (~idris@c-98-220-13-8.hsd1.il.comcast.net) |
| 2022-08-17 16:53:50 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 16:55:11 +0200 | <tomsmeding> | also omp_get_max_threads vs omp_get_num_threads -- according to the above quote, omp_set_num_threads constrols the value that omp_get_MAX_threads returns |
| 2022-08-17 16:55:13 +0200 | <Henson> | switching from async to asyncBound also doesn't seem to affect the non-async behaviour of the call, fortunately. |
| 2022-08-17 16:55:24 +0200 | shriekingnoise | (~shrieking@186.137.167.202) |
| 2022-08-17 16:56:02 +0200 | geekosaur[m] | is starting to think this sounds like an uninitialized variable |
| 2022-08-17 16:56:32 +0200 | <tomsmeding> | which feels like thread-local storage issues |
| 2022-08-17 16:56:36 +0200 | <geekosaur[m]> | Or similar |
| 2022-08-17 16:57:38 +0200 | <geekosaur[m]> | Or just a missing initialization call |
| 2022-08-17 16:57:43 +0200 | <Henson> | let me try a trick that worked in the past for TLS issues |
| 2022-08-17 16:58:40 +0200 | <Henson> | hmm, no |
| 2022-08-17 16:58:58 +0200 | Henson | continues tinkering |
| 2022-08-17 17:06:54 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-08-17 17:07:03 +0200 | <ski> | > runST (do Just x <- return Nothing; return x) |
| 2022-08-17 17:07:04 +0200 | <lambdabot> | *Exception: Pattern match failure in do expression at <interactive>:3:11-16 |
| 2022-08-17 17:07:11 +0200 | <ski> | > runST (do ~(Just x) <- return Nothing; return x) |
| 2022-08-17 17:07:13 +0200 | <lambdabot> | *Exception: <interactive>:3:11-37: Non-exhaustive patterns in Just x |
| 2022-08-17 17:07:46 +0200 | <ski> | @undo do ~(Just x) <- return Nothing; return x |
| 2022-08-17 17:07:46 +0200 | <lambdabot> | return Nothing >>= \ ~(Just x) -> return x |
| 2022-08-17 17:09:10 +0200 | alternateved | (~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection) |
| 2022-08-17 17:12:06 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-08-17 17:15:32 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-08-17 17:17:00 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a0595bd943540671dc0.dip0.t-ipconnect.de) |
| 2022-08-17 17:20:03 +0200 | acidjnk | (~acidjnk@p200300d6e7137a0595bd943540671dc0.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2022-08-17 17:22:53 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-08-17 17:23:31 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-08-17 17:25:26 +0200 | tinwood_ | (~tinwood@general.default.akavanagh.uk0.bigv.io) (Remote host closed the connection) |
| 2022-08-17 17:26:16 +0200 | Taneb0 | (~Taneb@runciman.hacksoc.org) |
| 2022-08-17 17:26:38 +0200 | tinwood | (~tinwood@general.default.akavanagh.uk0.bigv.io) |
| 2022-08-17 17:26:38 +0200 | tinwood | (~tinwood@general.default.akavanagh.uk0.bigv.io) (Changing host) |
| 2022-08-17 17:26:38 +0200 | tinwood | (~tinwood@canonical/tinwood) |
| 2022-08-17 17:27:19 +0200 | Taneb | (~Taneb@2001:41c8:51:10d:aaaa:0:aaaa:0) (Ping timeout: 244 seconds) |
| 2022-08-17 17:27:55 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 17:28:33 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-08-17 17:28:38 +0200 | nilradical | (~nilradica@user/naso) |
| 2022-08-17 17:30:19 +0200 | <qrpnxz> | imagine if MonadState RealWord# IO worked. Then we could rewind the universe 😈. STM is a little bit like that. I wonder if you could actually wrap an SQL API (or other transactional API) with STM such that you could do work with them the same way one does TVars. That's be pretty cool. |
| 2022-08-17 17:31:38 +0200 | <geekosaur> | STM doesn't work across processes, much less machines |
| 2022-08-17 17:31:50 +0200 | <geekosaur> | and anything more than a couple of TVars would work poorly |
| 2022-08-17 17:32:02 +0200 | <c_wraith> | It'd be limited in the same ways STM is.. No ability to make decisions based on IO inside a transaction |
| 2022-08-17 17:32:25 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2022-08-17 17:32:31 +0200 | <c_wraith> | eh, STM doesn't *need* to be implemented with optimistic locking. |
| 2022-08-17 17:34:37 +0200 | <qrpnxz> | STM Tvars don't work across processes doesn't mean other abstractions couldn't. |
| 2022-08-17 17:36:02 +0200 | <c_wraith> | the IO thing is a big issue, though. Databases are often used in ways where that would matter. |
| 2022-08-17 17:36:49 +0200 | <c_wraith> | And if you decide to allow arbitrary IO inside of transactions, you need to get rid of the automatic retry that makes STM work so nicely. |
| 2022-08-17 17:37:53 +0200 | <qrpnxz> | i would ofc want both a way to do sql transactions in both IO and STM, not just STM. |
| 2022-08-17 17:38:07 +0200 | bliminse | (~bliminse@user/bliminse) (Quit: leaving) |
| 2022-08-17 17:39:41 +0200 | <qrpnxz> | i'm just not sure what it would take to create a safe SQL version in STM. I don't know what way to tell haskell "if the STM fails, do this". I guess it's just not made for that, but it seems general enough to be useful. Like a resourcet but for transactions. |
| 2022-08-17 17:39:52 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-08-17 17:40:25 +0200 | f-a | (f2a@f2a.jujube.ircnow.org) |
| 2022-08-17 17:40:40 +0200 | f-a | (f2a@f2a.jujube.ircnow.org) () |
| 2022-08-17 17:41:11 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 17:41:40 +0200 | <c_wraith> | there's an idea there, but I'm afraid it wouldn't end up much like STM. It'd be something with relatively different semantics. |
| 2022-08-17 17:42:41 +0200 | <c_wraith> | One relatively obvious thing is a wrapper for existing database transactions where you turn up the isolation level all the way to serializable, then provide an interface that doesn't allow IO and does automatic retries |
| 2022-08-17 17:43:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 17:43:40 +0200 | <c_wraith> | That would cover a lot of use cases with a high degree of safety |
| 2022-08-17 17:44:33 +0200 | <riverside> | anyone with any experience with SDL_Audio? |
| 2022-08-17 17:44:45 +0200 | <riverside> | https://hackage.haskell.org/package/sdl2-2.5.3.3/docs/SDL-Audio.html |
| 2022-08-17 17:45:45 +0200 | <ski> | qrpnxz : fwiw, Mercury can memoize/table world state tokens, for "retry" (going back in time) for debugging. primitive operations will merely repeat the result they gave last time, rather than actually performing the I/O |
| 2022-08-17 17:45:50 +0200 | <riverside> | why not just have a propper buffered time window segmentation |
| 2022-08-17 17:46:22 +0200 | <qrpnxz> | ski: that's nice. |
| 2022-08-17 17:46:24 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 17:46:49 +0200 | <riverside> | its a "live streaming setting" specifically |
| 2022-08-17 17:47:01 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 17:47:09 +0200 | <qrpnxz> | ski: i can't find the relevant mercury thing |
| 2022-08-17 17:47:22 +0200 | <riverside> | mailboxes work from actor models |
| 2022-08-17 17:48:13 +0200 | <riverside> | for thread interaction, and they read then synchronously in a one at a time nearest neighbour factorisation of some combination of seperate threads combining to make an overall function graph |
| 2022-08-17 17:48:52 +0200 | <riverside> | this requires something like a disk write, though i think a UDP port might work, or something for fixed word sizes |
| 2022-08-17 17:49:09 +0200 | <riverside> | otherwise TCP i guess |
| 2022-08-17 17:49:13 +0200 | <ski> | qrpnxz : "Idempotent I/O for safe time travel" by Zoltan Somogyi in 2003-09 at <https://www.mercurylang.org/documentation/papers.html#aadebug03-paper> |
| 2022-08-17 17:49:36 +0200 | <qrpnxz> | riverside: API seems to take a callback for writing to an audio buffer. What's the problem, exactly? |
| 2022-08-17 17:49:51 +0200 | <qrpnxz> | mercury language ah |
| 2022-08-17 17:49:53 +0200 | <qrpnxz> | thx |
| 2022-08-17 17:50:12 +0200 | <riverside> | i cant get at the soundcard from haskell, i cant make sound come from the speakers or headset |
| 2022-08-17 17:50:30 +0200 | <riverside> | code snippit if it exists would be preddy useful |
| 2022-08-17 17:50:42 +0200 | <ski> | (iirc, OCaml also has some kind of back-in-time debugging, although i think it relies on regular snapshots, rather than backtracking/trailing or so .. also, i dunno if it does I/O tabling) |
| 2022-08-17 17:51:34 +0200 | <riverside> | last time there was a problem with buffers being quite long and introducing lag |
| 2022-08-17 17:51:40 +0200 | <qrpnxz> | ski: oh i get that now. Really nice! Sounds kind of expensive tho? |
| 2022-08-17 17:52:18 +0200 | <ski> | it says "The overhead of this mechanism is low enough and can be controlled well enough to make it practical to use it to debug computations that do significant amounts of I/O." |
| 2022-08-17 17:52:29 +0200 | <riverside> | you really want to be able to follow the build/fold fusion down to emiting actual speaker movements or something |
| 2022-08-17 17:52:32 +0200 | <qrpnxz> | but that is neat because it allows you to replay an effectful stream. Which for a lib i'm working on is a big no-no |
| 2022-08-17 17:52:44 +0200 | <riverside> | ie not using buffers but being granular through a fold |
| 2022-08-17 17:53:33 +0200 | janus | (janus@anubis.0x90.dk) |
| 2022-08-17 17:54:27 +0200 | <riverside> | and if not, any interface that can emit a buffers worth of sound |
| 2022-08-17 17:54:35 +0200 | <qrpnxz> | mmm, no. You need a buffer. I mean, you could abstract away the buffer, but it's always gonna be there. That's how all audio interfaces work. Not buffering (especially in haskell boxed types) would be way too slow. |
| 2022-08-17 17:55:06 +0200 | <riverside> | sure, any example of that would do |
| 2022-08-17 17:55:31 +0200 | bliminse | (~bliminse@user/bliminse) |
| 2022-08-17 17:55:47 +0200 | <riverside> | *least sufficient search term straining* |
| 2022-08-17 17:56:08 +0200 | <riverside> | the c lib must be easy to build on wsl |
| 2022-08-17 17:56:09 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 17:56:17 +0200 | <riverside> | oh shit and how to do the soundcard through that |
| 2022-08-17 17:56:45 +0200 | <qrpnxz> | have you tried not using windows. It's great |
| 2022-08-17 17:56:47 +0200 | <ski> | qrpnxz : i guess, vaguely related to lazy I/O as well |
| 2022-08-17 17:56:49 +0200 | <c_wraith> | SDL also provides the raw interfaces, direct C bindings of the SDL interfaces |
| 2022-08-17 17:56:59 +0200 | <c_wraith> | err, the haskell SDL library also provides.... |
| 2022-08-17 17:57:10 +0200 | <riverside> | SDL-Audio seemed like it was worth a try |
| 2022-08-17 17:57:26 +0200 | <c_wraith> | there's SDL.Raw.Audio |
| 2022-08-17 17:58:27 +0200 | <qrpnxz> | sdl haskell lib pretty nice 😃 good to know |
| 2022-08-17 17:59:24 +0200 | <riverside> | so this is all a load of givverish to me, is there a higher level interface? https://hackage.haskell.org/package/sdl2-2.5.3.3/docs/SDL-Audio.html |
| 2022-08-17 17:59:48 +0200 | <ski> | (fwiw, <https://www.swi-prolog.org/pldoc/man?section=pio> implements lazy I/O, in SWI-Prolog) |
| 2022-08-17 18:00:48 +0200 | <ski> | (the lazy list memoizes the characters read from the stream/handle) |
| 2022-08-17 18:00:54 +0200 | <riverside> | if your not streaming you can opperato on the transpose of the buffer |
| 2022-08-17 18:01:12 +0200 | <riverside> | for the simitanious "per itteration scope" |
| 2022-08-17 18:02:01 +0200 | <riverside> | todo with the centrality of state transfer in timeseries |
| 2022-08-17 18:02:12 +0200 | <ski> | (and <https://smlfamily.github.io/Basis/stream-io.html> in SML does the same .. although you get a chunk at a time, not just a character) |
| 2022-08-17 18:02:49 +0200 | nilradical | (~nilradica@user/naso) () |
| 2022-08-17 18:03:08 +0200 | <riverside> | ski: this is a simple example of monadic tailing |
| 2022-08-17 18:03:20 +0200 | <riverside> | they have a sequential graphi in the IO monad emulating a timeseries |
| 2022-08-17 18:03:39 +0200 | <riverside> | ListT IO |
| 2022-08-17 18:04:17 +0200 | <c_wraith> | funny, that's exactly the type streaming libraries are intended to replace |
| 2022-08-17 18:04:49 +0200 | <riverside> | well the IO bit is kind of required for any live interfacing |
| 2022-08-17 18:04:55 +0200 | <riverside> | so any interfacing at all i guess |
| 2022-08-17 18:05:13 +0200 | <riverside> | could just be an emitter |
| 2022-08-17 18:05:23 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 248 seconds) |
| 2022-08-17 18:05:36 +0200 | <geekosaur[m]> | riverside, I think the only higher level with audio is MIDI patches, which requires MIDI hardware or an emulator |
| 2022-08-17 18:05:37 +0200 | <riverside> | oh but yeah, if its to ever have any effect, "the time is now" and if it cant do that |
| 2022-08-17 18:05:54 +0200 | <riverside> | needs IO for real woulrd input And output |
| 2022-08-17 18:06:14 +0200 | <riverside> | you just dont want to do threading |
| 2022-08-17 18:06:46 +0200 | <riverside> | and are having a boundary problem todo with a monad section under bind splitting between within running programs and between them |
| 2022-08-17 18:07:20 +0200 | <riverside> | mailboxes partition nicely between running programs in a partitioned program graph |
| 2022-08-17 18:07:40 +0200 | <riverside> | implementing a state transfer formalism for "unrolling programs in time" |
| 2022-08-17 18:08:02 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-17 18:08:02 +0200 | <riverside> | here "time" being its interaction with us here in the real world via IO |
| 2022-08-17 18:08:09 +0200 | <riverside> | IO = Time in this setting |
| 2022-08-17 18:08:18 +0200 | <riverside> | or like, RealTime |
| 2022-08-17 18:08:34 +0200 | <riverside> | as in, when the thread communications happen |
| 2022-08-17 18:08:41 +0200 | <riverside> | or their buffered counterpart |
| 2022-08-17 18:08:55 +0200 | <riverside> | buffers can transpose so no need for composition of scanners |
| 2022-08-17 18:09:14 +0200 | <riverside> | can get column wise calculations that way |
| 2022-08-17 18:09:24 +0200 | <riverside> | by using map |
| 2022-08-17 18:09:31 +0200 | <riverside> | and transpose |
| 2022-08-17 18:09:40 +0200 | <riverside> | transpose somehow neatly doing all the scanning part there |
| 2022-08-17 18:09:45 +0200 | ccapndave | (~ccapndave@mob-194-230-146-204.cgn.sunrise.net) |
| 2022-08-17 18:10:53 +0200 | kenran | (~kenran@200116b82b7885000a30634e15848455.dip.versatel-1u1.de) |
| 2022-08-17 18:11:31 +0200 | <riverside> | and you can of course scan it aswell, then instead of scanning over the seperate threads, your scanning over the combined heads with one opperation, which has the full "vector" or whatever, of state data for the current time segment |
| 2022-08-17 18:12:02 +0200 | <riverside> | per-itteration state transfer within the finite time widthed buffer |
| 2022-08-17 18:12:46 +0200 | <riverside> | and then the concurrency is when this spreads between programs |
| 2022-08-17 18:13:29 +0200 | <riverside> | again, instead of scanning monoid concatination, which is required usually in generation of blocks of data |
| 2022-08-17 18:13:55 +0200 | <riverside> | if able to simply map over an *available* block, then the transpose can be taken instead of the sequential scanning monoid ever appearing |
| 2022-08-17 18:14:25 +0200 | <riverside> | well, really, fold over the transposed block into columns |
| 2022-08-17 18:14:32 +0200 | <riverside> | with the output IO opperation |
| 2022-08-17 18:14:50 +0200 | <geekosaur> | riverside, does this have context? |
| 2022-08-17 18:14:52 +0200 | <riverside> | its a scanner still though really |
| 2022-08-17 18:14:55 +0200 | zebrag | (~chris@user/zebrag) |
| 2022-08-17 18:15:31 +0200 | <riverside> | geekosaur: yes, the live streaming context was that of outputing to an api that could play segments of music in a poorted interface from some C lib |
| 2022-08-17 18:16:12 +0200 | <riverside> | geekosaur: in order to connect keystrokes to sound triggers |
| 2022-08-17 18:16:26 +0200 | <c_wraith> | riverside: maybe take a look at tidal. not as a library necessarily, but look at how it does stuff |
| 2022-08-17 18:16:33 +0200 | <riverside> | which required the concurrent threading *between* programs, which is scary cos it splits the graph |
| 2022-08-17 18:16:45 +0200 | <c_wraith> | https://hackage.haskell.org/package/tidal |
| 2022-08-17 18:16:52 +0200 | ccapndave | (~ccapndave@mob-194-230-146-204.cgn.sunrise.net) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-08-17 18:16:53 +0200 | <geekosaur> | I'm wondering if you're reinventing MIDI |
| 2022-08-17 18:17:15 +0200 | <riverside> | problys |
| 2022-08-17 18:17:22 +0200 | <ski> | dunno what you mean by "transpose", here |
| 2022-08-17 18:17:23 +0200 | <geekosaur> | last time I checked MIDI emulators came with a very limited selection of patches, but that was in the 90s |
| 2022-08-17 18:17:32 +0200 | <riverside> | no, its a live stream with non-overlapping segmentation |
| 2022-08-17 18:17:41 +0200 | <ski> | what kind of patches ? |
| 2022-08-17 18:17:43 +0200 | <c_wraith> | riverside: really, look at tidal |
| 2022-08-17 18:17:52 +0200 | <riverside> | you just waant to be able to push the buffer to a que and ensure it will pllay in a given time segment in real time |
| 2022-08-17 18:18:02 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 18:19:11 +0200 | <riverside> | i super low latency sound prlayer would work if you tricked it with some offsets so it played nicely at the right time |
| 2022-08-17 18:19:24 +0200 | <riverside> | but really thats why we want interface to a c lib bound within haskell |
| 2022-08-17 18:19:43 +0200 | <c_wraith> | tidal is all about scheduling playback of samples or synths |
| 2022-08-17 18:20:13 +0200 | <riverside> | c_wraith: i cant see if they managed to emit sound easily from what i can see of their project nothing obvious |
| 2022-08-17 18:20:57 +0200 | <riverside> | a link to anything playing a buffer of sound would be super useful |
| 2022-08-17 18:21:46 +0200 | <riverside> | > 60/(3*2^14/44100) |
| 2022-08-17 18:21:48 +0200 | <lambdabot> | 53.8330078125 |
| 2022-08-17 18:22:22 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-08-17 18:22:51 +0200 | <riverside> | bpm |
| 2022-08-17 18:24:46 +0200 | <riverside> | i think mailboxes introduce a lag that requires a buffer of a particular size |
| 2022-08-17 18:25:05 +0200 | <riverside> | to guarantee synchronous reads |
| 2022-08-17 18:25:31 +0200 | <riverside> | its always one buffer behind, obviously |
| 2022-08-17 18:25:34 +0200 | ccapndave | (~ccapndave@mob-194-230-146-204.cgn.sunrise.net) |
| 2022-08-17 18:25:44 +0200 | <geekosaur> | ski, a MIDI patch is basically a digitized segment of sound that the MIDI device/emulator can play bback as is or modified (pitch, attack/delay, etc.) |
| 2022-08-17 18:26:02 +0200 | <riverside> | and this lag is critical, too much so to use read and write to disk!? how isnt that the fastest thing? |
| 2022-08-17 18:26:14 +0200 | <riverside> | have to write just to ram somehow |
| 2022-08-17 18:26:23 +0200 | <geekosaur> | spinning rust is slow 🙂 |
| 2022-08-17 18:26:39 +0200 | <riverside> | i dont think 2 haskel programs can share ram, so write to disk is it really, just standard mailboxes |
| 2022-08-17 18:27:27 +0200 | <riverside> | since theres just one stream of output thread, and one responding driven thread, its just one message, a file write, to be read by another part of the program |
| 2022-08-17 18:27:52 +0200 | <riverside> | er, well, having it in two programs would mean you would have to do that |
| 2022-08-17 18:28:31 +0200 | <riverside> | but if you have them in one program then you just monoid it all together anyway to get the columns and could just use a transposed buffer for that reason, and then it could be kept very short |
| 2022-08-17 18:28:51 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 18:29:08 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-08-17 18:29:16 +0200 | <riverside> | or just combine scanners if doing something like zipping or zipping with the streams to try and implement a message passing graph of scanning functions |
| 2022-08-17 18:29:33 +0200 | <riverside> | or wrap it all up neatly in transpose |
| 2022-08-17 18:29:57 +0200 | <riverside> | so i just need to be able to drop a piece of sound over precisely the correct time. |
| 2022-08-17 18:30:08 +0200 | <riverside> | so i implement some kind of crude calculated pause |
| 2022-08-17 18:30:21 +0200 | <riverside> | and then it just calls a function |
| 2022-08-17 18:30:29 +0200 | <riverside> | which must then play the sound as fast as it can |
| 2022-08-17 18:30:44 +0200 | <riverside> | and if there is some delay this can be tracked somehow and compensated for |
| 2022-08-17 18:31:11 +0200 | <riverside> | eg if having to call an actual fully fledged sound exe which might be quite large |
| 2022-08-17 18:31:29 +0200 | <riverside> | but at least isolates the program we want, which is any haskell program that can play a sound file |
| 2022-08-17 18:31:43 +0200 | <riverside> | phrased like that kind of eliminates of this live stream patch sequence stuff |
| 2022-08-17 18:31:49 +0200 | <geekosaur> | you want tidal. or to interface with a midi emulator. |
| 2022-08-17 18:32:00 +0200 | <geekosaur> | something higher level than bit banging |
| 2022-08-17 18:33:12 +0200 | <albet70> | are ST Monad and State Monad different things? |
| 2022-08-17 18:33:29 +0200 | <jean-paul[m]> | yes |
| 2022-08-17 18:33:57 +0200 | <albet70> | what ST stands for? |
| 2022-08-17 18:33:58 +0200 | <geekosaur> | the names are somewhat unfortunate |
| 2022-08-17 18:34:02 +0200 | <geekosaur> | "state thread" |
| 2022-08-17 18:34:07 +0200 | <riverside> | i think you caould make STM concurrent using mailboxes for graph programs over threads as carried states |
| 2022-08-17 18:34:34 +0200 | <geekosaur> | basically, with normal pure code you neither know nor care what's evaluating it whne. a state thread is an imperative-like thread of control |
| 2022-08-17 18:34:45 +0200 | <geekosaur> | *when |
| 2022-08-17 18:35:14 +0200 | ccapndave | (~ccapndave@mob-194-230-146-204.cgn.sunrise.net) (Quit: Textual IRC Client: www.textualapp.com) |
| 2022-08-17 18:35:27 +0200 | <riverside> | you *want* access to the whole vector, data between programs, impossible. you get, the ability to do nearest neighbour message passing with a one step lag on a fully connected program graph corresponding to an unrestricted scope over the state vector |
| 2022-08-17 18:36:05 +0200 | <ski> | geekosaur : ah, a sample |
| 2022-08-17 18:36:13 +0200 | <geekosaur> | but distinct from CPU threads. it's sequenced like IO but you can do it in pure code as long as the result is pure, which the phantom "s" parameter ensures by "infecting" any impure data |
| 2022-08-17 18:36:19 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) (Ping timeout: 248 seconds) |
| 2022-08-17 18:36:26 +0200 | <albet70> | what that async/await model is? |
| 2022-08-17 18:37:17 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!) |
| 2022-08-17 18:37:26 +0200 | <geekosaur> | you fire off a bunch of threads to do computations and await their completion |
| 2022-08-17 18:37:42 +0200 | <geekosaur> | simpleminded parallelism |
| 2022-08-17 18:38:18 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 268 seconds) |
| 2022-08-17 18:38:22 +0200 | <qrpnxz> | if you are talking about haskell async lib, that's only potentially parallel |
| 2022-08-17 18:38:50 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-08-17 18:39:12 +0200 | <albet70> | a lots of languages now have async/await, it's easier to do some coroutine than the old threads |
| 2022-08-17 18:39:42 +0200 | <riverside> | erlang style |
| 2022-08-17 18:40:09 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 268 seconds) |
| 2022-08-17 18:40:15 +0200 | <riverside> | no this is buffered mailboxes, can use ports too |
| 2022-08-17 18:40:18 +0200 | <albet70> | python 3.4, ES7, kotlin coroutine etc... but old java still using threads |
| 2022-08-17 18:40:32 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-08-17 18:40:35 +0200 | <riverside> | idk how you access between threads |
| 2022-08-17 18:40:41 +0200 | <zzz> | is there any automatic parallellism in haskel? |
| 2022-08-17 18:40:57 +0200 | <davean> | zzz: define automatic parallellism |
| 2022-08-17 18:41:05 +0200 | <riverside> | compilation is very good? |
| 2022-08-17 18:41:06 +0200 | <davean> | the answer is both yes and no basicly |
| 2022-08-17 18:41:09 +0200 | <zzz> | like mapping over a list for example |
| 2022-08-17 18:41:18 +0200 | <geekosaur> | zzz, the closest you get is Control.Parallel.Strategies, I think |
| 2022-08-17 18:41:26 +0200 | <qrpnxz> | hypothetically yes, but i think you need `par` and stuff which is :/ |
| 2022-08-17 18:41:36 +0200 | <davean> | geekosaur: nah, some datatypes are processed inherently parallel |
| 2022-08-17 18:41:44 +0200 | <davean> | like some of the array libraries |
| 2022-08-17 18:41:53 +0200 | <davean> | (well, tensor? They're more than arrays) |
| 2022-08-17 18:41:54 +0200 | <riverside> | where as this way just uses *do this all exactly at the same time* for mailbox reads |
| 2022-08-17 18:42:02 +0200 | <zzz> | davean: that's what i'm looking for. can you tell me more about it? |
| 2022-08-17 18:42:22 +0200 | <riverside> | writeFile,readFile |
| 2022-08-17 18:42:42 +0200 | <riverside> | its not *that* slow, right? |
| 2022-08-17 18:42:48 +0200 | <qrpnxz> | first-class coroutines in haskell would be pretty cool |
| 2022-08-17 18:43:01 +0200 | <qrpnxz> | built-in, lua style |
| 2022-08-17 18:43:05 +0200 | <riverside> | easer not to look for anyway |
| 2022-08-17 18:43:06 +0200 | benin0 | (~benin@183.82.31.103) (Quit: The Lounge - https://thelounge.chat) |
| 2022-08-17 18:43:08 +0200 | <davean> | zzz: theres thigns like https://hackage.haskell.org/package/massiv but like I don't use any of the less explicite stuff, because why would I? Its easy to be explicite and get way more. |
| 2022-08-17 18:43:24 +0200 | <riverside> | well ports for between machines |
| 2022-08-17 18:43:24 +0200 | <zzz> | is there a reason why mapping over a list for example, with pure functions and immutability, can't be automatically parallellized? |
| 2022-08-17 18:43:42 +0200 | <riverside> | but again, just need cross machine file read and write which like ssh can do so |
| 2022-08-17 18:44:01 +0200 | <davean> | zzz: Well what there is is a problem if you do |
| 2022-08-17 18:44:05 +0200 | <davean> | zzz: because that changes performance |
| 2022-08-17 18:44:10 +0200 | kenran | (~kenran@200116b82b7885000a30634e15848455.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-08-17 18:44:17 +0200 | <riverside> | mapping should be parallel |
| 2022-08-17 18:44:17 +0200 | <davean> | what you can do is explicitely change out a map for a mapConcurrent |
| 2022-08-17 18:44:25 +0200 | <riverside> | always |
| 2022-08-17 18:44:29 +0200 | <davean> | because you should tell the compiler what you want |
| 2022-08-17 18:44:33 +0200 | <riverside> | its scanning thats consecutive |
| 2022-08-17 18:44:39 +0200 | <davean> | riverside: really it shouldn't, parallelism can ruin CPU performance |
| 2022-08-17 18:44:47 +0200 | <zzz> | davean: lol no. this is haskell :p |
| 2022-08-17 18:44:55 +0200 | <davean> | zzz: hum? |
| 2022-08-17 18:45:08 +0200 | <riverside> | the values can all be computed on seperate forked threads |
| 2022-08-17 18:45:17 +0200 | <geekosaur> | zzz, somewhat infamously it's difficult to determine when the overhead of spawning threads is higher than the benefit from parallelization. not to mention that sometimes you want things to remain lazy |
| 2022-08-17 18:45:25 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 18:45:31 +0200 | <geekosaur> | instead of being forced by parallelization |
| 2022-08-17 18:45:34 +0200 | <qrpnxz> | haskell or not, threads are overhead. You certainly would not want to do parallel for just a hundred elements for example |
| 2022-08-17 18:45:45 +0200 | <qrpnxz> | and with lists you can't know how many it will be |
| 2022-08-17 18:45:57 +0200 | <riverside> | actors does it all for a graph which is all |
| 2022-08-17 18:45:57 +0200 | <zzz> | ok |
| 2022-08-17 18:45:59 +0200 | <qrpnxz> | (unless you re traverse, which is pretty bad way to start) |
| 2022-08-17 18:46:10 +0200 | <davean> | riverside: they CAN but that isn't usually good |
| 2022-08-17 18:46:12 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-08-17 18:46:14 +0200 | <riverside> | mailboxes, nearest neighbour message passing on a fully connected graph |
| 2022-08-17 18:46:23 +0200 | <riverside> | even works between programs and machines |
| 2022-08-17 18:46:34 +0200 | <riverside> | uses read and write file, super simple |
| 2022-08-17 18:46:39 +0200 | <zzz> | i'm having some trouble parsing some of your sentences |
| 2022-08-17 18:46:40 +0200 | <davean> | riverside: And actors have HORRID performance. |
| 2022-08-17 18:46:45 +0200 | <riverside> | nope |
| 2022-08-17 18:46:48 +0200 | <davean> | Like truly attrocious |
| 2022-08-17 18:46:49 +0200 | <riverside> | we do transpose |
| 2022-08-17 18:46:49 +0200 | <geekosaur> | yep |
| 2022-08-17 18:46:51 +0200 | <davean> | No, seriously |
| 2022-08-17 18:47:02 +0200 | <davean> | like several orders of magnitude slower than the compute should be |
| 2022-08-17 18:47:02 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) |
| 2022-08-17 18:47:04 +0200 | <riverside> | its just the fully available state carry |
| 2022-08-17 18:47:11 +0200 | <davean> | thousands of times or tens of thousands of times |
| 2022-08-17 18:47:11 +0200 | <qrpnxz> | ofc they do. You just said the word "file", automatically this is super overhead that may or may not be worth it sometimes |
| 2022-08-17 18:47:29 +0200 | <riverside> | and weer using buffers anyway, so are now opperating on per-time column datat |
| 2022-08-17 18:47:35 +0200 | <davean> | riverside: you're just wrong and I don't know why we'd have this discussion anymore. |
| 2022-08-17 18:48:01 +0200 | <riverside> | right, but thats the boundry positioning problem |
| 2022-08-17 18:48:13 +0200 | <riverside> | keep as much in one program as possible, and one thread aswell then i guess |
| 2022-08-17 18:49:00 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-08-17 18:49:01 +0200 | <riverside> | so this is when you dont have to use mailboxes internally inside a running program |
| 2022-08-17 18:49:12 +0200 | geekosaur | sincerely doubts riverside has any clue what they're talking about |
| 2022-08-17 18:49:15 +0200 | <davean> | One has to very carefully pick their parallelism to get proper benefit from it. |
| 2022-08-17 18:49:24 +0200 | <davean> | geekosaur: oh its deeply clear they have no fucking clue at all |
| 2022-08-17 18:49:35 +0200 | <riverside> | we partition the state between programs, and seek to share memory live |
| 2022-08-17 18:49:38 +0200 | <davean> | Which is why I was wondering why we were even havign the conversation |
| 2022-08-17 18:49:45 +0200 | ChanServ | +o geekosaur |
| 2022-08-17 18:49:50 +0200 | <riverside> | as facilitated by simple mailboxes |
| 2022-08-17 18:49:57 +0200 | <zzz> | ok great it's not just me |
| 2022-08-17 18:50:14 +0200 | geekosaur | +q *!~riverside@213.205.241.143 |
| 2022-08-17 18:50:18 +0200 | <davean> | They seem to think a mailbox interaction somehow isn't larger than most calculations |
| 2022-08-17 18:50:28 +0200 | <geekosaur> | when it's much larger, yeh |
| 2022-08-17 18:50:30 +0200 | <davean> | which means they know nothing about how syncronization works in CPUs |
| 2022-08-17 18:50:41 +0200 | <davean> | Because of like bus locks |
| 2022-08-17 18:50:47 +0200 | <davean> | JUST A BUS LOCK ALONE!!! |
| 2022-08-17 18:51:04 +0200 | <davean> | You have any idea how many thousands of instructions a bus lock usually turns out to be? |
| 2022-08-17 18:51:30 +0200 | <davean> | (ok, often its only hundreds) |
| 2022-08-17 18:51:32 +0200 | <qrpnxz> | i think they were talking about making STM concurrent or something, but they were just going on and on? |
| 2022-08-17 18:51:37 +0200 | Colere | (~colere@about/linux/staff/sauvin) (Ping timeout: 252 seconds) |
| 2022-08-17 18:51:57 +0200 | <davean> | qrpnxz: I mean STM doesn't remove the atomic operations |
| 2022-08-17 18:52:08 +0200 | <geekosaur> | they were doing that before I got up this morning, I found wall-of-nonsense-text in my scrollback |
| 2022-08-17 18:52:14 +0200 | <qrpnxz> | lol |
| 2022-08-17 18:52:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 18:52:29 +0200 | <davean> | and atomic operations on a CPU require a memory controller lock to control said memory (or with HLE at least a cache lock and roll back) |
| 2022-08-17 18:52:31 +0200 | nattiestnate | (~nate@180.243.14.130) (Quit: WeeChat 3.6) |
| 2022-08-17 18:52:40 +0200 | <[exa]> | davean: it's hundreds on all CPUs right? |
| 2022-08-17 18:52:51 +0200 | lottaquestions | (~nick@104.221.24.83) (Quit: Konversation terminated!) |
| 2022-08-17 18:52:57 +0200 | <qrpnxz> | oh yeah just scrolled back |
| 2022-08-17 18:53:02 +0200 | <davean> | [exa]: Uh, no, sorta but yes in reality? There are WEIRD CPUs where counting instructions is strange like ThreadStorm |
| 2022-08-17 18:53:19 +0200 | <davean> | [exa]: and like on ThreadStorm its a bit ... weird |
| 2022-08-17 18:53:41 +0200 | <davean> | or some CPUs are slow enough they're in sync with RAM or only access L3 like RAM (Cell processors come to mind but not really) |
| 2022-08-17 18:53:50 +0200 | <davean> | [exa]: but any CPU you're thinking of? Yah |
| 2022-08-17 18:54:09 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2022-08-17 18:54:15 +0200 | geekosaur | -o geekosaur |
| 2022-08-17 18:54:20 +0200 | <davean> | Any CPU Haskell is relivent on? Yah |
| 2022-08-17 18:54:27 +0200 | <[exa]> | nah I really just asked, didn't know how brutal these are |
| 2022-08-17 18:55:03 +0200 | <davean> | [exa]: So there are a few options and a FEW things that can optimize, but MOSTLY you're takign exclusive control of a memory controller for the period to prevent conflicts |
| 2022-08-17 18:55:30 +0200 | <davean> | That that OFTEN lasts until the full read/write cycle of actual RAM has completed |
| 2022-08-17 18:55:46 +0200 | <davean> | Like theres a pile of caviates, CPUs are complicated |
| 2022-08-17 18:55:50 +0200 | ChanServ | +o litharge |
| 2022-08-17 18:55:51 +0200 | litharge | -qo *!~riverside@213.205.241.143 litharge |
| 2022-08-17 18:56:07 +0200 | <geekosaur> | (I set a short timeout) |
| 2022-08-17 18:56:17 +0200 | <geekosaur> | will increase it if needed |
| 2022-08-17 18:56:51 +0200 | econo | (uid147250@user/econo) |
| 2022-08-17 18:57:09 +0200 | <davean> | Anyway, the moral of the story is you really only want large blocks of parallelism which generally means making an inteligent choice about waht to parallelize |
| 2022-08-17 18:57:33 +0200 | <davean> | because the cordination will kill you and amsdal(sp)'s law will come for you in the night. |
| 2022-08-17 18:58:09 +0200 | Colere | (~colere@about/linux/staff/sauvin) |
| 2022-08-17 18:58:12 +0200 | <qrpnxz> | amdahl? |
| 2022-08-17 18:58:18 +0200 | <geekosaur> | was my guess |
| 2022-08-17 18:58:26 +0200 | <qrpnxz> | 👍 |
| 2022-08-17 18:58:34 +0200 | <davean> | qrpnxz: that sounds right |
| 2022-08-17 18:59:01 +0200 | <[exa]> | we should make some kind of a nicely named rule of thumb for this task granularity thing, so that it can get popular on hackernews etc and doesn't need to get explained all over again |
| 2022-08-17 18:59:32 +0200 | <davean> | [exa]: haha, is this not common knowlege? |
| 2022-08-17 18:59:45 +0200 | <davean> | I figured I was boring everyone to tears with programming 101 talk |
| 2022-08-17 18:59:48 +0200 | <[exa]> | it is, among people who got hurt by synchronization overhead already |
| 2022-08-17 19:00:18 +0200 | Furor | (~colere@about/linux/staff/sauvin) |
| 2022-08-17 19:00:41 +0200 | <[exa]> | young people are sometimes just like "let's send this addition to thread #5 because that is specialized to additions and we save one if()" |
| 2022-08-17 19:00:56 +0200 | <[exa]> | ^mild exaggeration |
| 2022-08-17 19:01:10 +0200 | <davean> | Just make it a conditional add |
| 2022-08-17 19:01:51 +0200 | <davean> | enable/disable bits are fun |
| 2022-08-17 19:02:11 +0200 | davean | looks around |
| 2022-08-17 19:02:23 +0200 | <davean> | You don't all plan out the assembly when you right Haskell? What? Just me? |
| 2022-08-17 19:03:11 +0200 | Colere | (~colere@about/linux/staff/sauvin) (Ping timeout: 256 seconds) |
| 2022-08-17 19:03:11 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-08-17 19:04:31 +0200 | <davean> | Which can I mention 9.4? :) |
| 2022-08-17 19:04:49 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 252 seconds) |
| 2022-08-17 19:04:49 +0200 | zitkat | (~zitkat@router-kraduha2-nat-c.pilsfree.net) (Quit: Leaving) |
| 2022-08-17 19:06:10 +0200 | <geekosaur[m]> | The stuff I usually write, I don't care |
| 2022-08-17 19:06:56 +0200 | <geekosaur[m]> | The computer is faster than me, that's good enough 😀 |
| 2022-08-17 19:08:58 +0200 | lottaquestions | (~nick@2607:fa49:503e:7100:17b4:8a9c:cee3:3359) |
| 2022-08-17 19:11:50 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 19:12:28 +0200 | janus | (janus@anubis.0x90.dk) () |
| 2022-08-17 19:14:55 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 19:15:02 +0200 | davean | looks over at htop, sees it reading 700d4h |
| 2022-08-17 19:15:08 +0200 | davean | quietly hides htop |
| 2022-08-17 19:15:47 +0200 | k8yun | (~k8yun@user/k8yun) |
| 2022-08-17 19:15:49 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 252 seconds) |
| 2022-08-17 19:16:05 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 19:17:57 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-08-17 19:17:59 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 19:19:51 +0200 | <davean> | When my CPU time is messured in years, I do infact care about factors of 1000x |
| 2022-08-17 19:20:46 +0200 | <davean> | I don't plan on dieing young, but I certainly care about a few thousand years of my life |
| 2022-08-17 19:21:41 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2022-08-17 19:25:22 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) |
| 2022-08-17 19:26:16 +0200 | <dolio> | Yes, the 'experts' on hackernews would never need to be told 101 level stuff. :þ |
| 2022-08-17 19:28:10 +0200 | <davean> | dolio: Of course, never |
| 2022-08-17 19:29:03 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-08-17 19:29:29 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-17 19:29:46 +0200 | kannon | (~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds) |
| 2022-08-17 19:30:23 +0200 | mbuf | (~Shakthi@122.165.55.71) (Quit: Leaving) |
| 2022-08-17 19:35:31 +0200 | vysn | (~vysn@user/vysn) (Ping timeout: 248 seconds) |
| 2022-08-17 19:36:01 +0200 | riverside | (~riverside@213.205.241.143) (Remote host closed the connection) |
| 2022-08-17 19:36:19 +0200 | riverside | (~riverside@213.205.241.143) |
| 2022-08-17 19:40:28 +0200 | <qrpnxz> | geekosaur[m]: even when the computer is slower than a person it can be worth it if it's more correct and/or cheaper |
| 2022-08-17 19:41:00 +0200 | <geekosaur> | the computer can also keep track of more things than I can, yes, so that's still a win |
| 2022-08-17 19:41:25 +0200 | <geekosaur> | but I used to runghc most of my stuff and only compile now because I cabalized everything to teach myself cabal v2 workflow |
| 2022-08-17 19:42:33 +0200 | <qrpnxz> | i was doing ghc manually, then i moved to a ninja script, but i wanted more automation for building that, and a few layers of abstraction in i concluded, "wait someone already solved this problem it's called cabal" lol |
| 2022-08-17 19:42:58 +0200 | <qrpnxz> | but i didn't really appreciate cabal until i started half reimplementing it |
| 2022-08-17 19:43:23 +0200 | <qrpnxz> | and stack is a few levels even above that |
| 2022-08-17 19:44:15 +0200 | <qrpnxz> | i guess is something different than what you were talking about, but i was just reminded of this |
| 2022-08-17 19:45:01 +0200 | <qrpnxz> | iirc, stack has some nice scripting helpers? |
| 2022-08-17 19:46:20 +0200 | <geekosaur> | cabal has mostly caught up with it, I think the only real difference as of 3.8 is the resolver |
| 2022-08-17 19:46:35 +0200 | <geekosaur> | in particular, cabal caches the result of building the script now |
| 2022-08-17 19:55:03 +0200 | MajorBiscuit | (~MajorBisc@c-001-030-027.client.tudelft.eduvpn.nl) (Ping timeout: 252 seconds) |
| 2022-08-17 19:56:30 +0200 | Inoperable | (~PLAYER_1@fancydata.science) (Excess Flood) |
| 2022-08-17 20:01:49 +0200 | Inoperable | (~PLAYER_1@fancydata.science) |
| 2022-08-17 20:06:33 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 20:08:54 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a0595bd943540671dc0.dip0.t-ipconnect.de) (Ping timeout: 256 seconds) |
| 2022-08-17 20:09:02 +0200 | gmg | (~user@user/gehmehgeh) |
| 2022-08-17 20:11:11 +0200 | hippoid | (~idris@c-98-220-13-8.hsd1.il.comcast.net) (Ping timeout: 252 seconds) |
| 2022-08-17 20:13:24 +0200 | <monochrom> | I have some ideas what kind of asm code I'm getting from GHC. |
| 2022-08-17 20:13:38 +0200 | <monochrom> | And I mostly just make peace with it. :) |
| 2022-08-17 20:15:04 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-08-17 20:15:43 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-08-17 20:17:49 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-08-17 20:18:17 +0200 | vulpine | (xfnw@tilde.team) (Quit: Connection reset by purr) |
| 2022-08-17 20:21:20 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) |
| 2022-08-17 20:23:20 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 20:28:20 +0200 | <geekosaur> | same |
| 2022-08-17 20:28:59 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 20:29:25 +0200 | <geekosaur> | I have poked a bit at what comes out of the compiler, I just don't care most of the time. I'm the slow/high overhead part of the chain, not the program, so it's irrelevant |
| 2022-08-17 20:31:18 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 20:31:43 +0200 | hippoid | (~idris@c-98-220-13-8.hsd1.il.comcast.net) |
| 2022-08-17 20:34:19 +0200 | vglfr | (~vglfr@145.224.94.221) (Remote host closed the connection) |
| 2022-08-17 20:34:59 +0200 | vglfr | (~vglfr@145.224.94.221) |
| 2022-08-17 20:36:20 +0200 | kuribas | (~user@ptr-17d51em3ydspl0uuwo7.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-08-17 20:36:37 +0200 | biberu | (~biberu@user/biberu) |
| 2022-08-17 20:39:00 +0200 | Inst | (~Inst@2601:6c4:4080:3f80:38a1:ad8c:aa85:4bd8) (Ping timeout: 244 seconds) |
| 2022-08-17 20:39:29 +0200 | Inst | (~Inst@2601:6c4:4080:3f80:e0a9:7049:576:28ef) |
| 2022-08-17 20:41:17 +0200 | mimmy | (~mimmy@66-46-12-74.dedicated.allstream.net) |
| 2022-08-17 20:41:47 +0200 | codaraxis | (~codaraxis@user/codaraxis) |
| 2022-08-17 20:45:15 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 20:45:21 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-08-17 20:46:44 +0200 | ubert | (~Thunderbi@178.165.179.220.wireless.dyn.drei.com) |
| 2022-08-17 20:47:38 +0200 | vglfr | (~vglfr@145.224.94.221) (Remote host closed the connection) |
| 2022-08-17 20:48:19 +0200 | vglfr | (~vglfr@145.224.94.221) |
| 2022-08-17 20:49:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2022-08-17 20:54:46 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:216d:db30:5bf:3c9c) |
| 2022-08-17 20:57:21 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 20:59:22 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 21:00:37 +0200 | <monochrom> | After teaching a C-and-Unix course several times, I reckon that there are so many syscalls to make, and on top of that half of them copy humongous data between user space and kernel space, and last but not least you're calling strlen() on the same string over and over again, that the myth of "C code more efficient" is completely bust. |
| 2022-08-17 21:01:50 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Ping timeout: 255 seconds) |
| 2022-08-17 21:02:13 +0200 | <monochrom> | At that rate Haskell is no more guilty than real-world C code. |
| 2022-08-17 21:02:23 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 21:03:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 21:04:03 +0200 | ubert | (~Thunderbi@178.165.179.220.wireless.dyn.drei.com) (Ping timeout: 248 seconds) |
| 2022-08-17 21:04:03 +0200 | <geekosaur> | " x code is more efficient" iff you put the right amount of effort into it, for any x |
| 2022-08-17 21:04:46 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Quit: Leaving) |
| 2022-08-17 21:05:10 +0200 | <monochrom> | Oh and I'm still teaching select() for portability haha. |
| 2022-08-17 21:05:36 +0200 | ski | (~ski@ext-1-308.eduroam.chalmers.se) (Ping timeout: 268 seconds) |
| 2022-08-17 21:06:33 +0200 | <tomsmeding> | monochrom: not sure that point about copying data back and forth between user and kernel space makes sense; clearly that's what's happening, but haskell is not going to avoid the same syscalls |
| 2022-08-17 21:06:42 +0200 | <tomsmeding> | *not going to be able to avoid |
| 2022-08-17 21:06:53 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-12.elisa-laajakaista.fi) |
| 2022-08-17 21:07:13 +0200 | <geekosaur> | that's kinda the point, I think: neither one can be more efficient with that overhead |
| 2022-08-17 21:07:29 +0200 | <geekosaur> | *than the other |
| 2022-08-17 21:07:59 +0200 | quarkyalice | (~quarkyali@user/quarkyalice) |
| 2022-08-17 21:08:18 +0200 | <tomsmeding> | there is a difference in speed _ceiling_, I guess; for many imperative algorithms, the maximum speed you can get out of C will probably be more than the maximum speed you can get out of Haskell without using custom FFI bindings |
| 2022-08-17 21:08:25 +0200 | nate4 | (~nate@98.45.169.16) |
| 2022-08-17 21:08:34 +0200 | <tomsmeding> | (though the difference need not be large) |
| 2022-08-17 21:08:59 +0200 | <tomsmeding> | but monochrom's point is valid that practical business C code vs practical business Haskell code has little to do with that speed ceiling :p |
| 2022-08-17 21:09:42 +0200 | <tomsmeding> | also, the speed ceiling of Fortran may even be higher than that of C for certain array-heavy workloads where C's memory model messes with you |
| 2022-08-17 21:10:14 +0200 | quarkyalice | (~quarkyali@user/quarkyalice) (Client Quit) |
| 2022-08-17 21:12:51 +0200 | <geekosaur> | right. but we also have examples where haskell's speed ceiling can be higher for some workloads |
| 2022-08-17 21:13:25 +0200 | king_gs | (~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec) |
| 2022-08-17 21:13:32 +0200 | <geekosaur> | that said, neither is the general case |
| 2022-08-17 21:13:37 +0200 | <tomsmeding> | hence my addition "for many imperative algorithms" -- but yes, good point |
| 2022-08-17 21:13:38 +0200 | nate4 | (~nate@98.45.169.16) (Ping timeout: 268 seconds) |
| 2022-08-17 21:14:01 +0200 | <tomsmeding> | you're not going to do a max-flow algorithm faster in haskell than in C :p |
| 2022-08-17 21:14:52 +0200 | robbert-vdh | (~robbert@robbertvanderhelm.nl) |
| 2022-08-17 21:15:04 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 21:15:08 +0200 | <geekosaur> | in general I'd expect well written C code to beat well written Haskell code. (then the question becomes, is it actually well written? Especially for C) |
| 2022-08-17 21:15:31 +0200 | <geekosaur> | given the number of programmers who think they produce well written C code |
| 2022-08-17 21:15:33 +0200 | <int-e> | For some time, one of the weirdest Haskell-is-faster-than-C niches was big integer arithmetic... I wonder whether that's still the case. Basically, many operations allocate temporaries, and `malloc` was slower than Haskell's heap management... |
| 2022-08-17 21:15:35 +0200 | <tomsmeding> | yeah "well-written" is what one quickly reaches for when talking about this stuff, but it's really an ill-defined notion |
| 2022-08-17 21:16:12 +0200 | <tomsmeding> | int-e: does haskell's GMP use the haskell heap allocator? |
| 2022-08-17 21:16:16 +0200 | <geekosaur> | yes |
| 2022-08-17 21:16:22 +0200 | <tomsmeding> | heh that's an interesting case |
| 2022-08-17 21:16:24 +0200 | <int-e> | (This was ages ago, when ghc hacked GMP's malloc functions.) |
| 2022-08-17 21:16:40 +0200 | <tomsmeding> | doesn't GMP allow overriding malloc and friends? |
| 2022-08-17 21:16:40 +0200 | <geekosaur> | with the result that you can't mix haskell gmp with C gmp because you can't specify the allocator on a per function basis |
| 2022-08-17 21:16:51 +0200 | <int-e> | The story now is that it uses the mpn_ interface. |
| 2022-08-17 21:17:05 +0200 | <int-e> | geekosaur: You can, now. |
| 2022-08-17 21:17:07 +0200 | <geekosaur> | ah |
| 2022-08-17 21:17:27 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 21:17:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 21:17:52 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Quit: ec) |
| 2022-08-17 21:18:16 +0200 | <tomsmeding> | > Fast low-level functions that operate on natural numbers. These are used by the functions in the preceding groups, and you can also call them directly from very time-critical user programs. These functions’ names begin with mpn_. The associated type is array of mp_ limb_t. There are about 60 (hard-to-use) functions in this class. |
| 2022-08-17 21:18:18 +0200 | <tomsmeding> | sounds good! :D |
| 2022-08-17 21:18:26 +0200 | <tomsmeding> | (it's been a while I last worked with GMP) |
| 2022-08-17 21:19:05 +0200 | <int-e> | Since GHC 8.0? I forgot, it may have been 7.10. |
| 2022-08-17 21:19:11 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 21:19:20 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-08-17 21:19:38 +0200 | acidjnk_new | (~acidjnk@p200300d6e7137a5774e66b102b0a005a.dip0.t-ipconnect.de) |
| 2022-08-17 21:20:11 +0200 | <Henson> | ok, I figured out the OpenMP problem. Apparently running OpenMP from within Haskell causes the various OMP_* environment variables to be ignored. Dynamic thread teams is enabled by default. When my computer has had a bit of a break, OpenMP seems to think that using 2 threads is fine and will use them. Then if I load it up or rebuild the software then it will think 1 thread is better.... |
| 2022-08-17 21:20:39 +0200 | <tomsmeding> | Henson: the deciding factor is system load? O.o |
| 2022-08-17 21:20:45 +0200 | <Henson> | By explicitly disabling dynamic thread teams in the C++ code using omp_set_dynamic(0) and then controlling the desired number of threads with omp_set_num_threads(2) I'm able to get it to work everytime |
| 2022-08-17 21:20:48 +0200 | <tomsmeding> | I would _not_ have guessed that |
| 2022-08-17 21:20:57 +0200 | <tomsmeding> | heh |
| 2022-08-17 21:21:04 +0200 | <tomsmeding> | good sleuthing |
| 2022-08-17 21:21:40 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 21:21:43 +0200 | <Henson> | tomsmeding: it would appear to be. I ran the executable and OpenMP worked fine. Then I copied the executable, rebuilt the software, and ran the benchmark again. Then OpenMP didn't work. I compared the was-working and now-not-working binaries, and they're exactly the same. The only difference was that my computer was busy rebuilding the software and had a higher load. |
| 2022-08-17 21:21:57 +0200 | <Henson> | I also would not have guessed that! |
| 2022-08-17 21:22:54 +0200 | zeenk | (~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) |
| 2022-08-17 21:23:02 +0200 | <Henson> | this still leaves the unusual question of: why does OpenMP make a different choice when the function is called using async", but I think I'll just leave that one a mystery. |
| 2022-08-17 21:23:23 +0200 | <Henson> | as I imagine it will take even more time-consuming sleuthing and will not benefit me in the end |
| 2022-08-17 21:23:25 +0200 | <int-e> | geekosaur: aha: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html "The integer-gmp package has been completely rewritten from the ground up. The primary change in this rewrite is that GHC-compiled programs that link to GMP no longer 'hook' GMP allocation routines [...]" |
| 2022-08-17 21:23:33 +0200 | <tomsmeding> | 1. if I ever do work with openMP, I hope I'll remember to omp_set_dynamic(0) -- dynamic thread scaling based on current load sounds quite harmful |
| 2022-08-17 21:24:02 +0200 | <tomsmeding> | 2. Henson: regarding those environment variables, that also sounds fishy; the variables are set in the environment of the Haskell program, but they've disappeared in the C++ code? |
| 2022-08-17 21:24:45 +0200 | <Henson> | tomsmeding: yeah. The software's built with Nix, so I don't know if there's some fishiness going on there |
| 2022-08-17 21:25:17 +0200 | <tomsmeding> | it's not the building that matters for env vars, it's the running |
| 2022-08-17 21:25:19 +0200 | <Henson> | unless I'm not setting the variables correctly. I assume that "export OMP_FOO=BAR" will do the trick |
| 2022-08-17 21:25:25 +0200 | <tomsmeding> | it _should_ |
| 2022-08-17 21:25:57 +0200 | <Henson> | tomsmeding: yeah but Nix somtimes wraps things up and has nested environments, which I don't think is happening in this case. |
| 2022-08-17 21:26:32 +0200 | <tomsmeding> | Henson: you can check the environment of a process by reading /proc/$PID/environ |
| 2022-08-17 21:26:32 +0200 | hippoid | (~idris@c-98-220-13-8.hsd1.il.comcast.net) (Ping timeout: 256 seconds) |
| 2022-08-17 21:26:39 +0200 | <tomsmeding> | "nested environments" is not a thing in unix :p |
| 2022-08-17 21:27:15 +0200 | <tomsmeding> | (in that file, the key-value pairs are separated with null bytes) |
| 2022-08-17 21:27:28 +0200 | <Henson> | tomsmeding: maybe "layered" environments |
| 2022-08-17 21:27:29 +0200 | <tomsmeding> | s/separated/delimited/ |
| 2022-08-17 21:27:51 +0200 | <Henson> | tomsmeding: I'll have to investigate your suggestion a bit later, got to make a call |
| 2022-08-17 21:28:04 +0200 | <tomsmeding> | still, that's not a thing in unix; if nix claims to do something like that, it will have to add and remove things from the actual environment at boundaries of the "layers" |
| 2022-08-17 21:28:07 +0200 | <tomsmeding> | sure :) |
| 2022-08-17 21:28:24 +0200 | <tomsmeding> | fool-proof way of setting something in the environment of a process is: $ env VAR=value ./binary |
| 2022-08-17 21:29:27 +0200 | <geekosaur[m]> | Layered isn't a thing either. Nix nuking environments, sadly, is |
| 2022-08-17 21:30:24 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-08-17 21:31:10 +0200 | monochrom | (trebla@216.138.220.146) (Quit: NO CARRIER) |
| 2022-08-17 21:32:13 +0200 | monochrom | (~trebla@216.138.220.146) |
| 2022-08-17 21:33:23 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds) |
| 2022-08-17 21:34:30 +0200 | riverside | (~riverside@213.205.241.143) (Remote host closed the connection) |
| 2022-08-17 21:34:48 +0200 | riverside | (~riverside@213.205.241.143) |
| 2022-08-17 21:43:35 +0200 | mimmy | (~mimmy@66-46-12-74.dedicated.allstream.net) (Ping timeout: 252 seconds) |
| 2022-08-17 21:44:31 +0200 | mimmy | (~mimmy@66-46-12-74.dedicated.allstream.net) |
| 2022-08-17 21:44:32 +0200 | mimmy | (~mimmy@66-46-12-74.dedicated.allstream.net) (Client Quit) |
| 2022-08-17 21:55:49 +0200 | chomwitt | (~chomwitt@2a02:587:dc16:4100:1289:3f0b:2a03:948d) |
| 2022-08-17 22:03:42 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) (Ping timeout: 264 seconds) |
| 2022-08-17 22:04:33 +0200 | erisco | (~erisco@d24-57-249-233.home.cgocable.net) |
| 2022-08-17 22:09:56 +0200 | mmhat | (~mmh@p200300f1c712fb1cee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 244 seconds) |
| 2022-08-17 22:10:33 +0200 | <tomsmeding> | oh my, I've been bitten by Foldable (a,) |
| 2022-08-17 22:10:54 +0200 | <tomsmeding> | this may well have been the first time |
| 2022-08-17 22:12:16 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2022-08-17 22:19:36 +0200 | martin02 | (~silas@141.84.69.76) (Ping timeout: 268 seconds) |
| 2022-08-17 22:19:45 +0200 | king_gs | (~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec) (Ping timeout: 244 seconds) |
| 2022-08-17 22:22:13 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:216d:db30:5bf:3c9c) (Quit: WeeChat 2.8) |
| 2022-08-17 22:24:12 +0200 | mmhat | (~mmh@p200300f1c722777cee086bfffe095315.dip0.t-ipconnect.de) |
| 2022-08-17 22:25:29 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) |
| 2022-08-17 22:25:38 +0200 | yvan-sraka | (~yvan-srak@37.168.2.133) |
| 2022-08-17 22:27:22 +0200 | pavonia | (~user@user/siracusa) |
| 2022-08-17 22:27:37 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-08-17 22:28:57 +0200 | yvan-sraka | (~yvan-srak@37.168.2.133) (Remote host closed the connection) |
| 2022-08-17 22:29:47 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-08-17 22:31:44 +0200 | martin02 | (~silas@141.84.69.76) |
| 2022-08-17 22:31:52 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-08-17 22:33:24 +0200 | merijn | (~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-08-17 22:33:45 +0200 | <monochrom> | "Get well soon." >:) |
| 2022-08-17 22:35:21 +0200 | <tomsmeding> | monochrom: the problem with this particular malady is that you only realise it was this one when you've already recovered :p |
| 2022-08-17 22:35:58 +0200 | <Rembane_> | Sounds like depression |
| 2022-08-17 22:36:16 +0200 | <tomsmeding> | accurate, for Foldable (a,) |
| 2022-08-17 22:41:29 +0200 | cdsmith | (~cdsmithma@2001:470:69fc:105::284) |
| 2022-08-17 22:43:48 +0200 | drdo | (~drdo@roach0.drdo.eu) (Quit: The Lounge - https://thelounge.chat) |
| 2022-08-17 22:44:21 +0200 | drdo | (~drdo@roach0.drdo.eu) |
| 2022-08-17 22:46:50 +0200 | gio123 | (~gio123@94.137.173.75) |
| 2022-08-17 22:46:57 +0200 | <zzz> | length (0,0) |
| 2022-08-17 22:47:05 +0200 | <zzz> | > length (0,0) |
| 2022-08-17 22:47:07 +0200 | <lambdabot> | 1 |
| 2022-08-17 22:47:21 +0200 | <tomsmeding> | > length (undefined, undefined) |
| 2022-08-17 22:47:23 +0200 | <lambdabot> | 1 |
| 2022-08-17 22:47:29 +0200 | <zzz> | oh no |
| 2022-08-17 22:47:35 +0200 | <tomsmeding> | > toList ('a', 42) |
| 2022-08-17 22:47:36 +0200 | <lambdabot> | [42] |
| 2022-08-17 22:48:04 +0200 | <zzz> | i don't even agree with the Functor instance of (,) |
| 2022-08-17 22:48:05 +0200 | <tomsmeding> | it's the only valid instance, but you seldom need it, and it's quite a footgun |
| 2022-08-17 22:48:20 +0200 | <tomsmeding> | functor is at least much less of a footgun :p |
| 2022-08-17 22:49:08 +0200 | <zzz> | what bit you exaclty, if i may ask? |
| 2022-08-17 22:49:12 +0200 | sammelweis | (~quassel@2601:401:8200:2d4c:bd9:d04c:7f69:eb10) (Ping timeout: 244 seconds) |
| 2022-08-17 22:49:41 +0200 | <tomsmeding> | map snd . filter (\col -> length col < 6) $ zip bd [0..] |
| 2022-08-17 22:49:59 +0200 | <tomsmeding> | bd :: [[a]], a list of columns. I want the indices of the columns with height < 6 |
| 2022-08-17 22:50:25 +0200 | <tomsmeding> | given the discussion the mistake is obvious, but y'know |
| 2022-08-17 22:51:29 +0200 | <zzz> | heh i get it |
| 2022-08-17 22:51:35 +0200 | Guest93 | (~Guest93@2603-8000-0401-65cc-654b-133e-fd96-a390.res6.spectrum.com) |
| 2022-08-17 22:52:54 +0200 | <tomsmeding> | I found it after some debugging of a _super_ uninformative error, which I tracked down to a 'bd' value with a column of height 7 |
| 2022-08-17 22:53:01 +0200 | <tomsmeding> | which should have been impossible |
| 2022-08-17 22:53:04 +0200 | <tomsmeding> | then I was like, wait... |
| 2022-08-17 22:53:18 +0200 | gio123 | (~gio123@94.137.173.75) (Quit: Client closed) |
| 2022-08-17 22:55:04 +0200 | <monochrom> | Yeah, valid does not imply desirable. |
| 2022-08-17 22:55:30 +0200 | <tomsmeding> | I don't think anybody has ever been bitten in this way by Functor (a,) |
| 2022-08-17 22:55:33 +0200 | <monochrom> | Infinite types are valid too, equirecursive types and all that, see TaPL. But hated by all. :) |
| 2022-08-17 22:55:54 +0200 | <tomsmeding> | monochrom: because type inference completely breaks down, right? |
| 2022-08-17 22:55:57 +0200 | coot | (~coot@213.134.176.158) |
| 2022-08-17 22:56:05 +0200 | zer0bitz | (~zer0bitz@2001:2003:f748:2000:9186:336c:b8e1:3e66) (Ping timeout: 256 seconds) |
| 2022-08-17 22:56:17 +0200 | <monochrom> | I don't know. But it's clearly royally confusing. |
| 2022-08-17 22:56:25 +0200 | <tomsmeding> | :D |
| 2022-08-17 22:58:17 +0200 | <monochrom> | It might not break type inference. Prolog is happy with omitting occurs check, and type inference is easier than Prolog. |
| 2022-08-17 22:59:29 +0200 | <tomsmeding> | let's just keep it at "it's royally confusing" them |
| 2022-08-17 22:59:31 +0200 | <tomsmeding> | *then |
| 2022-08-17 22:59:54 +0200 | <monochrom> | But if you don't tell beginners "you can't if ... then x else [x]", it's going to be both technical debt and pedagogical debt snowballing down the road. |
| 2022-08-17 23:00:45 +0200 | <tomsmeding> | that in particular is a fairly useless infinite type :p |
| 2022-08-17 23:01:00 +0200 | k8yun_ | (~k8yun@user/k8yun) |
| 2022-08-17 23:01:43 +0200 | ccntrq | (~Thunderbi@172.209.94.92.rev.sfr.net) (Read error: Connection reset by peer) |
| 2022-08-17 23:01:45 +0200 | <tomsmeding> | newtype Tree a = Tree [Tree a] |
| 2022-08-17 23:01:51 +0200 | <tomsmeding> | that is to say, newtype Tree = Tree [Tree] |
| 2022-08-17 23:02:51 +0200 | <monochrom> | The useful infinite types can still be made yet clearer by having explicit wrapping and unwrapping, i.e., let's go back to isorecursive types after all. |
| 2022-08-17 23:03:27 +0200 | <tomsmeding> | yes |
| 2022-08-17 23:03:45 +0200 | <tomsmeding> | I feel like type classes are slightly _too_ implicit sometimes |
| 2022-08-17 23:03:58 +0200 | <monochrom> | Similarly Foldable (e,) can be made clearer by rolling your own tuple type. |
| 2022-08-17 23:04:11 +0200 | <tomsmeding> | like, sometimes one would like to explicitly control what Ord gets used for some kind of sort or Set; or sometimes you want Foldable (a,), but mostly not |
| 2022-08-17 23:04:35 +0200 | k8yun | (~k8yun@user/k8yun) (Ping timeout: 248 seconds) |
| 2022-08-17 23:04:41 +0200 | <tomsmeding> | but I don't have a better design, at the very least type classes seem a local optimum, and a good one at that |
| 2022-08-17 23:06:17 +0200 | <monochrom> | So somehow we look at "(x,y)" and think "hey that's a length-2 list in funny syntax", and we look at "data MyTuple a b = T a b" we think "this is clearly b with piggybacked a". |
| 2022-08-17 23:07:03 +0200 | <tomsmeding> | I don't even think that thinking (x,y) is a funny list is the issue with Foldable (a,) |
| 2022-08-17 23:07:18 +0200 | <tomsmeding> | see my mistake above |
| 2022-08-17 23:07:26 +0200 | <tomsmeding> | but yeah, names good |
| 2022-08-17 23:07:31 +0200 | coot | (~coot@213.134.176.158) (Quit: coot) |
| 2022-08-17 23:08:00 +0200 | <tomsmeding> | and haskell is nice in that it's easy to create new names -- except that _sometimes_ one would like Rust's Deref functionality |
| 2022-08-17 23:08:11 +0200 | <tomsmeding> | i.e. inherit a bunch of functionality from the contained type |
| 2022-08-17 23:08:22 +0200 | mikoto-chan | (~mikoto-ch@164.5.249.78) |
| 2022-08-17 23:09:07 +0200 | <monochrom> | ooohhh, that one is very close to why infinite types are a bad idea. |
| 2022-08-17 23:09:33 +0200 | <monochrom> | valid code that hides a mistake very well |
| 2022-08-17 23:10:00 +0200 | <tomsmeding> | it would be strictly opt-in when you create a new type (just like in Rust) |
| 2022-08-17 23:10:06 +0200 | <tomsmeding> | for certain types it makes sense, for most it doesn't |
| 2022-08-17 23:10:37 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 23:10:41 +0200 | <monochrom> | "then x else [x]" looks obvious, but that's just because I single it out. Imagine it hiding in 20 lines of code, you'll never spot it. |
| 2022-08-17 23:10:44 +0200 | <tomsmeding> | but maybe the extra newtype (un)wrapping is worth our sanity :p |
| 2022-08-17 23:10:51 +0200 | <tomsmeding> | yeah no recursive types bad |
| 2022-08-17 23:11:00 +0200 | <tomsmeding> | eh, infinite types |
| 2022-08-17 23:11:19 +0200 | <tomsmeding> | (got confused thinking about the usual notation with Rec) |
| 2022-08-17 23:13:12 +0200 | <zzz> | you can? |
| 2022-08-17 23:13:31 +0200 | <tomsmeding> | you can what? |
| 2022-08-17 23:16:20 +0200 | dsrt^ | (~dsrt@50.236.139.178) |
| 2022-08-17 23:19:52 +0200 | Milan | (~Milan@46.245.79.69) |
| 2022-08-17 23:20:01 +0200 | <zzz> | sorry i was scrolled back and didn't notice |
| 2022-08-17 23:20:34 +0200 | <zzz> | you can [have infinite types]? |
| 2022-08-17 23:21:05 +0200 | Milan | (~Milan@46.245.79.69) (Client Quit) |
| 2022-08-17 23:21:08 +0200 | <tomsmeding> | I'm not too sure about the details -- monochrom seems to be surer -- but I think that having infinite types in a type system is not necessarily nonsense |
| 2022-08-17 23:21:16 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-08-17 23:21:26 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |
| 2022-08-17 23:22:00 +0200 | <tomsmeding> | You can have types of the form `Rec a. Maybe (Int, a)`, which transparently unwraps to `Maybe (Int, Rec a. Maybe (Int, a))` |
| 2022-08-17 23:22:03 +0200 | Guest93 | (~Guest93@2603-8000-0401-65cc-654b-133e-fd96-a390.res6.spectrum.com) (Quit: Client closed) |
| 2022-08-17 23:22:09 +0200 | <tomsmeding> | and which transparently wraps again if needed |
| 2022-08-17 23:22:22 +0200 | <tomsmeding> | (this happens to be [Int]) |
| 2022-08-17 23:22:43 +0200 | <tomsmeding> | this `Rec` might also be called `Roll` sometimes IIRC |
| 2022-08-17 23:23:18 +0200 | <tomsmeding> | if you have explicit term formers `roll` and `unroll` which wrap and unwrap the Rec, clearly it should work -- you just have anonymous newtypes then |
| 2022-08-17 23:23:27 +0200 | <tomsmeding> | but even without, it might work |
| 2022-08-17 23:23:38 +0200 | <tomsmeding> | but, as monochrom said, it would be royally confusing |
| 2022-08-17 23:26:01 +0200 | <monochrom> | TaPL has infinite type examples. It says "equirecursive types". |
| 2022-08-17 23:26:12 +0200 | biberu | (~biberu@user/biberu) (Read error: Connection reset by peer) |
| 2022-08-17 23:26:25 +0200 | <monochrom> | Although, it does type inference in an unrelated chapter that doesn't have infinite types. |
| 2022-08-17 23:27:17 +0200 | <tomsmeding> | yeah on the one hand it feels like you should be able to exchange the occurs check with construction of a rolled type; on the other hand, it feels like you'll open a can of worms |
| 2022-08-17 23:28:12 +0200 | jmd_ | (~jmdaemon@user/jmdaemon) |
| 2022-08-17 23:28:57 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 256 seconds) |
| 2022-08-17 23:28:57 +0200 | <monochrom> | For now I'm just at the cheeky level of "just go into your unification algorithm and delete the occurs check, what can possibly go wrong?" :) |
| 2022-08-17 23:29:07 +0200 | <tomsmeding> | eh, a lot :p |
| 2022-08-17 23:29:33 +0200 | <monochrom> | "Hey you may even be able to support \x -> x x" |
| 2022-08-17 23:29:35 +0200 | <tomsmeding> | a compiler written in haskell might fare a bit better than one in a strict language |
| 2022-08-17 23:30:06 +0200 | <tomsmeding> | on account of not necessarily immediately reifying the infinite type as a whole -- though that depends heavily on the precise implementation of the type checker |
| 2022-08-17 23:30:23 +0200 | <tomsmeding> | I can imagine at least one type checker implementation that will infinite loop |
| 2022-08-17 23:30:31 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) (Quit: ZNC - http://znc.in) |
| 2022-08-17 23:31:34 +0200 | johnw | (~johnw@76-234-69-149.lightspeed.frokca.sbcglobal.net) |
| 2022-08-17 23:33:50 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2022-08-17 23:34:16 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-08-17 23:34:43 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2022-08-17 23:35:05 +0200 | MajorBiscuit | (~MajorBisc@46-229-126.internethome.cytanet.com.cy) |
| 2022-08-17 23:35:45 +0200 | jmd_ | (~jmdaemon@user/jmdaemon) (Ping timeout: 256 seconds) |
| 2022-08-17 23:37:40 +0200 | vulpine | (xfnw@tilde.team) |
| 2022-08-17 23:38:45 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-08-17 23:38:49 +0200 | <Henson> | tomsmeding: is looks like when the 15 minute load average (rightmost load average number in "top") goes above 0.9, that's when the number of CPUs chosen by OpenMP changes. Below 0.9 it'll use 2, at or above 0.9 it'll use 1. |
| 2022-08-17 23:40:40 +0200 | geekosaur | introduces Henson to `uptime` |
| 2022-08-17 23:40:47 +0200 | matthewmosior | (~matthewmo@173.170.253.91) (Remote host closed the connection) |
| 2022-08-17 23:41:56 +0200 | gdown | (~gavin@h69-11-149-231.kndrid.broadband.dynamic.tds.net) |
| 2022-08-17 23:43:30 +0200 | <Henson> | geekosaur: :-) |
| 2022-08-17 23:44:33 +0200 | <tomsmeding> | Henson: your machine has 2 cores? |
| 2022-08-17 23:44:54 +0200 | <Henson> | tomsmeding: OpenMP seems to ignore the OMP_DYNAMIC variable, unless "false" or "FALSE" or "0" are not valid values. But it does show up in the /proc/$PID/environ variable. It DOES obey the OMP_NUM_THREADS environment variable. |
| 2022-08-17 23:45:15 +0200 | <Henson> | tomsmeding: yes, it's an old Thinkpad T430 |
| 2022-08-17 23:45:19 +0200 | <Henson> | still goin' |
| 2022-08-17 23:45:52 +0200 | <tomsmeding> | Henson: seems 'false' should be valid https://www.openmp.org/spec-html/5.0/openmpse51.html#x290-20560006.3 |
| 2022-08-17 23:45:57 +0200 | dsrt^ | (~dsrt@50.236.139.178) (Ping timeout: 268 seconds) |
| 2022-08-17 23:46:42 +0200 | <tomsmeding> | Henson: if it still works, it still works :) -- I wasn't doubting your machine, was clarifying because I thought I recalled you speaking about 4 before |
| 2022-08-17 23:47:47 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2022-08-17 23:48:47 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 255 seconds) |
| 2022-08-17 23:48:52 +0200 | king_gs | (~Thunderbi@187.201.216.244) |
| 2022-08-17 23:49:10 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-08-17 23:52:21 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-08-17 23:54:11 +0200 | jao | (~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 248 seconds) |
| 2022-08-17 23:54:47 +0200 | jao | (jao@gateway/vpn/protonvpn/jao) |
| 2022-08-17 23:55:50 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-08-17 23:57:02 +0200 | jgeerds | (~jgeerds@55d46bad.access.ecotel.net) (Ping timeout: 268 seconds) |
| 2022-08-17 23:57:23 +0200 | matthewmosior | (~matthewmo@173.170.253.91) |