IRCBrowse

2022/08/28

2022-08-28 00:02:15 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 00:03:42 +0200nate4(~nate@98.45.169.16)
2022-08-28 00:04:21 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-08-28 00:06:37 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2022-08-28 00:11:23 +0200dtman34_(~dtman34@2601:446:4400:2ad9:9069:db35:869c:4723) (Ping timeout: 244 seconds)
2022-08-28 00:11:49 +0200 <monochrom> I would make my own judgment whether to listen to coding style advices or not.
2022-08-28 00:13:18 +0200 <monochrom> In this case the advice is no better.
2022-08-28 00:13:19 +0200 <int-e> "I always listen to advice. It's polite." -- Terry Pratchett (This was followed by "If I *heeded* all the advice I've had over the years, I've have written 18 books about Rincewind.")
2022-08-28 00:13:41 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 260 seconds)
2022-08-28 00:18:16 +0200 <hpc> if you ever want to truly understand how arbitrary code style is, look at the configuration for eclipse's java autoformatter :D
2022-08-28 00:19:02 +0200 <hpc> personally, i think of code style in terms of "what idea am i trying to communicate"
2022-08-28 00:19:23 +0200 <hpc> because ultimately that's the only thing that matters
2022-08-28 00:19:45 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:fa6e:5383:4435:8be3) (Remote host closed the connection)
2022-08-28 00:20:03 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:5b7e:4694:daec:fba0)
2022-08-28 00:20:34 +0200 <monochrom> OK, I misread. The suggestion is better.
2022-08-28 00:21:13 +0200 <monochrom> The concern in this case is trying to stay either "data flow from left to right" or "data flow from right to left".
2022-08-28 00:21:50 +0200 <monochrom> Although, I don't normally care.
2022-08-28 00:22:19 +0200 <monochrom> I care about how to do algebraic reasoning, not how imperative programmers think.
2022-08-28 00:31:24 +0200ober_(~ober@c-24-61-80-64.hsd1.ma.comcast.net)
2022-08-28 00:32:21 +0200michalz(~michalz@185.246.204.90) (Remote host closed the connection)
2022-08-28 00:33:35 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 00:34:28 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:5b7e:4694:daec:fba0) (Remote host closed the connection)
2022-08-28 00:34:46 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:b1a2:d584:896c:ce62)
2022-08-28 00:35:06 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:b1a2:d584:896c:ce62) (Remote host closed the connection)
2022-08-28 00:38:10 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 268 seconds)
2022-08-28 00:39:24 +0200wonko(~wjc@2a0e:1c80:2::130) (Ping timeout: 268 seconds)
2022-08-28 00:41:00 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 00:44:20 +0200olle(~olle@h-94-254-63-12.NA.cust.bahnhof.se) (Ping timeout: 268 seconds)
2022-08-28 00:45:11 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 00:46:14 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!)
2022-08-28 00:49:37 +0200kannon(~NK@74-95-14-193-SFBA.hfc.comcastbusiness.net)
2022-08-28 00:51:44 +0200Midjak(~Midjak@82.66.147.146)
2022-08-28 00:55:57 +0200hippoid(~idris@c-98-220-13-8.hsd1.il.comcast.net)
2022-08-28 00:56:07 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 00:56:22 +0200 <ozkutuk> Did this PR end up in GHC 9.2.1? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4614
2022-08-28 00:56:26 +0200 <ozkutuk> I couldn't find anything relevant in the release notes
2022-08-28 01:05:57 +0200 <geekosaur> not in the release notes, but empirically nit seems to be there
2022-08-28 01:06:00 +0200 <geekosaur> *it
2022-08-28 01:11:57 +0200kaskal(~kaskal@213-225-33-152.nat.highway.a1.net)
2022-08-28 01:12:05 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 268 seconds)
2022-08-28 01:12:38 +0200Guest4172(~chenqisu1@183.217.200.212)
2022-08-28 01:13:08 +0200wonko(~wjc@2a0e:1c80:2::130)
2022-08-28 01:14:00 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 01:16:59 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-28 01:19:47 +0200beteigeuze(~Thunderbi@bl11-28-222.dsl.telepac.pt)
2022-08-28 01:20:22 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 01:24:14 +0200kannon(~NK@74-95-14-193-SFBA.hfc.comcastbusiness.net) (Ping timeout: 244 seconds)
2022-08-28 01:27:43 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 01:31:00 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-08-28 01:31:15 +0200bitdex_(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds)
2022-08-28 01:32:44 +0200wonko(~wjc@2a0e:1c80:2::130) (Ping timeout: 255 seconds)
2022-08-28 01:33:38 +0200bitdex_(~bitdex@gateway/tor-sasl/bitdex)
2022-08-28 01:34:46 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds)
2022-08-28 01:35:23 +0200juri__juri_
2022-08-28 01:37:20 +0200euandreh(~euandreh@179.214.113.107) (Ping timeout: 268 seconds)
2022-08-28 01:39:56 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 01:43:41 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-08-28 01:46:05 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 01:51:19 +0200Sgeo(~Sgeo@user/sgeo)
2022-08-28 01:52:51 +0200ddellacosta(~ddellacos@143.244.47.100) (Ping timeout: 260 seconds)
2022-08-28 01:53:15 +0200nate4(~nate@98.45.169.16) (Read error: Connection reset by peer)
2022-08-28 01:53:31 +0200nate4(~nate@98.45.169.16)
2022-08-28 01:55:35 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 01:55:57 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 252 seconds)
2022-08-28 01:57:51 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-08-28 01:58:58 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-08-28 01:59:04 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec)
2022-08-28 02:00:09 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 02:03:14 +0200shapr(~user@68.54.166.125)
2022-08-28 02:05:06 +0200nate4(~nate@98.45.169.16) (Ping timeout: 260 seconds)
2022-08-28 02:06:08 +0200enek(~enek@pool-100-11-18-203.phlapa.fios.verizon.net)
2022-08-28 02:09:15 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 02:15:45 +0200euandreh(~euandreh@179.214.113.107)
2022-08-28 02:17:14 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net)
2022-08-28 02:18:20 +0200causal(~user@50.35.83.177) (Quit: WeeChat 3.6)
2022-08-28 02:21:19 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Quit: segfaultfizzbuzz)
2022-08-28 02:21:34 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 02:23:12 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-28 02:23:37 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-28 02:23:39 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-28 02:26:56 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 02:28:22 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 02:29:39 +0200ober_(~ober@c-24-61-80-64.hsd1.ma.comcast.net) (Quit: Leaving)
2022-08-28 02:29:42 +0200bitdex_(~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection)
2022-08-28 02:30:47 +0200bitdex_(~bitdex@gateway/tor-sasl/bitdex)
2022-08-28 02:31:17 +0200Midjak(~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
2022-08-28 02:36:24 +0200 <segfaultfizzbuzz> oh lol i found the stack segfault on macos/m1 thing, it's a known issue looks like https://github.com/commercialhaskell/stack/issues/5607
2022-08-28 02:37:50 +0200 <segfaultfizzbuzz> oh wow if you use bash like the github issue says it doesn't segfault. how can this be!! lol
2022-08-28 02:38:29 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 252 seconds)
2022-08-28 02:51:57 +0200enek(~enek@pool-100-11-18-203.phlapa.fios.verizon.net) (Quit: Textual IRC Client: www.textualapp.com)
2022-08-28 02:52:35 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-28 02:52:54 +0200 <dsal> Yeah, I've run into that.
2022-08-28 02:57:33 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 03:00:35 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 03:03:21 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-28 03:09:03 +0200jmorris(uid537181@id-537181.uxbridge.irccloud.com)
2022-08-28 03:12:20 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
2022-08-28 03:14:58 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-28 03:26:51 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 03:27:45 +0200razetime(~quassel@117.254.35.219)
2022-08-28 03:28:52 +0200nate4(~nate@98.45.169.16)
2022-08-28 03:40:32 +0200mvk(~mvk@2607:fea8:5ce3:8500::a1ec) (Ping timeout: 255 seconds)
2022-08-28 03:45:58 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net)
2022-08-28 03:50:41 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds)
2022-08-28 03:58:16 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds)
2022-08-28 03:58:22 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-28 03:58:28 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 04:02:19 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2022-08-28 04:02:21 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 260 seconds)
2022-08-28 04:02:33 +0200bitmapper(uid464869@id-464869.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 04:04:14 +0200xff0x(~xff0x@2405:6580:b080:900:1b20:aae8:b54a:f45a)
2022-08-28 04:10:18 +0200beteigeuze(~Thunderbi@bl11-28-222.dsl.telepac.pt) (Ping timeout: 268 seconds)
2022-08-28 04:12:46 +0200td_(~td@94.134.91.193) (Ping timeout: 268 seconds)
2022-08-28 04:14:24 +0200td_(~td@94.134.91.78)
2022-08-28 04:16:15 +0200nate4(~nate@98.45.169.16) (Read error: Connection reset by peer)
2022-08-28 04:16:31 +0200nate4(~nate@98.45.169.16)
2022-08-28 04:16:47 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 04:17:41 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net)
2022-08-28 04:18:51 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 04:25:43 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 04:32:05 +0200Furor(~colere@about/linux/staff/sauvin)
2022-08-28 04:34:32 +0200Colere(~colere@about/linux/staff/sauvin) (Ping timeout: 255 seconds)
2022-08-28 04:35:47 +0200ddellacosta(~ddellacos@89.46.62.222)
2022-08-28 04:36:53 +0200FurorColere
2022-08-28 04:45:21 +0200bontaq(~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 252 seconds)
2022-08-28 04:53:34 +0200dtman34(~dtman34@c-73-62-246-247.hsd1.mn.comcast.net)
2022-08-28 04:58:02 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2022-08-28 04:58:02 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2022-08-28 04:58:02 +0200finn_elijaFinnElija
2022-08-28 05:00:02 +0200haasn(~nand@haasn.dev) (Quit: ZNC 1.7.5+deb4 - https://znc.in)
2022-08-28 05:01:22 +0200haasn(~nand@haasn.dev)
2022-08-28 05:02:26 +0200dtman34(~dtman34@c-73-62-246-247.hsd1.mn.comcast.net) (Ping timeout: 260 seconds)
2022-08-28 05:03:36 +0200xff0x(~xff0x@2405:6580:b080:900:1b20:aae8:b54a:f45a) (Ping timeout: 260 seconds)
2022-08-28 05:05:31 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net)
2022-08-28 05:06:16 +0200Me-me(~me-me@v.working.name) (Changing host)
2022-08-28 05:06:16 +0200Me-me(~me-me@user/me-me)
2022-08-28 05:06:22 +0200dtman34(~dtman34@c-73-62-246-247.hsd1.mn.comcast.net)
2022-08-28 05:12:39 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-28 05:13:55 +0200 <segfaultfizzbuzz> dsal: are you still using stack on m1/macos or did you switch to something else?
2022-08-28 05:14:35 +0200 <dsal> segfaultfizzbuzz: yeah, I'm using stack with nix integration
2022-08-28 05:15:27 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-08-28 05:15:56 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-28 05:17:01 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net) (Ping timeout: 260 seconds)
2022-08-28 05:20:51 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
2022-08-28 05:24:41 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 05:27:56 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net)
2022-08-28 05:33:01 +0200matthewmosior(~matthewmo@173.170.253.91) (Remote host closed the connection)
2022-08-28 05:37:51 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 05:45:11 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-28 05:50:04 +0200nate4(~nate@98.45.169.16) (Read error: Connection reset by peer)
2022-08-28 05:50:29 +0200nate4(~nate@98.45.169.16)
2022-08-28 05:51:17 +0200vglfr(~vglfr@145.224.94.75) (Read error: Connection reset by peer)
2022-08-28 05:52:35 +0200vglfr(~vglfr@145.224.94.75)
2022-08-28 05:53:46 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds)
2022-08-28 05:57:25 +0200linuxLinux
2022-08-28 05:57:59 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 06:00:02 +0200xff0x(~xff0x@ai071162.d.east.v6connect.net)
2022-08-28 06:06:30 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 06:08:08 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Ping timeout: 268 seconds)
2022-08-28 06:09:48 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-28 06:12:56 +0200vglfr(~vglfr@145.224.94.75) (Read error: Connection reset by peer)
2022-08-28 06:13:00 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 06:14:15 +0200vglfr(~vglfr@145.224.94.75)
2022-08-28 06:14:26 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 06:20:31 +0200radhika(uid560836@id-560836.helmsley.irccloud.com)
2022-08-28 06:20:53 +0200 <radhika> Hi.. this is a generic question.. I am trying to learn web dev and started with Spock
2022-08-28 06:21:04 +0200 <radhika> Kept getting multiple error messages
2022-08-28 06:21:36 +0200califax(~califax@user/califx) (Remote host closed the connection)
2022-08-28 06:21:44 +0200 <radhika> Specifically this video
2022-08-28 06:21:49 +0200 <radhika> https://youtube.com/watch?v=Orm-jIIgVD0&feature=share
2022-08-28 06:21:58 +0200califax(~califax@user/califx)
2022-08-28 06:22:29 +0200 <radhika> I keep getting multiple error messages which when googled says Spock is not compatible with current ghc I have installed
2022-08-28 06:23:13 +0200 <radhika> When I try to install ghc 8.2 it gives fdiagnostics colour error
2022-08-28 06:23:29 +0200 <radhika> On googling that I saw that that version is not maintained
2022-08-28 06:24:18 +0200 <radhika> Is there anyone who is learning Spock or any other simple framework currently?
2022-08-28 06:24:55 +0200 <radhika> In general how do u learn it? I have tried multiple tutorials and example.. many of them have non compatibility issue..
2022-08-28 06:25:56 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 06:26:20 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 06:26:52 +0200 <dmj`> radhika: IHP seems to have good docs https://ihp.digitallyinduced.com/
2022-08-28 06:29:03 +0200razetime(~quassel@117.254.35.219) (Ping timeout: 268 seconds)
2022-08-28 06:32:16 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 260 seconds)
2022-08-28 06:32:23 +0200 <radhika> @dmj hi.. So Spock does not work any more??
2022-08-28 06:32:23 +0200 <lambdabot> <unknown>.hs:1:3:Parse error: ..
2022-08-28 06:32:47 +0200 <radhika> Are there simpler frameworks for beginners??
2022-08-28 06:34:24 +0200 <radhika> In general how do u check if ur ghc installation matches or is compatible with different packages or frameworks that u want to learn
2022-08-28 06:34:54 +0200 <dsal> You'd normally use your stack or cabal or nix project to manage that.
2022-08-28 06:34:55 +0200 <glguy> radhika: the package maintainer is supposed to communicate which versions are supported using version bounds
2022-08-28 06:35:00 +0200 <dsal> How did you install ghc?
2022-08-28 06:35:09 +0200 <glguy> but some both bother because it can be a lot of work to keep them accurate
2022-08-28 06:35:20 +0200 <radhika> Ghcup
2022-08-28 06:35:57 +0200 <radhika> That’s the recommended way from Haskell site?
2022-08-28 06:36:02 +0200 <dsal> Is there a reason you want 8.2?
2022-08-28 06:36:12 +0200 <radhika> No
2022-08-28 06:36:26 +0200 <radhika> Spock was giving errors with 8.7
2022-08-28 06:36:30 +0200 <dsal> Anyway, if you start a new project with stack or cabal, you can specify your dependencies.
2022-08-28 06:36:33 +0200 <radhika> I googled the error
2022-08-28 06:36:38 +0200 <dsal> I've never used spock. scotty is pretty easy.
2022-08-28 06:37:00 +0200 <radhika> Saw message that ghc 8.2 is last compatible version
2022-08-28 06:37:05 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 06:37:08 +0200 <dsal> You've not really described the error in any way I think anyone can guess about, but if you're starting, you might try something more recent in general.
2022-08-28 06:37:15 +0200 <radhika> That’s why 8.2
2022-08-28 06:37:59 +0200 <radhika> @dsal yes.. hence the question how do you know which frameworks are compatible with a particular ghc version
2022-08-28 06:37:59 +0200 <lambdabot> Maybe you meant: keal eval
2022-08-28 06:38:22 +0200 <glguy> radhika: @ is for bot commands, you don't need to write it
2022-08-28 06:38:35 +0200 <radhika> Ok
2022-08-28 06:38:37 +0200 <glguy> Spock builds with ghc 8.10.7 and that's the ghcup recommended version
2022-08-28 06:40:39 +0200 <dsal> radhika: That's kind of a difficult way to think about things. Each version of each package will have a list of its dependencies and version bounds for each, which might include base deps and stuff. Something like stackage is easier to manage this graph most of the time. I don't see spock in recent releases at all.
2022-08-28 06:41:40 +0200 <radhika> Dsal understood.. that’s why it would help if you could let me know how to go about it.. I spent a lot of time just on this yesterday 😅
2022-08-28 06:42:22 +0200 <radhika> Shouldn’t stack new project name resolver-lts version number automatically take care of this issue?
2022-08-28 06:42:24 +0200 <dsal> Sure, you're asking about a specific library I don't know. It's probably fine, but I don't know it and I don't see it where I typically get libraries.
2022-08-28 06:42:43 +0200 <dsal> It should if that library's in the LTS resolver.
2022-08-28 06:43:25 +0200 <radhika> Dsal and that can be verified from stackage right?
2022-08-28 06:43:36 +0200 <dsal> e.g., https://www.stackage.org/lts-19.20/hoogle?q=spock
2022-08-28 06:43:51 +0200 <dsal> I only see one result. I don't know if it's the one you need or not.
2022-08-28 06:44:17 +0200 <dsal> For what it sounds like you're doing, I use this one: https://www.stackage.org/lts-19.20/hoogle?q=scotty
2022-08-28 06:44:19 +0200 <glguy> "cabal repl --build-dep Spock -w ghc-8.10.7" was enough to get Spock up and built. if you set ghc-8.10.7 as your default GHC in ghcup (or pick it with -w) you'll be good to go
2022-08-28 06:45:37 +0200 <dsal> Not knowing what the error is, it's hard to understand what you're running into. glguy knows what he's talking about more than I do by far. :)
2022-08-28 06:45:38 +0200 <radhika> Dsal glguy thanks for the tips.. I will have another go at it. Fact is I have nuked installations number of times just because of tooling.. will re try and see
2022-08-28 06:45:43 +0200 <radhika> Thanks again
2022-08-28 06:47:55 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 06:48:36 +0200shapr(~user@68.54.166.125) (Ping timeout: 260 seconds)
2022-08-28 06:53:42 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 06:54:20 +0200ddellacosta(~ddellacos@89.46.62.222) (Ping timeout: 268 seconds)
2022-08-28 06:54:51 +0200jmd_(~jmdaemon@user/jmdaemon)
2022-08-28 06:56:11 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 260 seconds)
2022-08-28 07:01:44 +0200jmd_(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 07:02:27 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 07:03:13 +0200bilegeek(~bilegeek@2600:1008:b045:672c:5812:f108:9f:4ee1)
2022-08-28 07:05:44 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
2022-08-28 07:07:12 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2022-08-28 07:07:37 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-28 07:07:45 +0200razetime(~quassel@117.254.35.219)
2022-08-28 07:08:03 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-28 07:17:49 +0200zebrag(~chris@user/zebrag) (Quit: Konversation terminated!)
2022-08-28 07:18:29 +0200famubu(~famubu@14.139.174.50)
2022-08-28 07:18:30 +0200famubu(~famubu@14.139.174.50) (Changing host)
2022-08-28 07:18:30 +0200famubu(~famubu@user/famubu)
2022-08-28 07:24:09 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
2022-08-28 07:25:20 +0200mrd(~mrd@45.61.147.211) (Changing host)
2022-08-28 07:25:20 +0200mrd(~mrd@user/mrd)
2022-08-28 07:25:33 +0200mrd(~mrd@user/mrd) ()
2022-08-28 07:26:56 +0200 <famubu> Is it possible to have a type which accepts two arguments? I was trying to have something like ` data Vect (n::Int) a = Cons a (Vect n a)`
2022-08-28 07:28:34 +0200 <famubu> Oh, `data Vect n a = Cons a (Vect n a)` runs without error. They explicit type was causing trouble.
2022-08-28 07:29:35 +0200talismanick(~talismani@2601:200:c100:3850::dd64)
2022-08-28 07:32:11 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 07:32:21 +0200Guest4172(~chenqisu1@183.217.200.212) (Ping timeout: 260 seconds)
2022-08-28 07:37:04 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net)
2022-08-28 07:38:20 +0200bilegeek_(~bilegeek@219.sub-174-209-41.myvzw.com)
2022-08-28 07:39:37 +0200mbuf(~Shakthi@122.165.55.71)
2022-08-28 07:40:50 +0200bilegeek(~bilegeek@2600:1008:b045:672c:5812:f108:9f:4ee1) (Ping timeout: 255 seconds)
2022-08-28 07:41:21 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-28 07:51:55 +0200 <dsal> If you mean `n :: Int` you'd just say `Int` and not name it.
2022-08-28 07:55:31 +0200coot(~coot@213.134.176.158)
2022-08-28 08:01:37 +0200zebrag(~chris@user/zebrag)
2022-08-28 08:03:36 +0200wei2912(~wei2912@138.75.147.149)
2022-08-28 08:05:44 +0200zebrag(~chris@user/zebrag) (Client Quit)
2022-08-28 08:16:02 +0200 <famubu> dsal: But what if we wanted to refer to that particular n in the construct? (Is that even possible?)
2022-08-28 08:17:00 +0200 <fvr> famubu: you will have this instead `data Vect a = Cons a (Vect Int a)`
2022-08-28 08:17:18 +0200 <dsal> You can make n a variable, or you can use Int
2022-08-28 08:18:04 +0200 <dsal> There are a few other kind of hacky things you can do, but it's not clear why you'd want that.
2022-08-28 08:23:06 +0200nate4(~nate@98.45.169.16)
2022-08-28 08:30:14 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2022-08-28 08:30:36 +0200shriekingnoise(~shrieking@186.137.167.202) (Quit: Quit)
2022-08-28 08:32:23 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 268 seconds)
2022-08-28 08:32:49 +0200hgolden(~Howard@cpe-172-251-233-141.socal.res.rr.com) (Quit: Leaving)
2022-08-28 08:33:41 +0200slaydr(~slaydr@173.239.197.75)
2022-08-28 08:34:09 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 08:34:31 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-28 08:40:23 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 08:40:47 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 08:45:51 +0200qrpnxz(~qrpnxz@fsf/member/qrpnxz) (Ping timeout: 260 seconds)
2022-08-28 08:47:03 +0200nattiestnate(~nate@202.138.250.6)
2022-08-28 08:47:51 +0200qrpnxz(~qrpnxz@fsf/member/qrpnxz)
2022-08-28 08:48:11 +0200famubu(~famubu@user/famubu) (Ping timeout: 260 seconds)
2022-08-28 08:54:36 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2022-08-28 08:55:41 +0200famubu(~famubu@14.139.174.50)
2022-08-28 08:56:34 +0200Guest|18(~Guest|18@2-107-248-53-dynamic.dk.customer.tdc.net)
2022-08-28 08:57:26 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-28 08:57:59 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
2022-08-28 08:58:48 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-28 09:08:15 +0200toeffel(~toeffel@user/toeffel)
2022-08-28 09:09:12 +0200gmg(~user@user/gehmehgeh)
2022-08-28 09:15:25 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-28 09:17:01 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it)
2022-08-28 09:23:11 +0200Vajb(~Vajb@2001:999:705:3c86:e7ea:442b:1e01:22d8) (Read error: Connection reset by peer)
2022-08-28 09:23:47 +0200Vajb(~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi)
2022-08-28 09:26:00 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-08-28 09:28:15 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 09:29:42 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 09:30:12 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 09:32:12 +0200famubu(~famubu@14.139.174.50) (Ping timeout: 268 seconds)
2022-08-28 09:33:06 +0200Guest|18(~Guest|18@2-107-248-53-dynamic.dk.customer.tdc.net) (Ping timeout: 260 seconds)
2022-08-28 09:37:45 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 268 seconds)
2022-08-28 09:40:20 +0200radhika(uid560836@id-560836.helmsley.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 09:48:14 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 268 seconds)
2022-08-28 09:52:21 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:d256:ff55:46cc:bc89)
2022-08-28 09:53:31 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-08-28 09:57:35 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com)
2022-08-28 10:00:23 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:d256:ff55:46cc:bc89) (Remote host closed the connection)
2022-08-28 10:00:42 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:1194:9d69:3198:4ddf)
2022-08-28 10:08:19 +0200olle(~olle@h-94-254-63-12.NA.cust.bahnhof.se)
2022-08-28 10:08:30 +0200jmd_(~jmdaemon@user/jmdaemon)
2022-08-28 10:09:12 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 10:14:57 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:1194:9d69:3198:4ddf) (Remote host closed the connection)
2022-08-28 10:15:15 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:7323:e5c3:cf25:ff32)
2022-08-28 10:21:02 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2022-08-28 10:21:31 +0200elkcl(~elkcl@broadband-37-110-156-162.ip.moscow.rt.ru)
2022-08-28 10:22:46 +0200jmd_(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 10:23:07 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 10:28:08 +0200nilradical(~nilradica@user/naso)
2022-08-28 10:28:16 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it)
2022-08-28 10:32:44 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 255 seconds)
2022-08-28 10:37:59 +0200MoC(~moc@user/moc)
2022-08-28 10:38:46 +0200jmorris(uid537181@id-537181.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 10:40:00 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 10:40:38 +0200notzmv(~zmv@user/notzmv)
2022-08-28 10:40:40 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-28 10:41:52 +0200nilradical(~nilradica@user/naso)
2022-08-28 10:41:59 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 10:42:07 +0200nattiestnate(~nate@202.138.250.6) (Quit: WeeChat 3.6)
2022-08-28 10:42:26 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2022-08-28 10:44:22 +0200Guest4172(~chenqisu1@183.217.200.212)
2022-08-28 10:44:57 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 10:45:30 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net)
2022-08-28 10:45:51 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-28 10:46:14 +0200nilradical(~nilradica@user/naso)
2022-08-28 10:46:21 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-28 10:47:14 +0200wonko(~wjc@2a0e:1c80:2::130)
2022-08-28 10:47:34 +0200nilradical(~nilradica@user/naso)
2022-08-28 10:47:49 +0200frost(~frost@user/frost)
2022-08-28 10:47:59 +0200nate4(~nate@98.45.169.16)
2022-08-28 10:49:30 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:7323:e5c3:cf25:ff32) (Ping timeout: 252 seconds)
2022-08-28 10:49:50 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 255 seconds)
2022-08-28 10:51:09 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
2022-08-28 10:52:59 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-28 10:53:52 +0200jakalx(~jakalx@base.jakalx.net) ()
2022-08-28 10:55:37 +0200ten_finger_typis(~ten_finge@adsl-84-226-91-51.adslplus.ch)
2022-08-28 11:00:53 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-28 11:01:33 +0200 <ten_finger_typis> Morning. I am trying to understand a bit more about unsafeCoerce. It is safe, if the two types have the same representation, but what about GADTs like lists or Maybe. Is the following safe?
2022-08-28 11:01:33 +0200 <ten_finger_typis> f :: [a] -> Int
2022-08-28 11:01:34 +0200 <ten_finger_typis> f x = length (unsafeCoerce x :: [()])
2022-08-28 11:01:59 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:14aa:bc5f:ec5b:98ab)
2022-08-28 11:02:04 +0200nilradical(~nilradica@user/naso)
2022-08-28 11:06:48 +0200nilradical(~nilradica@user/naso) (Remote host closed the connection)
2022-08-28 11:07:03 +0200nilradical(~nilradica@user/naso)
2022-08-28 11:10:21 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds)
2022-08-28 11:12:21 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 11:17:23 +0200jakalx(~jakalx@base.jakalx.net)
2022-08-28 11:20:37 +0200alternateved(~user@staticline-31-183-146-203.toya.net.pl)
2022-08-28 11:20:44 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 268 seconds)
2022-08-28 11:20:46 +0200toeffel(~toeffel@user/toeffel) (Quit: quit)
2022-08-28 11:21:19 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 268 seconds)
2022-08-28 11:21:21 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 11:23:30 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 11:25:08 +0200bilegeek_(~bilegeek@219.sub-174-209-41.myvzw.com) (Quit: Leaving)
2022-08-28 11:25:29 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-28 11:26:13 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-28 11:28:06 +0200Midjak(~Midjak@82.66.147.146)
2022-08-28 11:37:10 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:14aa:bc5f:ec5b:98ab) (Ping timeout: 252 seconds)
2022-08-28 11:39:35 +0200pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
2022-08-28 11:40:43 +0200ChaiTRex(~ChaiTRex@user/chaitrex) (Remote host closed the connection)
2022-08-28 11:40:43 +0200king_gs(~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec)
2022-08-28 11:41:07 +0200ChaiTRex(~ChaiTRex@user/chaitrex)
2022-08-28 11:42:55 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-28 11:47:51 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 260 seconds)
2022-08-28 11:48:52 +0200talismanick(~talismani@2601:200:c100:3850::dd64) (Ping timeout: 244 seconds)
2022-08-28 11:49:38 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:dee3:1ebd:2b27:6d24)
2022-08-28 11:51:38 +0200mima(mmh@gateway/vpn/airvpn/mima)
2022-08-28 11:56:12 +0200kilolympus(~kilolympu@90.203.82.22)
2022-08-28 11:57:53 +0200Vajb(~Vajb@hag-jnsbng11-58c3ad-40.dhcp.inet.fi) (Read error: Connection reset by peer)
2022-08-28 11:58:33 +0200 <kilolympus> Are compiler versions in the Hackage build runner determined based on anything?
2022-08-28 11:59:10 +0200 <kilolympus> Our project is trying to build with 9.2.4 here: https://hackage.haskell.org/package/discord-haskell-1.15.1/reports/
2022-08-28 11:59:19 +0200 <kilolympus> while it built with 8.10.2 before: https://hackage.haskell.org/package/discord-haskell-1.15.0/reports/
2022-08-28 11:59:34 +0200 <kilolympus> The diff between those two versions are almost negligible: https://github.com/discord-haskell/discord-haskell/compare/210e46bef7138540774f24cfc4cbb0b6a20420c…
2022-08-28 12:00:08 +0200Vajb(~Vajb@2001:999:705:3c86:e7ea:442b:1e01:22d8)
2022-08-28 12:01:28 +0200 <kilolympus> For info, the two versions were published by different people but I don't think the user's own PC environment would have affected this
2022-08-28 12:02:56 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:dee3:1ebd:2b27:6d24) (Remote host closed the connection)
2022-08-28 12:03:17 +0200__monty__(~toonn@user/toonn)
2022-08-28 12:03:45 +0200nilradical(~nilradica@user/naso) ()
2022-08-28 12:05:52 +0200mastarija(~mastarija@2a05:4f46:e03:6000:d36e:4952:1bda:e264)
2022-08-28 12:05:56 +0200wonko(~wjc@2a0e:1c80:2::130) (Ping timeout: 260 seconds)
2022-08-28 12:07:13 +0200king_gs(~Thunderbi@2806:103e:29:da7a:1f74:531c:dec2:7aec) (Quit: king_gs)
2022-08-28 12:15:59 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 252 seconds)
2022-08-28 12:17:14 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 12:26:46 +0200bontaq(~user@ool-45779fe5.dyn.optonline.net)
2022-08-28 12:30:23 +0200gehmehgeh(~user@user/gehmehgeh)
2022-08-28 12:31:42 +0200gmg(~user@user/gehmehgeh) (Ping timeout: 268 seconds)
2022-08-28 12:31:45 +0200stefan-_(~cri@42dots.de) (Ping timeout: 252 seconds)
2022-08-28 12:32:06 +0200gehmehgehgmg
2022-08-28 12:37:15 +0200gmg(~user@user/gehmehgeh) (Ping timeout: 268 seconds)
2022-08-28 12:40:51 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-28 12:41:39 +0200yaroot(~yaroot@p2550227-ipngn11101souka.saitama.ocn.ne.jp) (Ping timeout: 248 seconds)
2022-08-28 12:42:06 +0200vglfr(~vglfr@145.224.94.75) (Ping timeout: 268 seconds)
2022-08-28 12:43:27 +0200gmg(~user@user/gehmehgeh)
2022-08-28 12:44:55 +0200stefan-_(~cri@42dots.de)
2022-08-28 12:46:25 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-08-28 12:46:41 +0200wei2912(~wei2912@138.75.147.149) (Quit: Lost terminal)
2022-08-28 12:47:04 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2022-08-28 12:47:13 +0200gmg(~user@user/gehmehgeh)
2022-08-28 12:47:23 +0200titibandit(~titibandi@xdsl-87-78-66-58.nc.de)
2022-08-28 12:50:27 +0200cheater(~Username@user/cheater) (Ping timeout: 252 seconds)
2022-08-28 12:51:00 +0200cheater(~Username@user/cheater)
2022-08-28 12:58:12 +0200ten_finger_typis(~ten_finge@adsl-84-226-91-51.adslplus.ch) (Ping timeout: 252 seconds)
2022-08-28 13:02:40 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-08-28 13:19:38 +0200 <Franciman> does anbody use haskell in semantic web applications?
2022-08-28 13:20:11 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2022-08-28 13:26:00 +0200 <darkling> I found quite a few RDF libraries searching on hackage a while ago. I haven't used Haskell enough to get around to the semweb side of things yet, though.
2022-08-28 13:26:17 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it)
2022-08-28 13:26:39 +0200 <darkling> With that level of support, I'd be surprised if there weren't people using them somewhere.
2022-08-28 13:29:20 +0200jmd_(~jmdaemon@user/jmdaemon)
2022-08-28 13:29:35 +0200mastarija(~mastarija@2a05:4f46:e03:6000:d36e:4952:1bda:e264) (Ping timeout: 255 seconds)
2022-08-28 13:30:51 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 13:31:43 +0200notzmv(~zmv@user/notzmv)
2022-08-28 13:33:29 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-08-28 13:34:01 +0200pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5)
2022-08-28 13:34:23 +0200pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
2022-08-28 13:34:32 +0200gmg(~user@user/gehmehgeh)
2022-08-28 13:38:52 +0200jmd_(~jmdaemon@user/jmdaemon) (Ping timeout: 268 seconds)
2022-08-28 13:42:11 +0200alternateved(~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection)
2022-08-28 13:43:07 +0200random-jellyfish(~random-je@user/random-jellyfish)
2022-08-28 13:44:38 +0200vglfr(~vglfr@145.224.94.78)
2022-08-28 13:44:57 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-28 13:46:17 +0200qhong(~qhong@rescomp-21-400677.stanford.edu) (Read error: Connection reset by peer)
2022-08-28 13:47:31 +0200qhong(~qhong@rescomp-21-400677.stanford.edu)
2022-08-28 13:48:03 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-28 13:49:03 +0200mastarija(~mastarija@2a05:4f46:e03:6000:4bd1:c2b:75be:ac1b)
2022-08-28 13:49:56 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 268 seconds)
2022-08-28 13:49:58 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 268 seconds)
2022-08-28 13:50:31 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f)
2022-08-28 13:51:21 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 13:52:50 +0200mastarija(~mastarija@2a05:4f46:e03:6000:4bd1:c2b:75be:ac1b) (Client Quit)
2022-08-28 13:53:53 +0200instantaphex(~jb@c-73-171-252-84.hsd1.fl.comcast.net) (Ping timeout: 252 seconds)
2022-08-28 13:57:21 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-28 13:58:29 +0200mbuf(~Shakthi@122.165.55.71) (Remote host closed the connection)
2022-08-28 13:59:36 +0200mbuf(~Shakthi@122.165.55.71)
2022-08-28 14:00:26 +0200jakalx(~jakalx@base.jakalx.net) ()
2022-08-28 14:01:10 +0200jakalx(~jakalx@base.jakalx.net)
2022-08-28 14:04:23 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-28 14:04:56 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-08-28 14:08:13 +0200titibandit(~titibandi@xdsl-87-78-66-58.nc.de) (Remote host closed the connection)
2022-08-28 14:12:12 +0200 <albet70> @djinn a->b->a
2022-08-28 14:12:12 +0200 <lambdabot> f a _ = a
2022-08-28 14:12:48 +0200 <albet70> @hoogle a->b->b
2022-08-28 14:12:49 +0200 <lambdabot> Prelude seq :: forall (r :: RuntimeRep) a (b :: TYPE r) . a -> b -> b
2022-08-28 14:12:49 +0200 <lambdabot> GHC.Conc par :: a -> b -> b
2022-08-28 14:12:49 +0200 <lambdabot> GHC.Conc pseq :: a -> b -> b
2022-08-28 14:14:43 +0200vspecky(~vspecky@223.190.87.252)
2022-08-28 14:15:02 +0200mbuf(~Shakthi@122.165.55.71) (Remote host closed the connection)
2022-08-28 14:15:54 +0200mbuf(~Shakthi@122.165.55.71)
2022-08-28 14:26:37 +0200 <vspecky> Hey there, I'm a recently graduated software engineer currently exploring haskell (and purescript) and functional programming in general. Also a newbie to IRC in general. Nice to be here!
2022-08-28 14:29:24 +0200koala_man(~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 268 seconds)
2022-08-28 14:29:53 +0200alternateved(~user@staticline-31-183-146-203.toya.net.pl)
2022-08-28 14:31:06 +0200causal(~user@50.35.83.177)
2022-08-28 14:31:32 +0200 <geekosaur> o/
2022-08-28 14:36:20 +0200nate4(~nate@98.45.169.16)
2022-08-28 14:37:32 +0200Topsi(~Topsi@dyndsl-095-033-090-077.ewe-ip-backbone.de)
2022-08-28 14:41:46 +0200nate4(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-28 14:44:28 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-28 14:45:54 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 14:46:22 +0200kaskal(~kaskal@213-225-33-152.nat.highway.a1.net) (Quit: ZNC - https://znc.in)
2022-08-28 14:47:46 +0200random-jellyfish(~random-je@user/random-jellyfish) (Quit: Client closed)
2022-08-28 14:49:59 +0200kaskal(~kaskal@2001:4bb8:2dc:7b0e:55ee:692c:e44d:a4b0)
2022-08-28 14:51:22 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com)
2022-08-28 14:51:56 +0200vspecky(~vspecky@223.190.87.252) (Quit: Leaving)
2022-08-28 14:53:20 +0200Pickchea(~private@user/pickchea)
2022-08-28 14:55:07 +0200Guest4172(~chenqisu1@183.217.200.212) (Ping timeout: 252 seconds)
2022-08-28 15:02:42 +0200toeffel(~toeffel@user/toeffel)
2022-08-28 15:05:56 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it)
2022-08-28 15:06:39 +0200 <Franciman> ty darkling
2022-08-28 15:07:21 +0200razetime(~quassel@117.254.35.219) (Ping timeout: 260 seconds)
2022-08-28 15:08:17 +0200L29Ah(~L29Ah@wikipedia/L29Ah) (Ping timeout: 268 seconds)
2022-08-28 15:10:43 +0200mima(mmh@gateway/vpn/airvpn/mima) (Ping timeout: 268 seconds)
2022-08-28 15:16:03 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-28 15:18:39 +0200eikke(~NicolasT@user/NicolasT)
2022-08-28 15:19:14 +0200razetime(~quassel@117.254.34.136)
2022-08-28 15:27:29 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
2022-08-28 15:34:17 +0200Midjak(~Midjak@82.66.147.146) (Read error: Connection reset by peer)
2022-08-28 15:35:12 +0200Midjak(~Midjak@82.66.147.146)
2022-08-28 15:37:03 +0200eikke(~NicolasT@user/NicolasT) (Read error: Connection reset by peer)
2022-08-28 15:39:26 +0200eikke(~NicolasT@user/NicolasT)
2022-08-28 15:41:54 +0200wolfshappen(~waff@irc.furworks.de) (Ping timeout: 244 seconds)
2022-08-28 15:44:40 +0200frost(~frost@user/frost) (Ping timeout: 252 seconds)
2022-08-28 15:44:54 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 15:46:20 +0200wolfshappen(~waff@irc.furworks.de)
2022-08-28 15:51:25 +0200Pickchea(~private@user/pickchea) (Ping timeout: 268 seconds)
2022-08-28 16:02:02 +0200coot(~coot@213.134.176.158)
2022-08-28 16:04:18 +0200gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2022-08-28 16:05:14 +0200gmg(~user@user/gehmehgeh)
2022-08-28 16:13:02 +0200razetime(~quassel@117.254.34.136) (Ping timeout: 268 seconds)
2022-08-28 16:13:39 +0200razetime(~quassel@117.254.34.154)
2022-08-28 16:15:08 +0200radhika(uid560836@id-560836.helmsley.irccloud.com)
2022-08-28 16:19:41 +0200wolfshappen(~waff@irc.furworks.de) (Ping timeout: 260 seconds)
2022-08-28 16:24:44 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2022-08-28 16:34:27 +0200wolfshappen(~waff@irc.furworks.de)
2022-08-28 16:41:24 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds)
2022-08-28 16:41:51 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-08-28 16:42:09 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-28 16:44:24 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de)
2022-08-28 16:48:02 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-28 16:52:16 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:caf3:451b:8c00:3fe3)
2022-08-28 16:54:05 +0200jespada(~jespada@cpc121060-nmal24-2-0-cust249.19-2.cable.virginm.net) (Read error: Connection reset by peer)
2022-08-28 16:54:30 +0200jespada(~jespada@cpc121060-nmal24-2-0-cust249.19-2.cable.virginm.net)
2022-08-28 16:54:43 +0200Pickchea(~private@user/pickchea)
2022-08-28 16:59:21 +0200razetime(~quassel@117.254.34.154) (Ping timeout: 260 seconds)
2022-08-28 16:59:24 +0200razetime_(~quassel@117.193.4.187)
2022-08-28 17:01:41 +0200gustik(~gustik@2a01:c844:2457:2220:475d:34f:d571:996f)
2022-08-28 17:02:25 +0200gmg(~user@user/gehmehgeh) (Ping timeout: 268 seconds)
2022-08-28 17:03:05 +0200toeffel(~toeffel@user/toeffel) (Ping timeout: 252 seconds)
2022-08-28 17:04:08 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-28 17:04:32 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2022-08-28 17:04:38 +0200gmg(~user@user/gehmehgeh)
2022-08-28 17:07:55 +0200Pickchea(~private@user/pickchea) (Ping timeout: 268 seconds)
2022-08-28 17:08:36 +0200alternateved(~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection)
2022-08-28 17:10:15 +0200 <Linux> /join #kernel
2022-08-28 17:10:20 +0200 <Linux> Eep.
2022-08-28 17:10:22 +0200alternateved(~user@staticline-31-183-146-203.toya.net.pl)
2022-08-28 17:11:39 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:caf3:451b:8c00:3fe3) (Remote host closed the connection)
2022-08-28 17:11:58 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:5f1e:cc4a:57b6:cd25)
2022-08-28 17:12:59 +0200coot(~coot@213.134.176.158)
2022-08-28 17:14:05 +0200eikke(~NicolasT@user/NicolasT) (Ping timeout: 268 seconds)
2022-08-28 17:14:51 +0200bgamari(~bgamari@64.223.169.142) (Read error: Connection reset by peer)
2022-08-28 17:15:01 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 17:16:50 +0200biberu\(~biberu@user/biberu)
2022-08-28 17:17:21 +0200tcard_(~tcard@p945242-ipngn9701hodogaya.kanagawa.ocn.ne.jp)
2022-08-28 17:17:42 +0200Noinia(~Frank@77-162-168-71.fixed.kpn.net)
2022-08-28 17:17:52 +0200drdo5(~drdo@roach0.drdo.eu)
2022-08-28 17:17:56 +0200lambdap237(~lambdap@static.167.190.119.168.clients.your-server.de)
2022-08-28 17:17:59 +0200MironZ2(~MironZ@nat-infra.ehlab.uk)
2022-08-28 17:17:59 +0200ell9(~ellie@user/ellie)
2022-08-28 17:18:05 +0200bollu5(~bollu@159.65.151.13)
2022-08-28 17:18:09 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:5f1e:cc4a:57b6:cd25) (Remote host closed the connection)
2022-08-28 17:18:24 +0200Alex_test_(~al_test@178.34.163.186)
2022-08-28 17:18:25 +0200AlexZenon_2(~alzenon@178.34.163.186)
2022-08-28 17:18:26 +0200orcus-(~orcus@user/brprice)
2022-08-28 17:18:28 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:61c0:691c:619d:f0a1)
2022-08-28 17:18:39 +0200raym_(~raym@user/raym)
2022-08-28 17:19:22 +0200stilgart(~Christoph@chezlefab.net)
2022-08-28 17:19:28 +0200takuan_dozo(~takuan@178-116-218-225.access.telenet.be)
2022-08-28 17:19:30 +0200mmarusea1ph2(~mihai@198.199.98.239)
2022-08-28 17:19:34 +0200glider(~glider@user/glider)
2022-08-28 17:19:46 +0200acidjnk(~acidjnk@p200300d6e7137a04192cc13bdab8a600.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-08-28 17:19:49 +0200Furor(~colere@about/linux/staff/sauvin)
2022-08-28 17:20:03 +0200uroboros(~ouroboros@user/ouroboros)
2022-08-28 17:20:10 +0200kaol(~kaol@94-237-42-30.nl-ams1.upcloud.host)
2022-08-28 17:20:13 +0200bgamari(~bgamari@64.223.130.166)
2022-08-28 17:20:13 +0200razetime_(~quassel@117.193.4.187) (Ping timeout: 268 seconds)
2022-08-28 17:20:15 +0200axeman_(~quassel@net-93-65-246-244.cust.vodafonedsl.it)
2022-08-28 17:20:19 +0200eggplantade(~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net)
2022-08-28 17:20:25 +0200hrberg_(~quassel@171.79-160-161.customer.lyse.net)
2022-08-28 17:20:28 +0200bontaq`(~user@ool-45779fe5.dyn.optonline.net)
2022-08-28 17:20:28 +0200turlando_(~turlando@user/turlando)
2022-08-28 17:20:36 +0200aforemny_(~aforemny@static.248.158.34.188.clients.your-server.de)
2022-08-28 17:20:41 +0200dysfigured(dfg@dfg.rocks)
2022-08-28 17:20:42 +0200Jonno_FT1(~come@api.carswap.me)
2022-08-28 17:20:45 +0200Unode_(~Unode@194.94.44.220)
2022-08-28 17:20:49 +0200mjs2600_(~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net)
2022-08-28 17:20:51 +0200gff_(~gff@user/gff)
2022-08-28 17:20:53 +0200opqdonut_(opqdonut@pseudo.fixme.fi)
2022-08-28 17:20:57 +0200einfair_(~einfair@broadband-90-154-71-147.ip.moscow.rt.ru)
2022-08-28 17:20:58 +0200Clint_(~Clint@user/clint)
2022-08-28 17:21:02 +0200rembo10_(~rembo10@main.remulis.com)
2022-08-28 17:21:05 +0200goldstein(~goldstein@goldstein.rs)
2022-08-28 17:21:05 +0200perrierj1(~perrier-j@modemcable012.251-130-66.mc.videotron.ca)
2022-08-28 17:21:10 +0200lbseale_(~quassel@user/ep1ctetus)
2022-08-28 17:21:11 +0200tompaw_(~tompaw@static-47-206-100-136.tamp.fl.frontiernet.net)
2022-08-28 17:21:11 +0200aku_(~aku@163.172.137.34)
2022-08-28 17:21:13 +0200xerox__(~edi@user/edi)
2022-08-28 17:21:14 +0200jao-(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 17:21:18 +0200ezzieygu1wuf(~Unknown@user/ezzieyguywuf)
2022-08-28 17:21:21 +0200oats_(~thomas@user/oats)
2022-08-28 17:21:24 +0200kraftwerk28_(~kraftwerk@178.62.210.83)
2022-08-28 17:21:29 +0200orcus(~orcus@user/brprice) (Ping timeout: 252 seconds)
2022-08-28 17:21:29 +0200thaumavorio(~thaumavor@thaumavor.io) (Ping timeout: 252 seconds)
2022-08-28 17:21:29 +0200ouroboros(~ouroboros@user/ouroboros) (Ping timeout: 252 seconds)
2022-08-28 17:21:29 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200perrierjouet(~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Rembane(~Rembane@li346-36.members.linode.com) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200aforemny(~aforemny@static.248.158.34.188.clients.your-server.de) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Alex_test(~al_test@178.34.163.186) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200AlexZenon(~alzenon@178.34.163.186) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200mmaruseacph2(~mihai@198.199.98.239) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200aku(~aku@163.172.137.34) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Unode(~Unode@194.94.44.220) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200stilgart_(~Christoph@chezlefab.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200xerox(~edi@user/edi) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Henkru(henkru@kapsi.fi) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200mbuf(~Shakthi@122.165.55.71) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200raym(~raym@user/raym) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200hughjfchen(~hughjfche@vmi556545.contaboserver.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200ystael(~ystael@user/ystael) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200acarrico(~acarrico@dhcp-68-142-48-19.greenmountainaccess.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200malte(~malte@mal.tc) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200ezzieyguywuf(~Unknown@user/ezzieyguywuf) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200adium(adium@user/adium) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200sudden(~cat@user/sudden) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200WzC(~Frank@77-162-168-71.fixed.kpn.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200drdo(~drdo@roach0.drdo.eu) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200tompaw(~tompaw@static-47-206-100-136.tamp.fl.frontiernet.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200lbseale(~quassel@user/ep1ctetus) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200bcmiller(~bm3719@66.42.95.185) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200kraftwerk28(~kraftwerk@178.62.210.83) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200dfg(~dfg@user/dfg) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Hecate(~mariposa@user/hecate) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Clint(~Clint@user/clint) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200MironZ(~MironZ@nat-infra.ehlab.uk) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200oats(~thomas@user/oats) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200cjay(cjay@nerdbox.nerd2nerd.org) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200bah(~bah@l1.tel) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200turlando(~turlando@user/turlando) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200axeman(~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200bontaq(~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Colere(~colere@about/linux/staff/sauvin) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200biberu(~biberu@user/biberu) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200tcard(~tcard@p945242-ipngn9701hodogaya.kanagawa.ocn.ne.jp) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200GoldsteinQ(~goldstein@goldstein.rs) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200TheCoffeMaker_(~TheCoffeM@200.126.129.149) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200kaol_(~kaol@94-237-42-30.nl-ams1.upcloud.host) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200glider_(~glider@user/glider) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Philonous(~Philonous@user/philonous) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200ell(~ellie@user/ellie) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200lambdap23(~lambdap@static.167.190.119.168.clients.your-server.de) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200rembo10(~rembo10@main.remulis.com) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200opqdonut(opqdonut@pseudo.fixme.fi) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200gff(~gff@75-174-108-23.boid.qwest.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200_xor(~xor@74.215.182.83) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200einfair__(~einfair@broadband-90-154-71-147.ip.moscow.rt.ru) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200xsarnik(xsarnik@lounge.fi.muni.cz) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200tv(~tv@user/tv) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200Jonno_FTW(~come@user/jonno-ftw/x-0835346) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200mjs2600(~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200dumptruckman(~dumptruck@23-239-13-163.ip.linodeusercontent.com) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200bollu(~bollu@159.65.151.13) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200tessier(~treed@98.171.210.130) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200wz1000(~zubin@static.11.113.47.78.clients.your-server.de) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200hippoid(~idris@c-98-220-13-8.hsd1.il.comcast.net) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200sagax(~sagax_nb@user/sagax) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200leah_(lp0@heathens.club) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200wagle(~wagle@quassel.wagle.io) (Ping timeout: 252 seconds)
2022-08-28 17:21:30 +0200mbuf(~Shakthi@122.165.55.71)
2022-08-28 17:21:30 +0200dumptruckman(~dumptruck@23-239-13-163.ip.linodeusercontent.com)
2022-08-28 17:21:30 +0200Rembane(~Rembane@li346-36.members.linode.com)
2022-08-28 17:21:30 +0200tessier(~treed@98.171.210.130)
2022-08-28 17:21:31 +0200uroborosouroboros
2022-08-28 17:21:31 +0200Unode_Unode
2022-08-28 17:21:31 +0200lambdap237lambdap23
2022-08-28 17:21:34 +0200Philonous_(~Philonous@user/philonous)
2022-08-28 17:21:34 +0200MironZ2MironZ
2022-08-28 17:21:34 +0200ell9ell
2022-08-28 17:21:34 +0200bollu5bollu
2022-08-28 17:21:40 +0200hughjfchen(~hughjfche@vmi556545.contaboserver.net)
2022-08-28 17:21:45 +0200biberu\biberu
2022-08-28 17:21:54 +0200hippoid(~idris@c-98-220-13-8.hsd1.il.comcast.net)
2022-08-28 17:21:57 +0200sudden(~cat@user/sudden)
2022-08-28 17:21:57 +0200malte(~malte@mal.tc)
2022-08-28 17:21:59 +0200_xor(~xor@74.215.182.83)
2022-08-28 17:22:02 +0200tv(~tv@user/tv)
2022-08-28 17:22:16 +0200thaumavorio(~thaumavor@thaumavor.io)
2022-08-28 17:22:17 +0200leah_(lp0@heathens.club)
2022-08-28 17:22:19 +0200mima(mmh@gateway/vpn/airvpn/mima)
2022-08-28 17:22:30 +0200xsarnik(xsarnik@lounge.fi.muni.cz)
2022-08-28 17:22:34 +0200wz1000(~zubin@static.11.113.47.78.clients.your-server.de)
2022-08-28 17:22:36 +0200wagle(~wagle@quassel.wagle.io)
2022-08-28 17:22:44 +0200acarrico(~acarrico@dhcp-68-142-48-19.greenmountainaccess.net)
2022-08-28 17:23:55 +0200oats_oats
2022-08-28 17:24:21 +0200Henkru(henkru@kapsi.fi)
2022-08-28 17:24:42 +0200TheCoffeMaker(~TheCoffeM@user/thecoffemaker)
2022-08-28 17:25:39 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:61c0:691c:619d:f0a1) (Remote host closed the connection)
2022-08-28 17:25:40 +0200aforemny_aforemny
2022-08-28 17:25:56 +0200bcmiller(~bm3719@66.42.95.185)
2022-08-28 17:25:58 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:e602:ace1:30ba:5cc)
2022-08-28 17:26:14 +0200cjay(cjay@nerdbox.nerd2nerd.org)
2022-08-28 17:26:22 +0200Hecate(~mariposa@user/hecate)
2022-08-28 17:26:22 +0200bah(~bah@l1.tel)
2022-08-28 17:26:24 +0200ystael(~ystael@user/ystael)
2022-08-28 17:27:20 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2022-08-28 17:27:50 +0200adium(adium@user/adium)
2022-08-28 17:28:18 +0200razetime(~quassel@117.254.35.219)
2022-08-28 17:32:27 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2022-08-28 17:33:28 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:e602:ace1:30ba:5cc) (Remote host closed the connection)
2022-08-28 17:33:47 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d)
2022-08-28 17:43:57 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d) (Remote host closed the connection)
2022-08-28 17:44:18 +0200zxx7529(~Thunderbi@user/zxx7529)
2022-08-28 17:44:18 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d)
2022-08-28 17:44:41 +0200toeffel(~toeffel@user/toeffel)
2022-08-28 17:45:15 +0200splitted(~root@88.160.31.174)
2022-08-28 17:47:13 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:9c9c:d9fa:45ff:f5d) (Remote host closed the connection)
2022-08-28 17:47:55 +0200Clint_Clint
2022-08-28 18:00:12 +0200M3w0[m](~M3w0matri@2001:470:69fc:105::2:55b3) (Quit: You have been kicked for being idle)
2022-08-28 18:01:45 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 18:04:12 +0200nilradical(~nilradica@user/naso)
2022-08-28 18:04:24 +0200perrierj1(~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.6)
2022-08-28 18:04:46 +0200perrierjouet(~perrier-j@modemcable012.251-130-66.mc.videotron.ca)
2022-08-28 18:05:32 +0200splitted(~root@88.160.31.174) (Remote host closed the connection)
2022-08-28 18:06:26 +0200shapr(~user@68.54.166.125)
2022-08-28 18:07:48 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-28 18:08:21 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-28 18:08:37 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2022-08-28 18:09:35 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:361c:1634:7cfb:4544)
2022-08-28 18:14:49 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:361c:1634:7cfb:4544) (Remote host closed the connection)
2022-08-28 18:14:55 +0200koala_man(~vidar@157.146.251.23.bc.googleusercontent.com)
2022-08-28 18:15:07 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:bfb4:5236:6588:c29c)
2022-08-28 18:21:01 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 244 seconds)
2022-08-28 18:26:25 +0200olle(~olle@h-94-254-63-12.NA.cust.bahnhof.se) ()
2022-08-28 18:27:52 +0200nilradical(~nilradica@user/naso) ()
2022-08-28 18:34:26 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 18:34:45 +0200alternateved(~user@staticline-31-183-146-203.toya.net.pl) (Remote host closed the connection)
2022-08-28 18:36:38 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2022-08-28 18:36:49 +0200nate4(~nate@98.45.169.16)
2022-08-28 18:39:09 +0200toeffel(~toeffel@user/toeffel) (Ping timeout: 252 seconds)
2022-08-28 18:40:50 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2022-08-28 18:41:26 +0200jakalx(~jakalx@base.jakalx.net) ()
2022-08-28 18:43:27 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
2022-08-28 18:43:37 +0200jmd_(~jmdaemon@user/jmdaemon)
2022-08-28 18:44:19 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 248 seconds)
2022-08-28 18:44:35 +0200waleee(~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340)
2022-08-28 18:45:39 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:bfb4:5236:6588:c29c) (Remote host closed the connection)
2022-08-28 18:45:57 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:906a:4715:8c98:d126)
2022-08-28 18:48:31 +0200jakalx(~jakalx@base.jakalx.net)
2022-08-28 18:54:18 +0200toeffel(~toeffel@user/toeffel)
2022-08-28 18:54:51 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds)
2022-08-28 18:59:19 +0200tzh(~tzh@c-24-21-73-154.hsd1.or.comcast.net)
2022-08-28 19:04:27 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 252 seconds)
2022-08-28 19:06:15 +0200econo(uid147250@user/econo)
2022-08-28 19:09:42 +0200dwt_(~dwt_@c-98-198-103-176.hsd1.tx.comcast.net)
2022-08-28 19:12:27 +0200shapr(~user@68.54.166.125) (Ping timeout: 268 seconds)
2022-08-28 19:12:28 +0200vglfr(~vglfr@145.224.94.78) (Read error: Connection reset by peer)
2022-08-28 19:13:05 +0200vglfr(~vglfr@145.224.94.78)
2022-08-28 19:15:55 +0200geekosaur(~geekosaur@xmonad/geekosaur) (Quit: Leaving)
2022-08-28 19:16:00 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-28 19:16:28 +0200yvan-sraka(~yvan-srak@2a02:2788:224:71c:906a:4715:8c98:d126) (Remote host closed the connection)
2022-08-28 19:18:23 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-28 19:18:39 +0200n8chan(~nate@98.45.169.16)
2022-08-28 19:19:19 +0200nate4(~nate@98.45.169.16)
2022-08-28 19:21:05 +0200neightchan(~nate@98.45.169.16) (Ping timeout: 268 seconds)
2022-08-28 19:21:40 +0200beteigeuze(~Thunderbi@bl11-28-222.dsl.telepac.pt)
2022-08-28 19:22:21 +0200notzmv(~zmv@user/notzmv) (Ping timeout: 268 seconds)
2022-08-28 19:25:50 +0200mbuf(~Shakthi@122.165.55.71) (Quit: Leaving)
2022-08-28 19:27:07 +0200geekosaur(~geekosaur@xmonad/geekosaur)
2022-08-28 19:27:53 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2022-08-28 19:29:09 +0200shriekingnoise(~shrieking@186.137.167.202)
2022-08-28 19:30:32 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
2022-08-28 19:30:46 +0200jao-(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 19:31:04 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f) (Quit: Konversation terminated!)
2022-08-28 19:31:44 +0200shriekingnoise(~shrieking@186.137.167.202) (Remote host closed the connection)
2022-08-28 19:33:54 +0200shriekingnoise(~shrieking@186.137.167.202)
2022-08-28 19:34:02 +0200AlexZenon_2(~alzenon@178.34.163.186) (Ping timeout: 268 seconds)
2022-08-28 19:34:02 +0200Alex_test_(~al_test@178.34.163.186) (Ping timeout: 268 seconds)
2022-08-28 19:35:46 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 19:37:39 +0200vglfr(~vglfr@145.224.94.78) (Ping timeout: 248 seconds)
2022-08-28 19:39:18 +0200razetime(~quassel@117.254.35.219) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2022-08-28 19:40:14 +0200Alex_test(~al_test@178.34.163.186)
2022-08-28 19:40:19 +0200AlexZenon(~alzenon@178.34.163.186)
2022-08-28 19:41:44 +0200nate4(~nate@98.45.169.16) (Ping timeout: 255 seconds)
2022-08-28 19:43:14 +0200nate4(~nate@98.45.169.16)
2022-08-28 19:45:21 +0200jmd_(~jmdaemon@user/jmdaemon) (Quit: ZNC 1.8.2 - https://znc.in)
2022-08-28 19:49:11 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-28 19:51:27 +0200opqdonut_opqdonut
2022-08-28 19:52:56 +0200Luj(~Luj@2a01:e0a:5f9:9681:8b11:280b:5dc6:2dbd) (Quit: The Lounge - https://thelounge.chat)
2022-08-28 19:55:01 +0200coot(~coot@213.134.176.158)
2022-08-28 19:55:54 +0200lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 20:00:33 +0200nate4(~nate@98.45.169.16) (Ping timeout: 252 seconds)
2022-08-28 20:02:39 +0200Luj(~Luj@2a01:e0a:5f9:9681:193b:902c:4a27:b473)
2022-08-28 20:04:54 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
2022-08-28 20:10:06 +0200eikke(~NicolasT@user/NicolasT)
2022-08-28 20:10:51 +0200rburkholder(~blurb@96.45.2.121)
2022-08-28 20:11:51 +0200nate4(~nate@98.45.169.16)
2022-08-28 20:16:05 +0200vglfr(~vglfr@145.224.94.75)
2022-08-28 20:21:27 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
2022-08-28 20:21:56 +0200notzmv(~zmv@user/notzmv)
2022-08-28 20:23:11 +0200beteigeuze1(~Thunderbi@bl11-28-222.dsl.telepac.pt)
2022-08-28 20:24:02 +0200beteigeuze(~Thunderbi@bl11-28-222.dsl.telepac.pt) (Read error: Connection reset by peer)
2022-08-28 20:24:02 +0200beteigeuze1beteigeuze
2022-08-28 20:26:11 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 248 seconds)
2022-08-28 20:28:19 +0200zeenk(~zeenk@2a02:2f04:a311:2d00:6865:d863:4c93:799f)
2022-08-28 20:36:26 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2022-08-28 20:36:58 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 268 seconds)
2022-08-28 20:39:11 +0200Lord_of_Life_Lord_of_Life
2022-08-28 20:54:54 +0200radhika(uid560836@id-560836.helmsley.irccloud.com) (Quit: Connection closed for inactivity)
2022-08-28 20:57:56 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2022-08-28 20:58:00 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:3570:6165:e2af:8564)
2022-08-28 21:00:01 +0200aeka`(~aeka@2606:6080:2001:6:e14e:c3f3:8562:6916)
2022-08-28 21:00:16 +0200aeka(~aeka@2606:6080:2001:9:2679:addd:655:8142) (Ping timeout: 260 seconds)
2022-08-28 21:00:23 +0200aeka`aeka
2022-08-28 21:03:41 +0200gustik(~gustik@2a01:c844:2457:2220:475d:34f:d571:996f) (Quit: Leaving)
2022-08-28 21:04:24 +0200toeffel(~toeffel@user/toeffel) (Quit: quit)
2022-08-28 21:05:12 +0200mikoto-chan(~mikoto-ch@164.5.249.78)
2022-08-28 21:09:42 +0200gurkenglas(~gurkengla@p548ac72e.dip0.t-ipconnect.de)
2022-08-28 21:12:36 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
2022-08-28 21:13:09 +0200zxx7529(~Thunderbi@user/zxx7529) (Ping timeout: 252 seconds)
2022-08-28 21:13:27 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2022-08-28 21:13:54 +0200wonko(~wjc@2a0e:1c80:2::130)
2022-08-28 21:14:28 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net)
2022-08-28 21:14:37 +0200 <segfaultfizzbuzz> what is a "spine-nonstrict data structure" -- someone said that anynoe experienced with haskell knows to avoid these
2022-08-28 21:14:50 +0200 <segfaultfizzbuzz> so as to not have space leaks
2022-08-28 21:15:11 +0200mikoto-chan(~mikoto-ch@164.5.249.78) (Ping timeout: 268 seconds)
2022-08-28 21:15:49 +0200 <c_wraith> well that's obviously a false assertion
2022-08-28 21:15:58 +0200 <c_wraith> as a spine-strict list would cause a lot of space leaks
2022-08-28 21:15:59 +0200 <segfaultfizzbuzz> heh ok
2022-08-28 21:16:00 +0200 <geekosaur> who is "someone"?
2022-08-28 21:16:11 +0200 <segfaultfizzbuzz> some forum post
2022-08-28 21:16:17 +0200 <segfaultfizzbuzz> no idea who
2022-08-28 21:16:36 +0200 <segfaultfizzbuzz> what does spine-strict or spine-nonstrict
2022-08-28 21:16:38 +0200 <c_wraith> the thing is, you need to actually think about evaluation patterns. any "always X" is wrong
2022-08-28 21:17:05 +0200 <geekosaur> anyway a spine-nonstrict data structure is one in which the association between individual components is not strict. so for a list, it's the tail that links list elements together (and is nonstrict)
2022-08-28 21:17:14 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-08-28 21:17:32 +0200 <geekosaur> trees are also often nonstrict. this is usually a good thing as it permits sharing
2022-08-28 21:17:42 +0200 <segfaultfizzbuzz> sharing between threads?
2022-08-28 21:18:13 +0200 <c_wraith> the saving grace for thinking about evaluation patterns is that there are patterns which if applied locally consistently result in good global behavior.
2022-08-28 21:18:14 +0200 <geekosaur> no. if I change a given node in a tree, only the parent nodes need to be copied; child nodes can be shared
2022-08-28 21:18:32 +0200 <geekosaur> \(between the modified tree and the original)
2022-08-28 21:18:45 +0200kannon(~NK@135-180-47-54.fiber.dynamic.sonic.net) (Ping timeout: 244 seconds)
2022-08-28 21:18:48 +0200 <segfaultfizzbuzz> i see
2022-08-28 21:19:31 +0200axeman_(~quassel@net-93-65-246-244.cust.vodafonedsl.it) (Ping timeout: 260 seconds)
2022-08-28 21:19:44 +0200 <geekosaur> whereas if it's stricyt it would force copying of the entire tree to update a single node
2022-08-28 21:19:50 +0200 <geekosaur> *strict
2022-08-28 21:19:59 +0200 <c_wraith> I... don't think that's the same thing
2022-08-28 21:20:06 +0200 <dolio> Yeah, that's not true.
2022-08-28 21:20:21 +0200 <segfaultfizzbuzz> it seems like as you write down lines of code the probability that one line depends on some other line goes up quite rapidly over time--there is a "mixing coefficient" and it trends upwards
2022-08-28 21:20:21 +0200 <davean> segfaultfizzbuzz: they're crazy - you USUALLY want spine lazy
2022-08-28 21:20:58 +0200 <segfaultfizzbuzz> granted with functional programming you can try to minimize, control, and limit the growth of this mixing coefficient
2022-08-28 21:21:05 +0200 <c_wraith> there's a certain cargo cult of strictness in Haskell, though. You see a lot of bad advice out of them.
2022-08-28 21:21:41 +0200 <davean> people don't get what non-strictness means and things like liveness and persistence and sharing ...
2022-08-28 21:21:56 +0200 <davean> and they think in general strictness increases computational efficience which is very wrong
2022-08-28 21:22:38 +0200 <segfaultfizzbuzz> i think my primary reason for being strictness-oriented is fear
2022-08-28 21:22:52 +0200 <geekosaur> that may apply to most of the strictness cabal
2022-08-28 21:22:56 +0200Sgeo(~Sgeo@user/sgeo)
2022-08-28 21:23:03 +0200 <davean> segfaultfizzbuzz: so to get to the actual question, "spine-lazy" usually goes along with strict leaves
2022-08-28 21:23:05 +0200 <segfaultfizzbuzz> and my second reason is that it seems like if a block of code has a high mixing coefficient then strictness seems like it would make sense, at least for that block
2022-08-28 21:23:24 +0200 <geekosaur> that, and looking for simplistic ways out of having to actually understand their code
2022-08-28 21:23:30 +0200 <c_wraith> What you actually should do is learn how evaluation works in Haskell. It's a completely different approach than most languages, but it is logical and predictable.
2022-08-28 21:23:30 +0200 <davean> in that the local actual components often are more efficient to be computed promptly, but the overall structure is what gets shared and can limit control flow of other parts of the program
2022-08-28 21:23:40 +0200 <davean> and also what has to go with the useful parts of liveness control
2022-08-28 21:23:44 +0200 <segfaultfizzbuzz> c_wraith: yeah i am kind of in the middle of that, [exa] had been helping me
2022-08-28 21:24:12 +0200 <davean> c_wraith: its ... predictable? I mean SORTA technically, for a given compiler, but like its REALLY hard to predict for GHC.
2022-08-28 21:24:15 +0200 <davean> c_wraith: I mean in specific
2022-08-28 21:24:23 +0200 <davean> but I also care about the very precise details often
2022-08-28 21:24:32 +0200 <davean> because I'm often targetting assembly optimal output
2022-08-28 21:25:14 +0200 <segfaultfizzbuzz> davean: yeah i'm unlikely to ever understand code at the level of assembly, it is far far too complex
2022-08-28 21:25:34 +0200mikoto-chan(~mikoto-ch@164.5.249.78)
2022-08-28 21:25:40 +0200 <segfaultfizzbuzz> i am very aware that my primate brain is very limited so i just want the necessary and most powerful abstractions
2022-08-28 21:25:50 +0200 <c_wraith> I will say that RULES pragmas tend to break reasonability. And the full laziness transform is probably a mistake. If people want that result, they should just write that code.
2022-08-28 21:26:47 +0200 <c_wraith> GHC does too much magic to allow bad code to perform well, and sometimes it messes up good code.
2022-08-28 21:28:43 +0200acidjnk(~acidjnk@p200300d6e7137a4628adea4619d717ec.dip0.t-ipconnect.de)
2022-08-28 21:28:55 +0200 <davean> segfaultfizzbuzz: assembly is the MOST trivial
2022-08-28 21:29:12 +0200 <davean> segfaultfizzbuzz: its hard to write things in because its SO SIMPLE
2022-08-28 21:29:19 +0200 <davean> there is almost nothing to understand at all
2022-08-28 21:29:43 +0200 <davean> c_wraith: The full laziness transform is the only thing that really causes me issues ever
2022-08-28 21:30:01 +0200mima(mmh@gateway/vpn/airvpn/mima) (Ping timeout: 260 seconds)
2022-08-28 21:30:27 +0200 <davean> c_wraith: I just fought with it the other day, where duplicating a line of code (with a TINY fmap) took the compute time from 15 seconds in 10MiB to 100s of GiBs and OOM hours later
2022-08-28 21:30:39 +0200michalz(~michalz@185.246.204.75)
2022-08-28 21:30:44 +0200 <c_wraith> yeah, it's a rough one. It makes your code do something other than what you actually wrote.
2022-08-28 21:30:50 +0200 <c_wraith> If you wrote it that way for a reason....
2022-08-28 21:30:50 +0200 <segfaultfizzbuzz> davean: i mean okay you say that but there are like a zillion instructions and then consider their interactions and soforth, it's impossible
2022-08-28 21:30:52 +0200 <davean> and convincing GHC it was WRONG AND IT MUST NOT DO THAT was super annoying
2022-08-28 21:31:04 +0200 <davean> segfaultfizzbuzz: No, they *don't* interact
2022-08-28 21:31:20 +0200 <segfaultfizzbuzz> ever, in any context?
2022-08-28 21:31:25 +0200 <davean> segfaultfizzbuzz: and there are like 20 main ones, they have procedurally defined variation and then there are a few hundred specialized ones you can mostly ignore
2022-08-28 21:31:35 +0200 <davean> segfaultfizzbuzz: Yes, definitionally
2022-08-28 21:31:42 +0200 <davean> segfaultfizzbuzz: Assembly is too simple for any interactions at all
2022-08-28 21:31:42 +0200 <segfaultfizzbuzz> i think i know maybe eight instructions and i don't have the judgement to know which others are worth knowing
2022-08-28 21:31:44 +0200 <c_wraith> They certainly interact in edge cases. setting the FP mode, for instance.
2022-08-28 21:32:00 +0200 <davean> c_wraith: no, they set registers
2022-08-28 21:32:08 +0200 <davean> c_wraith: the instructions work directly from the register state
2022-08-28 21:32:28 +0200 <davean> theres no interaction between instructions, its all the register sets and it has nothing to do with the previsious instructions
2022-08-28 21:32:51 +0200 <davean> so every instruction can be analyized in complete isolation from what came befor
2022-08-28 21:33:14 +0200 <segfaultfizzbuzz> right but then there are lots of registers and you have to thnik about how an earlier instruction can impact a subsequent one
2022-08-28 21:33:23 +0200Pickchea(~private@user/pickchea)
2022-08-28 21:33:34 +0200 <c_wraith> I suppose very technically, that's true. But without complete visibility into contents of registers you might think never get touched, you can end up mistaking function.
2022-08-28 21:33:39 +0200 <davean> segfaultfizzbuzz: depends on the architecture, but there really aren't many, and most of them are the same specification for register
2022-08-28 21:33:51 +0200 <segfaultfizzbuzz> aren't there like 60 or something on x86
2022-08-28 21:33:57 +0200 <davean> theres like the control register, the IP, the FP, and then some general purpose ones. one general purpose one is often
2022-08-28 21:33:57 +0200 <segfaultfizzbuzz> i forget the number, but it isn't small
2022-08-28 21:34:05 +0200 <davean> "special" in that its teh default hard coded into some instructions
2022-08-28 21:34:14 +0200 <davean> segfaultfizzbuzz: They're almost all identical
2022-08-28 21:34:14 +0200 <c_wraith> x86 is kind of a worst-case for understandability. :P
2022-08-28 21:34:26 +0200 <segfaultfizzbuzz> and mov means copy lol
2022-08-28 21:34:29 +0200 <davean> x86 is kinda the worst case, but even there MOST of those registers are copy paste
2022-08-28 21:34:34 +0200 <darkling> If you have trouble with x86 assembly, try ARM. That's much nicer.
2022-08-28 21:35:15 +0200 <davean> segfaultfizzbuzz: and futher, MOST of THOSE 60ish registers are vector registers and not relivent to almost all code
2022-08-28 21:35:30 +0200 <davean> segfaultfizzbuzz: so even THAT claim is basicly meaningless in practice, even if they weren't copy and paste
2022-08-28 21:35:49 +0200 <davean> and even beyond that only like 4 have a special meaning thats relivent
2022-08-28 21:36:23 +0200 <davean> Honestly you could probably learn enough assembly to write basic integer programs in an 8 hour work day
2022-08-28 21:36:49 +0200 <segfaultfizzbuzz> probably you have spent hundreds of hours staring at assembly so it is familiar to you but even if i could somehow determine which instructions were worth paying attention to it is very unlikely that i would reach fluency
2022-08-28 21:36:56 +0200 <darkling> It's very very tedious, though...
2022-08-28 21:37:04 +0200 <segfaultfizzbuzz> and i also feel skeptical that programmers can defeat computers for much longer
2022-08-28 21:37:07 +0200 <davean> darkling: extremely tedious
2022-08-28 21:37:40 +0200 <segfaultfizzbuzz> we are maybe ten or twenty years away from programming ending up like the go board game, i think
2022-08-28 21:37:41 +0200 <davean> segfaultfizzbuzz: I wrote my first assembly program in under 6 hours - I happen to know because it was a game dev project back when I was first starting game dev in 1998 and I had to make it to school :-p
2022-08-28 21:38:07 +0200 <darkling> I tried the Advent of Code last year in Z80 assembler. I got to about day 4. :/
2022-08-28 21:38:23 +0200 <davean> segfaultfizzbuzz: really you're just scared
2022-08-28 21:38:37 +0200 <davean> segfaultfizzbuzz: ignorance generates fear
2022-08-28 21:39:04 +0200 <davean> You've built it up as some mythical beast, you haven't actually gone "Ok, what do I actually need to know to do X"
2022-08-28 21:39:27 +0200 <segfaultfizzbuzz> davean: partially that, partially it's that i intentionally avoid learning things which deteriorate in their value,... x86 has held up much better over time than i projected
2022-08-28 21:39:50 +0200 <segfaultfizzbuzz> i think that if itanium or whatever had taken off my point might have been more salient
2022-08-28 21:40:21 +0200 <davean> segfaultfizzbuzz: The thing is all assemblies are the same, it doesn't matter which you learn, they follow a principal and almost any language you learn educates you more about programming
2022-08-28 21:40:28 +0200 <davean> segfaultfizzbuzz: I programmed Itanium too
2022-08-28 21:40:35 +0200 <davean> In 2003
2022-08-28 21:40:41 +0200 <segfaultfizzbuzz> davean: there are probably some more fundamental things, ... and i think, so probably this has to do with the speed of light
2022-08-28 21:40:56 +0200 <davean> that was the hardest assembly I ever learned, it took like 2 days to get sufficient to be compitent, but I wasn't able to beat compilers
2022-08-28 21:41:04 +0200 <segfaultfizzbuzz> probably the speed of light means that a program is always about some kind of spatially local state
2022-08-28 21:41:11 +0200 <darkling> davean: I can think of at least two architectures that are very different at the assembly level to things like x86 or ARM, but those are pretty much dead and gone. :)
2022-08-28 21:41:28 +0200 <segfaultfizzbuzz> and so therefore something like a CPU is "inevitable"
2022-08-28 21:41:37 +0200 <davean> darkling: A few, but even like a dataflow processor is actually fairly similar
2022-08-28 21:41:54 +0200 <davean> darkling: Honestly, in a way a VLIW is the "most" different I've ever actually seen
2022-08-28 21:41:58 +0200 <davean> since it requires different thinking
2022-08-28 21:42:05 +0200 <segfaultfizzbuzz> i've also heard that we use CPU rather than FPGA for compute because FPGA layout is slow
2022-08-28 21:42:18 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
2022-08-28 21:42:26 +0200Midjak(~Midjak@82.66.147.146) (Quit: This computer has gone to sleep)
2022-08-28 21:42:27 +0200 <davean> segfaultfizzbuzz: You seem to hear a lot instead of learn a lot ;)
2022-08-28 21:42:35 +0200 <darkling> The CM-1 and CM-2 were one-bit processors runinng in parallel. No registers at all.
2022-08-28 21:42:41 +0200 <davean> darkling: I've seen those
2022-08-28 21:42:50 +0200 <davean> I know people who worked on those
2022-08-28 21:43:03 +0200 <segfaultfizzbuzz> uh, well the speed of light was my observation, but the FPGA thing is not
2022-08-28 21:43:04 +0200 <davean> By which I mean on the design of them
2022-08-28 21:43:11 +0200 <darkling> And the Transputer had a stack.
2022-08-28 21:43:14 +0200 <davean> segfaultfizzbuzz: yes, I'm talking about the FPGA thing
2022-08-28 21:43:29 +0200 <davean> darkling: oh lots of assemblies are stack based
2022-08-28 21:43:31 +0200 <monochrom> w00t transputer
2022-08-28 21:43:37 +0200 <davean> thats not really different than registers
2022-08-28 21:43:38 +0200 <darkling> Itanium was register-based, but you had to spend extra work on sequencing and combining the instructions into the VLIW.
2022-08-28 21:43:42 +0200 <segfaultfizzbuzz> davean: the question here partially is, is this whole concept of registers and assembly and cache hierarchy and whatnot physically inevitable
2022-08-28 21:43:56 +0200 <davean> segfaultfizzbuzz: Even a stack is effectively registers
2022-08-28 21:44:05 +0200 <segfaultfizzbuzz> right, local state
2022-08-28 21:44:26 +0200 <davean> a stack is a variable number of "real" registers, which is abstracted over
2022-08-28 21:44:33 +0200 <segfaultfizzbuzz> register, stack, cache are eskimo words for spatially localized state
2022-08-28 21:45:04 +0200 <davean> segfaultfizzbuzz: A specific sort really
2022-08-28 21:45:25 +0200 <segfaultfizzbuzz> so there is localized state, there is sequentiality, and then there is some kind of irreducible mixing
2022-08-28 21:46:03 +0200 <davean> darkling: I will say that there is a weird similarity between dataflow systems and VLIW
2022-08-28 21:46:05 +0200 <monochrom> Local state is probably inevitable. Note that sometimes it is encoded as control points.
2022-08-28 21:46:19 +0200 <davean> segfaultfizzbuzz: the thing is if you learned Itanium it would have been useful - what do you think modern GPUs look like?
2022-08-28 21:46:32 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Remote host closed the connection)
2022-08-28 21:46:33 +0200 <segfaultfizzbuzz> what is a control point
2022-08-28 21:46:40 +0200 <segfaultfizzbuzz> davean: lol gpus are itanium? haha
2022-08-28 21:46:48 +0200 <davean> segfaultfizzbuzz: They're VLIQW
2022-08-28 21:46:51 +0200 <monochrom> For example "I'm at line 10".
2022-08-28 21:46:52 +0200 <c_wraith> well, they're massively data parallel
2022-08-28 21:46:52 +0200 <davean> *VLIW
2022-08-28 21:47:02 +0200 <davean> c_wraith: very specificly they're VLIW
2022-08-28 21:47:19 +0200 <monochrom> For example program counter.
2022-08-28 21:47:45 +0200ddellacosta(~ddellacos@143.244.47.77)
2022-08-28 21:48:41 +0200 <davean> c_wraith: I mean they're also a weird VLIW sometimes
2022-08-28 21:49:05 +0200 <segfaultfizzbuzz> davean: well i will complain a bit that we still aren't referencing a paper or proving that this whole approach is inevitable
2022-08-28 21:49:55 +0200 <segfaultfizzbuzz> we might imagine an FPGA which could be reprogrammed extraordinarily quickly (after every clock or something) or other ways of doing things
2022-08-28 21:50:27 +0200 <davean> segfaultfizzbuzz: they tend to wear out.
2022-08-28 21:50:31 +0200 <davean> depending on the design
2022-08-28 21:50:37 +0200 <monochrom> If you change the circuit every clock cycle, I will then just declare that the circuit is your local state.
2022-08-28 21:50:37 +0200 <davean> you don't want too many rewrite cycles.
2022-08-28 21:50:45 +0200 <davean> But infact there was a design that did that for temporal locality
2022-08-28 21:51:03 +0200 <monochrom> In the same way if your program counter changes every clock cycle, that's your local state.
2022-08-28 21:51:54 +0200 <segfaultfizzbuzz> there is a compelling argument that we need to be using electrons, albeit there are some very new developments in photonics which may decrease the size advantage gap,...
2022-08-28 21:52:01 +0200 <monochrom> Indeed "program counter" is an index to an array of circuits.
2022-08-28 21:54:06 +0200 <segfaultfizzbuzz> davean: so is there a blog post on your 20 instructions of importance?
2022-08-28 21:54:26 +0200 <davean> segfaultfizzbuzz: I will say programming OoO assembly and VLIW assembly has taught me SPECIFICLY why spine-lazy is a good datastructure approach often
2022-08-28 21:54:38 +0200 <monochrom> In general, I'm pretty sure the Church-Turing thesis already implies you must have local state or encoding thereof.
2022-08-28 21:54:38 +0200 <segfaultfizzbuzz> oh wow okay so this is a very sophisticated question then
2022-08-28 21:54:38 +0200 <davean> segfaultfizzbuzz: oh no, most assembly tutorials handle that
2022-08-28 21:54:55 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
2022-08-28 21:55:07 +0200 <segfaultfizzbuzz> i mean i read an introduction to riscv once
2022-08-28 21:56:15 +0200 <segfaultfizzbuzz> davean: since you seem to really understand performance i have an embarassingly bad question
2022-08-28 21:57:12 +0200 <davean> I have about 5 more minutes
2022-08-28 21:57:27 +0200 <segfaultfizzbuzz> which is that the (cringey, i know) programming language shootout normally has not that many problems to solve but it seems like haskell should have a better showing there if it wants to live up to its claims (10% of C),... plus not uncommonly there is some compilation flaw
2022-08-28 21:57:57 +0200 <davean> oh man I don't think anyone has updated those in 15 years
2022-08-28 21:58:02 +0200 <davean> since BOS was working on them
2022-08-28 21:58:17 +0200 <monochrom> Yeah they now have real-world real jobs.
2022-08-28 21:58:17 +0200 <segfaultfizzbuzz> yeah, so, maybe someone should do that? :-P
2022-08-28 21:58:28 +0200 <dolio> Why, though?
2022-08-28 21:58:35 +0200 <davean> No one cares
2022-08-28 21:58:42 +0200 <segfaultfizzbuzz> lol ok
2022-08-28 21:58:48 +0200 <segfaultfizzbuzz> haskell wants to be unknown
2022-08-28 21:58:51 +0200 <davean> I could make something cool, or update someone else's out of date toy test case
2022-08-28 21:59:01 +0200 <[exa]> it's a test, takes out people who believe random stuff on the internet
2022-08-28 21:59:08 +0200 <davean> segfaultfizzbuzz: last I knew it was generally better than most of the options on there but I haven't looked in years
2022-08-28 21:59:14 +0200 <segfaultfizzbuzz> i mean, haskell is also random stuff on the internet lol
2022-08-28 21:59:37 +0200 <davean> segfaultfizzbuzz: If you look at the code for those, many of the languages aren't *actually* doing the same thing
2022-08-28 21:59:45 +0200 <davean> its not a senible comparison to start with
2022-08-28 21:59:50 +0200 <segfaultfizzbuzz> yeah there is a lot of false comparison
2022-08-28 21:59:57 +0200jao(~jao@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net)
2022-08-28 22:00:00 +0200 <davean> some to some degree its a game of how infidelious (sp?) you're willing to be
2022-08-28 22:00:13 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
2022-08-28 22:00:15 +0200 <segfaultfizzbuzz> what we don't have a good way of measuring is "idiomatic speed"
2022-08-28 22:00:25 +0200 <segfaultfizzbuzz> which is how much domain knowledge/special stuff you need to know to go fast
2022-08-28 22:00:40 +0200 <davean> man I haven't used "infidelious" as a word in a long time, glad I didn't butcher that
2022-08-28 22:00:43 +0200 <segfaultfizzbuzz> hahah
2022-08-28 22:00:45 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-28 22:00:57 +0200 <davean> segfaultfizzbuzz: honestly one thing I've learned with Haskell is that there is a HUGE spectrum of "idiomatic speed" in Haskell
2022-08-28 22:01:01 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-28 22:01:04 +0200 <dolio> Even if all the examples were up to date and accurate, the premise leads people to make stupid decisions.
2022-08-28 22:01:04 +0200 <darkling> Sounds like a character from some minor Opera Buffa. :)
2022-08-28 22:01:06 +0200 <davean> Several orders of magnitude
2022-08-28 22:01:17 +0200 <dolio> Because they'll just go, "C is fastest, so everyone should use C."
2022-08-28 22:01:17 +0200 <davean> and some forms of thinking lead to space leaks and slowness and other people just never experience them
2022-08-28 22:01:39 +0200 <davean> dolio: I beat a C with Haskell for a talk ;)
2022-08-28 22:01:43 +0200 <segfaultfizzbuzz> i am not smart enough to write or read C,... i am probably also not smart enough to read or write haskell but at least it follows some rules
2022-08-28 22:01:51 +0200 <davean> (now I'm being a little infidelious but not too badly)
2022-08-28 22:02:14 +0200 <monochrom> In idiomatic C, people do not use proper data structures. If they need a priority queue, they just put things in an array in arbitrary order and then do linear search every time.
2022-08-28 22:02:23 +0200 <segfaultfizzbuzz> haha
2022-08-28 22:02:37 +0200 <[exa]> that approach is underrated
2022-08-28 22:02:37 +0200 <segfaultfizzbuzz> because it's so fast that you don't have to write good code
2022-08-28 22:02:41 +0200justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 244 seconds)
2022-08-28 22:02:49 +0200 <dolio> Because, for example, they haven't taken monochrom's class, and learned that most people are really bad at writing C, so they shouldn't.
2022-08-28 22:02:52 +0200 <davean> [exa]: that approach is optimal for small n :-p
2022-08-28 22:02:57 +0200 <monochrom> You can probably even see that in the Linux kernel for many past versions.
2022-08-28 22:03:22 +0200 <[exa]> yeah, surprisingly most people's n is small
2022-08-28 22:03:30 +0200 <segfaultfizzbuzz> davean: yeah, i can tell from your most recent statement that you actually do know how to code :^)
2022-08-28 22:03:30 +0200 <davean> [exa]: its about judgement, sometimes that is what you SHOULD do, and knowing when to do that vs. the complicated version is what seperates the compitent from the incompitent
2022-08-28 22:04:12 +0200 <[exa]> davean: yeah (or simply account for programmer time spent nerding about the best algorithm :D )
2022-08-28 22:04:14 +0200 <darkling> If you've only got three items, bubble sort is going to be pretty fast and simple...
2022-08-28 22:04:30 +0200 <darkling> If you've got a million items, it'd be a disaster.
2022-08-28 22:04:51 +0200 <davean> darkling: right which is why almost all sort implimentations switch short algs when the n gets small
2022-08-28 22:04:55 +0200 <monochrom> But I learned that from the code library that the U of Waterloo team brought to the ACM programming contests. Recall that U of Waterloo consistently places like the top 5 or even top 3.
2022-08-28 22:04:59 +0200 <davean> (including on the specific sub problem)
2022-08-28 22:05:18 +0200 <davean> monochrom: learned what specificly?\
2022-08-28 22:05:18 +0200 <monochrom> And considering that the ACM programming contests give you large n's.
2022-08-28 22:05:32 +0200 <segfaultfizzbuzz> okay so if i can ask a very boring practical question about strictness/laziness and fear:
2022-08-28 22:05:44 +0200 <davean> I'm a bit out of my 5 minutes
2022-08-28 22:05:51 +0200 <davean> I'm sure other people can help you though :)
2022-08-28 22:05:53 +0200 <segfaultfizzbuzz> davean: that's fine thanks for the input :-)
2022-08-28 22:05:56 +0200 <monochrom> That when you need a priority queue for Dijkstra's shortest path, you just throw things an an array and do linear search every time.
2022-08-28 22:06:18 +0200 <monochrom> Or perhaps s/you/they/
2022-08-28 22:06:40 +0200 <segfaultfizzbuzz> so suppose someone is writing a rest backend which updates a database
2022-08-28 22:06:47 +0200 <segfaultfizzbuzz> or talks to a database i should say
2022-08-28 22:07:07 +0200 <monochrom> Although, I think I heard that at some point the Linux kernel changelog also had "we finally use a real priority queue".
2022-08-28 22:07:20 +0200 <segfaultfizzbuzz> the rest backend must respond to each command in full
2022-08-28 22:08:02 +0200 <segfaultfizzbuzz> it would be too stressfull to think about a rest query which hangs around un-evaluated in part while other rest commands do their thing
2022-08-28 22:08:38 +0200 <segfaultfizzbuzz> so at some top level there is some kind of per-request strictness mandate
2022-08-28 22:08:42 +0200 <geekosaur> if it must respond in full then it'll force evaluation
2022-08-28 22:09:00 +0200 <segfaultfizzbuzz> and then,... won't that almost always bubble all the way down?
2022-08-28 22:09:24 +0200 <segfaultfizzbuzz> like you might make an individual rest command faster or terminate for more cases or whatever, but
2022-08-28 22:10:11 +0200 <[exa]> segfaultfizzbuzz: the queries are usually some kind of IO actions, not really simple to have them hanging around unevaluated. You eitehr run the IO or not.
2022-08-28 22:10:14 +0200 <segfaultfizzbuzz> you can't like visit amazon.com and have your query hanging around for an hour while their backend decides that it can't yet justify evaluating your entire query, right?
2022-08-28 22:10:37 +0200 <geekosaur> IO forces evaluation, in general
2022-08-28 22:10:57 +0200 <geekosaur> laziness comes in when for example some part of the query isn't relevant to the result
2022-08-28 22:11:10 +0200 <geekosaur> so it won't be evaluated
2022-08-28 22:11:18 +0200 <segfaultfizzbuzz> right, i can make sense of query-internal laziness
2022-08-28 22:11:28 +0200 <segfaultfizzbuzz> but "exterior" laziness makes me quiver with fear
2022-08-28 22:11:38 +0200 <[exa]> that's the right reaction IMO
2022-08-28 22:11:43 +0200 <geekosaur> that's just silly
2022-08-28 22:11:50 +0200 <geekosaur> hm, is it?
2022-08-28 22:11:59 +0200 <[exa]> and that's why you don't unsafePerformIO
2022-08-28 22:12:01 +0200matthewmosior(~matthewmo@173.170.253.91) (Ping timeout: 260 seconds)
2022-08-28 22:12:17 +0200 <geekosaur> right, unsafePerformIO is another question
2022-08-28 22:12:23 +0200 <segfaultfizzbuzz> because unsafePerformIO can cause the evaluation to be postponed?
2022-08-28 22:12:50 +0200 <geekosaur> because it does an IO evaluation lazily instead of letting the IO force evaluation
2022-08-28 22:13:08 +0200 <[exa]> yeah, it's one of the easiest ways to have strictness/laziness exhibit external actions
2022-08-28 22:13:17 +0200 <geekosaur> because unsafePerformIO makes a strict IO operation look like a lazy operation
2022-08-28 22:14:14 +0200 <[exa]> and while it has uses (Debug.Trace afaik?), I'd sanely choose to have stuff organized in actual production code
2022-08-28 22:14:47 +0200 <geekosaur> Debug.Trace, yes. where a large part of the point is showing when something is lazily evaluated
2022-08-28 22:15:15 +0200 <geekosaur> by doing the IO at that point instead of the IO strictifying evaluation
2022-08-28 22:16:59 +0200beteigeuze1(~Thunderbi@bl11-28-222.dsl.telepac.pt)
2022-08-28 22:17:22 +0200lortabac(~lortabac@2a01:e0a:541:b8f0:3570:6165:e2af:8564) (Quit: WeeChat 2.8)
2022-08-28 22:17:30 +0200 <[exa]> segfaultfizzbuzz: in short, you don't need to worry-- all externally visible actions (except timing etc.) are written in a strict DSL (the IO monad) unless you decide to explicitly break it, with your own consequences
2022-08-28 22:17:43 +0200beteigeuze(~Thunderbi@bl11-28-222.dsl.telepac.pt) (Read error: Connection reset by peer)
2022-08-28 22:17:43 +0200beteigeuze1beteigeuze
2022-08-28 22:18:06 +0200 <qrpnxz> all IO is lazy, it just so happens that that the dependency chain of the subsequent continuations passed to >>= makes them happen in order once the action is needed (main is forced)
2022-08-28 22:18:46 +0200 <qrpnxz> in other words, if you never make main depend on an IO action, it doesn't happen
2022-08-28 22:19:33 +0200 <qrpnxz> so i wouldn't say that unsafePerformIO makes an action any lazier with that respect
2022-08-28 22:22:02 +0200 <Hecate> lazy IO is the work of the Devil
2022-08-28 22:22:13 +0200 <dolio> No it isn't.
2022-08-28 22:22:14 +0200 <qrpnxz> that's another kind of lazy IO 😃
2022-08-28 22:22:21 +0200 <qrpnxz> and i do avoid it at all costs
2022-08-28 22:22:29 +0200 <Hecate> qrpnxz: ;-D
2022-08-28 22:22:53 +0200ten_finger_typis(~ten_finge@adsl-84-226-91-51.adslplus.ch)
2022-08-28 22:23:00 +0200 <geekosaur> let's just say anyting designated "unsafe" is so designated for a reason
2022-08-28 22:23:33 +0200 <geekosaur> this includes things that are based on unsafeInterleaveIO (and are typically regarded as "lazy I/O")
2022-08-28 22:24:03 +0200 <qrpnxz> unsafeInterleaveIO is pretend play IO. You set up all these dependency chains for nothing because the IO happens whenever it bloody wants
2022-08-28 22:24:10 +0200matthewmosior(~matthewmo@173.170.253.91)
2022-08-28 22:24:17 +0200 <Hecate> qrpnxz: btw, I'm interested in your usage of effectful
2022-08-28 22:24:24 +0200 <qrpnxz> Hecate: oh?
2022-08-28 22:24:26 +0200 <qrpnxz> what's up
2022-08-28 22:24:31 +0200 <segfaultfizzbuzz> anyway i think the thing that makes me the most nervous about laziness is that my mission-critical rest backend might fail to complete evaluation of a rest command or a certain command might cause a space leak which is otherwise not visible
2022-08-28 22:24:38 +0200 <Hecate> qrpnxz: I'm co-maintainer and avid user, so I'm interested in you as a user :)
2022-08-28 22:24:46 +0200 <qrpnxz> ah! :)
2022-08-28 22:24:59 +0200 <qrpnxz> i'm having fun with it.
2022-08-28 22:25:08 +0200 <Hecate> kewl
2022-08-28 22:25:25 +0200 <geekosaur> segfaultfizzbuzz, if it has to respond and that response depends on evaluation then it will complete evaluation
2022-08-28 22:25:33 +0200jakalx(~jakalx@base.jakalx.net) (Error from remote client)
2022-08-28 22:25:38 +0200 <qrpnxz> It just makes me so happy honestly, because it makes reality that old idea of "have an effect for different IO things without having to use IO everywhere and it actually composes"
2022-08-28 22:25:42 +0200 <Hecate> qrpnxz: fun fact, I replaced a DataKind affixed to a Session type by an effect in the stack, in Flora
2022-08-28 22:25:59 +0200 <Hecate> qrpnxz: oh yeah it's beautiful
2022-08-28 22:26:03 +0200 <segfaultfizzbuzz> it might be nice if there was some way to have per-action memory pressure
2022-08-28 22:26:32 +0200 <segfaultfizzbuzz> so i could say, here is 64MB for a rest command, become more strict the closer you get to 64MB
2022-08-28 22:26:39 +0200 <geekosaur> space leaks are more complicated but boil down to letting too many things pile up until the response forces them. whether this happens or not, or even matters, depends on what you're doing
2022-08-28 22:26:54 +0200 <qrpnxz> Hecate: what is Flora?
2022-08-28 22:27:31 +0200 <ten_finger_typis> I am trying to understand a bit more about unsafeCoerce. It is safe, if the two types have the same representation, but what about GADTs like lists or Maybe. Is the following safe or can it give an incorrect result for some list?
2022-08-28 22:27:32 +0200 <ten_finger_typis> f :: [a] -> Int
2022-08-28 22:27:32 +0200 <ten_finger_typis> f x = length (unsafeCoerce x :: [()])
2022-08-28 22:28:09 +0200 <qrpnxz> that use would not be safe, you don't know that `a` has same rep as ()
2022-08-28 22:28:11 +0200 <monochrom> qrpnxz: I used unsafeInterleaveIO to develope a joke unsafeInterleaveIO-passing style :)
2022-08-28 22:28:19 +0200 <Hecate> qrpnxz: good question: https://github.com/flora-pm/flora-server/wiki/What-is-Flora
2022-08-28 22:28:19 +0200 <qrpnxz> lol
2022-08-28 22:28:37 +0200Topsi(~Topsi@dyndsl-095-033-090-077.ewe-ip-backbone.de) (Read error: Connection reset by peer)
2022-08-28 22:28:46 +0200 <ten_finger_typis> @qr
2022-08-28 22:28:46 +0200 <lambdabot> Maybe you meant: wn v url src rc pl id do bf arr @ ? .
2022-08-28 22:28:52 +0200 <qrpnxz> oh interesting
2022-08-28 22:29:55 +0200 <qrpnxz> ten_finger_typis: this would be allowed: f x = length (fmap (unsafeCoerce :: _ -> Any) x)
2022-08-28 22:29:57 +0200 <ten_finger_typis> @qrpnxz but does that actually matter in this case?
2022-08-28 22:29:57 +0200 <lambdabot> Unknown command, try @list
2022-08-28 22:30:01 +0200 <monochrom> That one is safe, although why bother, length is already polymorphic.
2022-08-28 22:30:22 +0200 <qrpnxz> unsafeCoerce, and worse unsafeCoerce#, are good ways to segfault a normally unbreakable haskell program
2022-08-28 22:30:23 +0200 <qrpnxz> so watch out
2022-08-28 22:30:41 +0200 <ten_finger_typis> yes ;-)
2022-08-28 22:30:42 +0200 <qrpnxz> monochrom: yeah lol
2022-08-28 22:31:13 +0200 <ten_finger_typis> good advice using that fmap to Any
2022-08-28 22:31:14 +0200 <monochrom> Wait, a normally unbreakable program shouldn't be affected.
2022-08-28 22:31:28 +0200jakalx(~jakalx@base.jakalx.net)
2022-08-28 22:31:38 +0200pavonia(~user@user/siracusa)
2022-08-28 22:31:38 +0200 <monochrom> It is the nomrally rejected program that gets accepted and then segfaults.
2022-08-28 22:32:04 +0200 <monochrom> Although, maybe you define unbreakable to include unrunnable.
2022-08-28 22:32:17 +0200 <qrpnxz> i mean a program you would have written properly, but instead did something crazy with unsafe. Sprinkling unsafeCoerce in an already sane program shouldn't do anything yes
2022-08-28 22:32:28 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2022-08-28 22:32:31 +0200 <monochrom> Oh, that.
2022-08-28 22:32:39 +0200 <ten_finger_typis> What about this?
2022-08-28 22:32:39 +0200 <ten_finger_typis> f x = length (unsafeCoerce :: [(Any)])
2022-08-28 22:32:43 +0200 <ten_finger_typis> What about this?
2022-08-28 22:32:43 +0200 <ten_finger_typis> f x = length (unsafeCoerce :: [(Any)])
2022-08-28 22:32:47 +0200 <ten_finger_typis> What about this?
2022-08-28 22:32:48 +0200 <ten_finger_typis> f x = length (unsafeCoerce x :: [(Any)])
2022-08-28 22:33:20 +0200 <monochrom> The representation of the spine of [X] is independent of X.
2022-08-28 22:33:24 +0200 <qrpnxz> i would think unsafe coerce of [a] to [Any] should be okay, but i've not seen documentation particularly blessing that
2022-08-28 22:33:35 +0200bitdex_(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 268 seconds)
2022-08-28 22:33:52 +0200 <monochrom> So in the eyes of length, which only cares about the spine, you can make it [X] or [Y] or [Any].
2022-08-28 22:34:17 +0200vglfr(~vglfr@145.224.94.75) (Read error: Connection reset by peer)
2022-08-28 22:34:26 +0200 <monochrom> Although, I haven't checked what happens when there is also fusion.
2022-08-28 22:34:29 +0200vglfr(~vglfr@145.224.94.75)
2022-08-28 22:35:04 +0200 <qrpnxz> good question
2022-08-28 22:35:18 +0200goepsilongo(~goepsilon@2806:101e:9:5045:107a:c190:12f7:570c) (Quit: Textual IRC Client: www.textualapp.com)
2022-08-28 22:35:33 +0200 <qrpnxz> however length is implemented it would ignore the element (it's poly so it can't do anything with it) so i would think fusion doesn't change anything
2022-08-28 22:35:48 +0200 <monochrom> I think it doesn't break fusion. Or rather, fusion doesn't break my model.
2022-08-28 22:36:26 +0200 <monochrom> Yeah, that.
2022-08-28 22:36:33 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-28 22:36:59 +0200 <ten_finger_typis> For context, I have been playing around with existential types,
2022-08-28 22:37:02 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-28 22:37:12 +0200 <ten_finger_typis> data A = forall a . Typeable a => A a
2022-08-28 22:37:13 +0200 <ten_finger_typis> listLength :: A -> Maybe Int
2022-08-28 22:37:13 +0200 <ten_finger_typis> listLength (A a)
2022-08-28 22:37:14 +0200 <ten_finger_typis>   | App con _ <- R.typeOf a
2022-08-28 22:37:14 +0200 <monochrom> "Safe unsafeCoerce for Free! A Sequel to Theorems for Free!"
2022-08-28 22:37:14 +0200 <ten_finger_typis>   , Just HRefl <- con `eqTypeRep` R.typeRep @[]
2022-08-28 22:37:15 +0200 <ten_finger_typis>   = Just $ length (unsafeCoerce a :: [()])
2022-08-28 22:37:15 +0200 <ten_finger_typis>   | True
2022-08-28 22:37:16 +0200 <ten_finger_typis>   = Nothing
2022-08-28 22:37:28 +0200 <geekosaur> @where paste
2022-08-28 22:37:28 +0200 <lambdabot> Help us help you: please paste full code, input and/or output at e.g. https://paste.tomsmeding.com
2022-08-28 22:37:40 +0200coot(~coot@213.134.176.158) (Quit: coot)
2022-08-28 22:37:42 +0200 <geekosaur> please don't just blat code into the channel
2022-08-28 22:37:51 +0200 <ten_finger_typis> sorry, thanks for the link
2022-08-28 22:38:00 +0200chexum(~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection)
2022-08-28 22:38:18 +0200chexum(~quassel@gateway/tor-sasl/chexum)
2022-08-28 22:39:09 +0200 <qrpnxz> "coerce: theorems for less" "unsafeCoerce: freer theorems" "unsafeCoerce#: theorems gives you their wallet!"
2022-08-28 22:39:52 +0200 <monochrom> Sounds like "shut up and take my money" :)
2022-08-28 22:40:41 +0200 <qrpnxz> Hecate: since you say you are co-mantainer, I'll bring up a PR i just made... https://github.com/haskell-effectful/effectful/pull/94 :)
2022-08-28 22:41:20 +0200 <hpc> qrpnxz: if the program has no semantics, it has no bugs either
2022-08-28 22:41:38 +0200 <qrpnxz> unfortunately also no features :(
2022-08-28 22:41:42 +0200 <monochrom> But every program has semantics.
2022-08-28 22:41:54 +0200 <monochrom> But you could s/semantics/specification
2022-08-28 22:41:57 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-28 22:41:58 +0200 <qrpnxz> "it's supposed to segfault!"
2022-08-28 22:42:15 +0200 <[exa]> "the code is the specification!!!"
2022-08-28 22:42:29 +0200 <qrpnxz> amen
2022-08-28 22:42:36 +0200 <monochrom> This is why I keep my expectations low.
2022-08-28 22:42:41 +0200 <[exa]> :]
2022-08-28 22:42:41 +0200 <ten_finger_typis> so in the `listLength` functionabove the `fmap unsafeCoerce` would not wok because the type in the list would be ambiguous
2022-08-28 22:43:00 +0200 <qrpnxz> Any is specifically made so that anything can be unsafeCoerced into it
2022-08-28 22:43:34 +0200 <monochrom> If you present a glass half-filled with water, some see it as half-empty, some others see it as half-full. I see "at least there is a glass".
2022-08-28 22:43:46 +0200 <ten_finger_typis> yes, and that extends to thinks like [X] = [Any]
2022-08-28 22:43:48 +0200 <ten_finger_typis> ?
2022-08-28 22:43:51 +0200 <darkling> But it's clearly twice the size it needs to be.
2022-08-28 22:44:02 +0200 <monochrom> haha
2022-08-28 22:44:03 +0200 <qrpnxz> i don't make that assumption generally, but i would think likely
2022-08-28 22:44:40 +0200 <ten_finger_typis> thanks
2022-08-28 22:44:41 +0200 <qrpnxz> fmap is definitely okay, not fmapping is probably okay. I'm team definitely okay, personally.
2022-08-28 22:45:09 +0200 <segfaultfizzbuzz> if i write assembly "in haskell" can haskell still limit the damage i do?
2022-08-28 22:45:28 +0200 <qrpnxz> idk what writing assembly in haskell looks like
2022-08-28 22:45:40 +0200 <segfaultfizzbuzz> so for example if i have a haskell function mapping FooType to BarType
2022-08-28 22:46:06 +0200 <segfaultfizzbuzz> can i put assembly "on the interior" of that function ?
2022-08-28 22:46:37 +0200mima(mmh@gateway/vpn/airvpn/mima)
2022-08-28 22:46:50 +0200 <Hecate> qrpnxz: I saw it :) But at this level I have to defer to Andrzej
2022-08-28 22:46:57 +0200 <qrpnxz> 👍
2022-08-28 22:46:57 +0200 <Hecate> and also I'm flying abroad like tomorrow
2022-08-28 22:47:16 +0200 <qrpnxz> business or pleasure?
2022-08-28 22:47:20 +0200 <Hecate> vacations!
2022-08-28 22:47:24 +0200 <qrpnxz> yay!
2022-08-28 22:47:26 +0200 <monochrom> Perhaps you can s/asm/C/ and investigate first what happens when Haskell calls a C function.
2022-08-28 22:47:26 +0200 <Hecate> so, cruelly needed
2022-08-28 22:47:27 +0200 <segfaultfizzbuzz> and be guaranteed that, worst case is that i mangle the map from FooType to BarType, rather than cause my inkjet printer to demand ink
2022-08-28 22:47:48 +0200 <segfaultfizzbuzz> monochrom: ok
2022-08-28 22:47:58 +0200 <qrpnxz> if "asm in haskell" is like "C in haskell", then you should be able to break the rules and launch nukes
2022-08-28 22:48:05 +0200 <Hecate> qrpnxz: btw, we're always interested in experience feedbacks, so don't hesitate to publish a post / tweet / post on Reddit about your experience with Effectful
2022-08-28 22:48:06 +0200 <monochrom> But we already know the answer, don't we? Haskell does not limit the damage of foreign functions.
2022-08-28 22:48:13 +0200 <qrpnxz> you have to make the choice and tag with IO or not an extern call
2022-08-28 22:48:28 +0200 <qrpnxz> Hecate: 👍 will consider
2022-08-28 22:49:15 +0200 <segfaultfizzbuzz> so maybe FFI is the wrong way to "do asm in haskell"
2022-08-28 22:49:16 +0200 <monochrom> As for causing an inkjet printer to demand ink, isn't that the job of an OS?
2022-08-28 22:49:34 +0200 <monochrom> Err I mean the job of an OS to stop that.
2022-08-28 22:49:35 +0200 <segfaultfizzbuzz> monochrom: i was making a joke in lieu of "launch nukes"
2022-08-28 22:49:36 +0200 <qrpnxz> i think CUPS is userspace :)
2022-08-28 22:50:04 +0200 <ten_finger_typis> qrpnxz: I do not know how I could get fmap to work in that example
2022-08-28 22:50:07 +0200 <segfaultfizzbuzz> qrpnxz: lol
2022-08-28 22:50:13 +0200 <qrpnxz> i like launch nukes because that's how bad it could hypothetically be xD
2022-08-28 22:50:33 +0200 <segfaultfizzbuzz> i am more afraid of printer ink
2022-08-28 22:50:35 +0200 <qrpnxz> ten_finger_typis: idk what you mean by how. Does it not type check?
2022-08-28 22:50:51 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2022-08-28 22:51:11 +0200 <monochrom> What is with this obsession with length (unsafeCoerse xs)?
2022-08-28 22:51:13 +0200 <qrpnxz> segfaultfizzbuzz: tbh if my printer just started printing a bunch of all black pages none stop i'd freak out and get quite irate xD
2022-08-28 22:51:26 +0200kannon(~NK@108-216-157-82.lightspeed.sntcca.sbcglobal.net)
2022-08-28 22:51:31 +0200 <segfaultfizzbuzz> qrpnxz: so you agree xD
2022-08-28 22:51:45 +0200 <qrpnxz> i can't say that's worse than nukes, but it pretty bad
2022-08-28 22:51:48 +0200 <qrpnxz> :)
2022-08-28 22:52:01 +0200 <qrpnxz> monochrom: maybe the length is 42 :)
2022-08-28 22:52:12 +0200 <segfaultfizzbuzz> yeah on a log scale it's like only one step worse
2022-08-28 22:52:19 +0200 <qrpnxz> xD
2022-08-28 22:52:23 +0200 <monochrom> No no no.
2022-08-28 22:52:37 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl)
2022-08-28 22:52:57 +0200 <monochrom> If you waste ink, it runs you into debt, you'll be miserable.
2022-08-28 22:53:07 +0200 <monochrom> If you launch nuke, all your debts are over.
2022-08-28 22:53:26 +0200 <segfaultfizzbuzz> monochrom: btw if i search for hakell c ffi i get a guide to a method which "is discouraged" https://wiki.haskell.org/Foreign_Function_Interface
2022-08-28 22:53:49 +0200 <qrpnxz> if we amortize the printer damage caused by nukes into all other cotidian printer issues, we see that the typical printer issue is about as bad as a nuke /s
2022-08-28 22:54:18 +0200 <monochrom> Oh, that one. It just means s/ccall/capi/ throughout the article and you'll be fine.
2022-08-28 22:54:24 +0200 <qrpnxz> lol
2022-08-28 22:54:36 +0200 <monochrom> This is what's wrong with the haskell wiki.
2022-08-28 22:54:42 +0200 <segfaultfizzbuzz> monochrom: oh ok the writing should clarify that
2022-08-28 22:54:50 +0200 <qrpnxz> feel free to edit :)
2022-08-28 22:54:51 +0200 <geekosaur> back in the day, ghc compiled haskell via c and there was no problem
2022-08-28 22:55:01 +0200 <monochrom> People are too polite to edit, no? So add a sentence instead of editing or deleting.
2022-08-28 22:55:04 +0200 <geekosaur> eventually ghc started compiling directly to asm
2022-08-28 22:55:36 +0200 <qrpnxz> and now there's even llvm backend i think
2022-08-28 22:55:40 +0200 <geekosaur> this made calling some C functions or referring to some C values mroe difficult, because they were actually C preprocessor defines
2022-08-28 22:56:08 +0200 <geekosaur> llvm still has this problem since it's not going through C any more
2022-08-28 22:56:25 +0200 <monochrom> Although, in the off chance you're still using Hugs, it doesn't have capi, you're stuck with ccall, which is the only standardized one.
2022-08-28 22:56:26 +0200 <geekosaur> so capi was developed, which makes FFI go via the C compiler instead of direct to asm
2022-08-28 22:56:33 +0200 <qrpnxz> :o
2022-08-28 22:56:39 +0200 <ten_finger_typis> wait, it looks like I do not need coerce at all, GHC knows that it's list and that's enough:  https://paste.tomsmeding.com/rzrG5Ogj
2022-08-28 22:56:42 +0200 <geekosaur> (or llvm IR)
2022-08-28 22:57:50 +0200 <monochrom> Consider the infamous errno :)
2022-08-28 22:58:24 +0200 <geekosaur> well, that's still going to be infamous 🙂
2022-08-28 22:59:15 +0200 <monochrom> Also sorry geekosaur last time I put up an unnecessary argument. On second thought I agree that capi uniformly is the better idea. Although, last time I was really whining about the haskell wiki.
2022-08-28 22:59:42 +0200 <geekosaur> yes
2022-08-28 22:59:50 +0200 <geekosaur> I just logged in and popped up the page in question
2022-08-28 23:00:05 +0200 <monochrom> Even I teach my students that even errno is not simple at all, not going to be a simple global "int errno;".
2022-08-28 23:00:08 +0200 <geekosaur> (account creation is disabled currently so there's not much segfaultfizzbuzz will be able to do)
2022-08-28 23:01:07 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2022-08-28 23:01:19 +0200 <hpc> "simple global" you say :D
2022-08-28 23:02:44 +0200 <darkling> Global variables? Just say errno.
2022-08-28 23:02:49 +0200 <monochrom> haha
2022-08-28 23:03:36 +0200 <apache2> lol monochrom, arrays?!? real C programmers just use labels and volatile stack variables
2022-08-28 23:04:19 +0200 <geekosaur> anyone want to check my changes to https://wiki.haskell.org/Foreign_Function_Interface ?
2022-08-28 23:04:25 +0200 <int-e> darkling: err... no?
2022-08-28 23:04:35 +0200 <monochrom> haha
2022-08-28 23:04:56 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-08-28 23:05:47 +0200 <apache2> also why would you need linear search
2022-08-28 23:06:12 +0200 <monochrom> Are you suggesting bogosearch instead? :)
2022-08-28 23:06:14 +0200 <apache2> the hardware already has a builtin btree
2022-08-28 23:06:30 +0200 <monochrom> Wait, that's new to me.
2022-08-28 23:06:37 +0200 <apache2> you can just use ring2 page faults
2022-08-28 23:06:38 +0200 <int-e> which hardware?
2022-08-28 23:06:43 +0200 <monochrom> Oh hahahaha
2022-08-28 23:06:46 +0200 <int-e> ah
2022-08-28 23:06:48 +0200 <apache2> amd64?
2022-08-28 23:06:49 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 268 seconds)
2022-08-28 23:06:55 +0200takuan_dozo(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2022-08-28 23:06:56 +0200 <int-e> page tables
2022-08-28 23:07:07 +0200 <int-e> not quite a btree
2022-08-28 23:07:16 +0200 <apache2> alright, close enough
2022-08-28 23:07:23 +0200 <monochrom> Next time I teach data structures I'll keep that in mind >:)
2022-08-28 23:07:40 +0200 <qrpnxz> darkling: lmao
2022-08-28 23:08:14 +0200 <qrpnxz> geekosaur: thanks for the edit
2022-08-28 23:08:22 +0200 <apache2> in idiomatic C you could use binary search though
2022-08-28 23:08:25 +0200 <int-e> monochrom: is there a constant time version of bogosearch? (pick random index, write key there, return index)
2022-08-28 23:08:30 +0200 <apache2> or skip lists; skip lists are easy in C
2022-08-28 23:08:33 +0200 <int-e> (it's definitely bogus)
2022-08-28 23:08:51 +0200 <monochrom> I thought bogo-anything is meant to take at least exponential time...
2022-08-28 23:09:00 +0200 <apache2> if search.h didn't suck so badly you could use anything in there
2022-08-28 23:09:16 +0200 <qrpnxz> int-e: that would not help because it still has to check every index, and it will still stop on exactly the same condition: needle index
2022-08-28 23:09:56 +0200 <int-e> qrpnxz: nah, it returns a valid index for the key
2022-08-28 23:10:04 +0200 <kilolympus> Does using "awaitForever yield" as a Conduit in the "conduit" library impact performance? Or is it fused away in compilation?
2022-08-28 23:10:06 +0200 <apache2> int-e you can do constant
2022-08-28 23:10:07 +0200 <qrpnxz> ?
2022-08-28 23:10:12 +0200 <apache2> n^2 inserts
2022-08-28 23:10:16 +0200 <int-e> qrpnxz: that's why it's writing the key
2022-08-28 23:10:17 +0200 <int-e> ;)
2022-08-28 23:10:23 +0200 <apache2> with n
2022-08-28 23:10:25 +0200 <int-e> it's a joke. probably a bad one.
2022-08-28 23:10:28 +0200 <apache2> lookup time
2022-08-28 23:10:35 +0200 <apache2> whoah my enter key is crapping out, sorry
2022-08-28 23:10:51 +0200 <monochrom> qrpnxz, int-e's method is known as "planting evidence" in law and law enforcement circles.
2022-08-28 23:11:01 +0200 <qrpnxz> lol
2022-08-28 23:11:38 +0200 <qrpnxz> kilolympus: i don't think there's a fusion rule for that, but if you can statically see that you are doing that... don't?
2022-08-28 23:11:56 +0200 <kilolympus> Mmmmmm good point amazing point
2022-08-28 23:11:57 +0200 <qrpnxz> and if it's dynamic that it might do that, then the rule wouldn't trigger anyway and it's okay
2022-08-28 23:12:16 +0200 <kilolympus> Thanks qrpnxz !
2022-08-28 23:12:20 +0200 <qrpnxz> 👍
2022-08-28 23:12:54 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net)
2022-08-28 23:15:22 +0200_xor(~xor@74.215.182.83) (Read error: Connection reset by peer)
2022-08-28 23:18:11 +0200segfaultfizzbuzz(~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds)
2022-08-28 23:22:14 +0200merijn(~merijn@c-001-001-007.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds)
2022-08-28 23:29:41 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2022-08-28 23:31:33 +0200kannon(~NK@108-216-157-82.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 244 seconds)
2022-08-28 23:34:59 +0200acidjnk(~acidjnk@p200300d6e7137a4628adea4619d717ec.dip0.t-ipconnect.de) (Ping timeout: 248 seconds)
2022-08-28 23:38:56 +0200ormaaj(~ormaaj@user/ormaaj) (Quit: Reconnecting)
2022-08-28 23:39:21 +0200ormaaj(~ormaaj@user/ormaaj)
2022-08-28 23:45:53 +0200 <mrianbloom> Is it possible to have a default associated type family that is applied to any type that isn't specified by another instance?
2022-08-28 23:46:26 +0200tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2022-08-28 23:49:55 +0200 <glguy> mrianbloom: you can have a default on the class that's used as the default for any instance you define
2022-08-28 23:50:35 +0200justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 255 seconds)
2022-08-28 23:51:56 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2022-08-28 23:54:40 +0200justsomeguy(~justsomeg@user/justsomeguy)
2022-08-28 23:55:50 +0200 <mrianbloom> Are there any restrictions on that, like for example this code snippet doesn't compile:
2022-08-28 23:56:09 +0200 <mrianbloom> https://www.irccloud.com/pastebin/OuX1GiPO/
2022-08-28 23:56:44 +0200michalz(~michalz@185.246.204.75) (Remote host closed the connection)
2022-08-28 23:56:47 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2022-08-28 23:56:47 +0200 <glguy> The default implementations don't get to assume that the instance uses the default associated type family
2022-08-28 23:57:00 +0200 <glguy> you'll need to assert that in the context of those default implementations
2022-08-28 23:57:21 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2022-08-28 23:57:24 +0200 <mrianbloom> Is see, with a unification constraint?
2022-08-28 23:57:34 +0200 <glguy> yeah, like this: https://hackage.haskell.org/package/generic-trie-0.3.1/docs/src/Data.GenericTrie.Internal.html#Tri…