IRCBrowse

2023/11/29

2023-11-29 00:05:21 +0100coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-11-29 00:08:36 +0100gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-11-29 00:10:15 +0100coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-11-29 00:12:50 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-11-29 00:14:38 +0100adanwan(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2023-11-29 00:21:26 +0100mengu(~mengu@c83-254-18-254.bredband.tele2.se) (Quit: Client closed)
2023-11-29 00:22:22 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 268 seconds)
2023-11-29 00:23:32 +0100L29Ah(~L29Ah@wikipedia/L29Ah)
2023-11-29 00:26:07 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 00:27:20 +0100adanwan(~adanwan@gateway/tor-sasl/adanwan)
2023-11-29 00:28:09 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 00:32:48 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 00:33:23 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 00:36:39 +0100chomwitt(~chomwitt@ppp-2-85-137-120.home.otenet.gr) (Ping timeout: 256 seconds)
2023-11-29 00:37:23 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-29 00:37:37 +0100 <meejah> if you were to build a little toy 2D game-like thing (goal: learn more haskell) on a Linux machine, which Haskell framework would you reach for right now?
2023-11-29 00:38:32 +0100 <meejah> (I'm asking here, because I want something showing "good haskell" -- i.e. sure I could use the GTK bindings, but then I'm doing "c-like gtk in haskell" approximately, it seems)
2023-11-29 00:40:31 +0100 <carter> meejah: dear im gui
2023-11-29 00:40:51 +0100 <carter> It’s dirt simple but you can make it fancy
2023-11-29 00:41:03 +0100 <carter> Or maybe I’m just ignorant at gui dev
2023-11-29 00:41:16 +0100 <jackdk> meejah: Note that whatever program you write, there's often an "imperative outer layer" which grows up around the program and then you have a core of pure data structures and functions to work out what you need to change in the imperative layer
2023-11-29 00:41:23 +0100thegeekinside(~thegeekin@189.180.53.210) (Remote host closed the connection)
2023-11-29 00:43:36 +0100 <jackdk> meejah: https://www.youtube.com/watch?v=GaorHAlUkVs is an interesting talk using some pretty high-powered tools to get performance but captures the idea pretty well
2023-11-29 00:43:45 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 00:44:36 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-11-29 00:46:16 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 00:47:10 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-11-29 00:47:17 +0100 <duncan> meejah: I have a Haskell implementation of the 'greed' game using Brick
2023-11-29 00:47:44 +0100 <duncan> Brick runs in the terminal and it is a bunch of combinators
2023-11-29 00:48:27 +0100 <meejah> thanks! (I've played a little with Brick and yeah it looks neat)
2023-11-29 00:48:37 +0100 <meejah> it's the "reactive" type thing?
2023-11-29 00:48:46 +0100 <duncan> It's not reactive
2023-11-29 00:48:52 +0100 <duncan> State is updated every so often though
2023-11-29 00:49:17 +0100 <meejah> jackdk: thanks, i'll check out the talk
2023-11-29 00:49:34 +0100 <meejah> duncan: oh, is it like monomer then? (more like model/view/controller a bit)
2023-11-29 00:49:56 +0100 <duncan> Well, it's not reactive in the same way the reactive-banana is
2023-11-29 00:50:01 +0100 <meejah> right, okay
2023-11-29 00:50:04 +0100 <duncan> But it might be given it has a state machine
2023-11-29 00:50:12 +0100emmanuelux(~emmanuelu@user/emmanuelux)
2023-11-29 00:50:25 +0100 <meejah> (yeah i meant "reactive" in that sense, like Obsidian etc )
2023-11-29 00:50:31 +0100 <duncan> https://github.com/druimalban/hgreed
2023-11-29 00:50:45 +0100 <duncan> A famous Haskeller starred the repository IIRC.
2023-11-29 00:53:51 +0100 <duncan> Oh god I think I used some recursion scheme with that
2023-11-29 00:54:01 +0100 <duncan> Probably not a great teaching tool.
2023-11-29 00:55:13 +0100 <EvanR> meejah, simple graphics library gloss has a "game" mode
2023-11-29 00:55:35 +0100 <EvanR> but you'd have to bring your own audio if you want audio
2023-11-29 00:55:36 +0100masterbuilder(~quassel@user/masterbuilder)
2023-11-29 00:57:06 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 260 seconds)
2023-11-29 00:57:25 +0100gabriel_sevecek(~gabriel@188-167-229-200.dynamic.chello.sk) (Ping timeout: 276 seconds)
2023-11-29 00:58:36 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 00:59:30 +0100 <duncan> I think it would involve a lot of wrangling with 2D graphics libraries, whereas Brick is just blitting composed together text objects to the terminal
2023-11-29 01:00:00 +0100thegeekinside(~thegeekin@189.180.53.210)
2023-11-29 01:00:18 +0100 <duncan> Also, the Brick approach using combinators is quite powerful as a teaching mechanism because learning about combinators can be applied to other stuff like parsec
2023-11-29 01:09:35 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 01:10:21 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 01:12:08 +0100shapr(~user@2600:1700:c640:3100:147b:3662:c432:30f1) (Remote host closed the connection)
2023-11-29 01:12:23 +0100shapr(~user@2600:1700:c640:3100:c355:fe3e:4f9f:d5b6)
2023-11-29 01:13:40 +0100alp_(~alp@2001:861:e3d6:8f80:1124:c998:cd66:bc03) (Ping timeout: 246 seconds)
2023-11-29 01:17:34 +0100mrmr15533(~mrmr@user/mrmr)
2023-11-29 01:18:46 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Remote host closed the connection)
2023-11-29 01:19:10 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 01:22:47 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-11-29 01:23:34 +0100 <EvanR> gloss depends on glfw-b, and opengl that's it
2023-11-29 01:24:24 +0100gabriel_sevecek(~gabriel@188-167-229-200.dynamic.chello.sk)
2023-11-29 01:25:46 +0100notzmv(~zmv@user/notzmv) (Ping timeout: 245 seconds)
2023-11-29 01:27:19 +0100Alleria(~JohnGalt@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-11-29 01:27:44 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 268 seconds)
2023-11-29 01:30:49 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 01:31:49 +0100 <EvanR> a new enough GLFW is probably in your distros package manager
2023-11-29 01:32:00 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 01:34:40 +0100misterfish(~misterfis@87.215.131.102) (Ping timeout: 255 seconds)
2023-11-29 01:37:38 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 260 seconds)
2023-11-29 01:43:06 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 01:43:11 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 01:47:47 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 260 seconds)
2023-11-29 01:49:37 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 01:50:29 +0100ames(~amelia@offtopia/offtopian/amelia) (Quit: Ping timeout (120 seconds))
2023-11-29 01:50:40 +0100ames(~amelia@offtopia/offtopian/amelia)
2023-11-29 01:51:16 +0100shailangsa(~shailangs@host109-152-9-157.range109-152.btcentralplus.com) (Read error: Connection reset by peer)
2023-11-29 01:51:29 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-29 01:51:29 +0100dumptruckman(~dumptruck@23-239-13-136.ip.linodeusercontent.com) (Remote host closed the connection)
2023-11-29 01:51:33 +0100tertek(~tertek@user/tertek) (Remote host closed the connection)
2023-11-29 01:51:39 +0100dumptruckman(~dumptruck@23-239-13-136.ip.linodeusercontent.com)
2023-11-29 01:51:54 +0100tertek(~tertek@user/tertek)
2023-11-29 01:53:53 +0100emmanuelux(~emmanuelu@user/emmanuelux) (Read error: Connection reset by peer)
2023-11-29 01:54:12 +0100targetdisk(~daemonchi@45-33-4-162.ip.linodeusercontent.com) (Ping timeout: 256 seconds)
2023-11-29 01:56:30 +0100tzh_(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-11-29 01:56:56 +0100dtman34(~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)
2023-11-29 01:57:05 +0100telser(~quassel@user/telser) (Quit: No Ping reply in 180 seconds.)
2023-11-29 01:57:17 +0100dtman34(~dtman34@c-76-156-89-180.hsd1.mn.comcast.net)
2023-11-29 01:57:43 +0100 <meejah> EvanR: thanks
2023-11-29 01:57:55 +0100fun-safe-math(~fun-safe-@c-24-21-106-247.hsd1.or.comcast.net) (Quit: No Ping reply in 180 seconds.)
2023-11-29 01:58:10 +0100raym(~ray@user/raym) (Ping timeout: 256 seconds)
2023-11-29 01:58:44 +0100kaol(~kaol@94-237-42-30.nl-ams1.upcloud.host) (Ping timeout: 256 seconds)
2023-11-29 01:58:50 +0100Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-11-29 01:59:18 +0100 <meejah> ah, i have looked at gloss before. definitely like the "pitch" / paragraph on hackage :) (and so I want Graphics.Gloss.Interface.IO.Game is what you're saying ...)
2023-11-29 01:59:50 +0100emmanuelux(~emmanuelu@user/emmanuelux)
2023-11-29 02:00:10 +0100 <meejah> ahh, BitmapSection sounds good too
2023-11-29 02:01:00 +0100tzh(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Ping timeout: 256 seconds)
2023-11-29 02:01:06 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 02:01:37 +0100fun-safe-math(~fun-safe-@c-24-21-106-247.hsd1.or.comcast.net)
2023-11-29 02:02:23 +0100telser(~quassel@user/telser)
2023-11-29 02:04:02 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (*.net *.split)
2023-11-29 02:04:02 +0100yahb2(~yahb2@static.56.27.47.78.clients.your-server.de) (*.net *.split)
2023-11-29 02:04:02 +0100troydm(~troydm@user/troydm) (*.net *.split)
2023-11-29 02:04:02 +0100tremon(~tremon@83.80.159.219) (*.net *.split)
2023-11-29 02:04:02 +0100arahael(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (*.net *.split)
2023-11-29 02:04:03 +0100caef^(~cd@c-98-242-74-66.hsd1.ga.comcast.net) (*.net *.split)
2023-11-29 02:04:03 +0100ridcully(~ridcully@p57b52dae.dip0.t-ipconnect.de) (*.net *.split)
2023-11-29 02:04:03 +0100nek0(~nek0@2a01:4f8:222:2b41::12) (*.net *.split)
2023-11-29 02:04:03 +0100John_Ivan(~John_Ivan@user/john-ivan/x-1515935) (*.net *.split)
2023-11-29 02:04:03 +0100benjaminl(~benjaminl@user/benjaminl) (*.net *.split)
2023-11-29 02:04:03 +0100teqwve(teqwve@2a01:4f8:c2c:e5b0::1) (*.net *.split)
2023-11-29 02:04:03 +0100Luj(~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb) (*.net *.split)
2023-11-29 02:04:03 +0100inedia(~irc@23.153.248.82) (*.net *.split)
2023-11-29 02:04:03 +0100steew(~steew@user/steew) (*.net *.split)
2023-11-29 02:04:03 +0100turlando(~turlando@user/turlando) (*.net *.split)
2023-11-29 02:04:03 +0100bramhaag7(~bramhaag@endeavour.server.bramh.me) (*.net *.split)
2023-11-29 02:04:03 +0100rncwnd(~quassel@2a01:4f8:221:27c6::1) (*.net *.split)
2023-11-29 02:04:04 +0100m1dnight(~christoph@78-22-4-67.access.telenet.be) (*.net *.split)
2023-11-29 02:04:04 +0100p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (*.net *.split)
2023-11-29 02:04:04 +0100cawfee_(~root@2406:3003:2077:2758::babe) (*.net *.split)
2023-11-29 02:04:04 +0100V(~v@ircpuzzles/2022/april/winner/V) (*.net *.split)
2023-11-29 02:04:04 +0100dyniec(~dyniec@dybiec.info) (*.net *.split)
2023-11-29 02:04:04 +0100arkeet(~arkeet@moriya.ca) (*.net *.split)
2023-11-29 02:04:04 +0100codedmart(codedmart@2600:3c01::f03c:92ff:fefe:8511) (*.net *.split)
2023-11-29 02:04:04 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (*.net *.split)
2023-11-29 02:04:04 +0100noctux1(Hfi6K5vcqP@user/noctux) (*.net *.split)
2023-11-29 02:04:05 +0100dunj3(~dunj3@kingdread.de) (*.net *.split)
2023-11-29 02:04:05 +0100defanor(~defanor@tart.uberspace.net) (*.net *.split)
2023-11-29 02:04:05 +0100dminuoso_(~dminuoso@user/dminuoso) (*.net *.split)
2023-11-29 02:04:05 +0100Yumemi_(~Yumemi@2001:bc8:47a0:1b14::1) (*.net *.split)
2023-11-29 02:04:05 +0100erisco(~erisco@d24-141-66-165.home.cgocable.net) (*.net *.split)
2023-11-29 02:04:05 +0100SoF(~skius@user/skius) (*.net *.split)
2023-11-29 02:04:05 +0100Xe(~cadey@perl/impostor/xe) (*.net *.split)
2023-11-29 02:04:05 +0100sudden(~cat@user/sudden) (*.net *.split)
2023-11-29 02:04:05 +0100nicole(ilbelkyr@libera/staff/ilbelkyr) (*.net *.split)
2023-11-29 02:04:05 +0100blackfield(~aenima@85.255.4.218) (*.net *.split)
2023-11-29 02:04:05 +0100cross(~cross@spitfire.i.gajendra.net) (*.net *.split)
2023-11-29 02:04:05 +0100eL_Bart0(eL_Bart0@dietunichtguten.org) (*.net *.split)
2023-11-29 02:04:06 +0100jjhoo(~jahakala@user/jjhoo) (*.net *.split)
2023-11-29 02:04:06 +0100iteratee(~kyle@162.218.222.207) (*.net *.split)
2023-11-29 02:04:28 +0100Alleria(~JohnGalt@user/alleria) (*.net *.split)
2023-11-29 02:04:28 +0100end(~end@user/end/x-0094621) (*.net *.split)
2023-11-29 02:04:28 +0100remedan(~remedan@ip-94-112-0-18.bb.vodafone.cz) (*.net *.split)
2023-11-29 02:04:28 +0100potato44(uid421314@id-421314.lymington.irccloud.com) (*.net *.split)
2023-11-29 02:04:28 +0100ubert(~Thunderbi@91.141.52.8.wireless.dyn.drei.com) (*.net *.split)
2023-11-29 02:04:29 +0100cods(~fred@tuxee.net) (*.net *.split)
2023-11-29 02:04:29 +0100dexter2(dexter@2a01:7e00::f03c:91ff:fe86:59ec) (*.net *.split)
2023-11-29 02:04:29 +0100feetwind(~mike@user/feetwind) (*.net *.split)
2023-11-29 02:04:29 +0100incertia(~incertia@209.122.137.252) (*.net *.split)
2023-11-29 02:04:29 +0100swistak-(~swistak@185.21.216.141) (*.net *.split)
2023-11-29 02:04:29 +0100meinside(uid24933@id-24933.helmsley.irccloud.com) (*.net *.split)
2023-11-29 02:04:29 +0100nrr_______(sid20938@id-20938.lymington.irccloud.com) (*.net *.split)
2023-11-29 02:04:29 +0100hamess_(~hamess@user/hamess) (*.net *.split)
2023-11-29 02:04:29 +0100ft(~ft@p508db3bc.dip0.t-ipconnect.de) (*.net *.split)
2023-11-29 02:04:29 +0100nckx(~nckx@libera/staff/owl/nckx) (*.net *.split)
2023-11-29 02:04:29 +0100Pozyomka(~pyon@user/pyon) (*.net *.split)
2023-11-29 02:04:30 +0100connrs(~connrs@user/connrs) (*.net *.split)
2023-11-29 02:04:30 +0100kraftwerk28(~kraftwerk@164.92.219.160) (*.net *.split)
2023-11-29 02:04:30 +0100xsarnik(xsarnik@lounge.fi.muni.cz) (*.net *.split)
2023-11-29 02:04:30 +0100pieguy128(~pieguy128@bras-base-mtrlpq5031w-grc-49-67-70-103-21.dsl.bell.ca) (*.net *.split)
2023-11-29 02:04:30 +0100davetapley(sid666@uxbridge.irccloud.com) (*.net *.split)
2023-11-29 02:04:30 +0100koala_man(~vidar@157.146.251.23.bc.googleusercontent.com) (*.net *.split)
2023-11-29 02:04:30 +0100pointlessslippe1(~pointless@212.82.82.3) (*.net *.split)
2023-11-29 02:04:30 +0100lbseale(~quassel@user/ep1ctetus) (*.net *.split)
2023-11-29 02:04:30 +0100ggVGc(~ggVGc@a.lowtech.earth) (*.net *.split)
2023-11-29 02:04:31 +0100NiKaN(sid385034@id-385034.helmsley.irccloud.com) (*.net *.split)
2023-11-29 02:04:31 +0100gaze_____(sid387101@helmsley.irccloud.com) (*.net *.split)
2023-11-29 02:04:31 +0100conjunctive(sid433686@helmsley.irccloud.com) (*.net *.split)
2023-11-29 02:04:31 +0100tomku(~tomku@user/tomku) (*.net *.split)
2023-11-29 02:04:31 +0100dsrt^(~cd@c-98-242-74-66.hsd1.ga.comcast.net) (*.net *.split)
2023-11-29 02:04:31 +0100nisstyre(wes@user/nisstyre) (*.net *.split)
2023-11-29 02:04:31 +0100hamster(~ham@user/ham) (*.net *.split)
2023-11-29 02:04:31 +0100vgtw(~vgtw@user/vgtw) (*.net *.split)
2023-11-29 02:04:31 +0100Deide(d0130db69a@user/deide) (*.net *.split)
2023-11-29 02:04:31 +0100mhatta(~mhatta@www21123ui.sakura.ne.jp) (*.net *.split)
2023-11-29 02:04:31 +0100g00gler(uid125351@id-125351.uxbridge.irccloud.com) (*.net *.split)
2023-11-29 02:04:31 +0100Katarushisu1(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (*.net *.split)
2023-11-29 02:04:31 +0100AlexNoo(~AlexNoo@178.34.151.29) (*.net *.split)
2023-11-29 02:04:31 +0100komikat(~akshitkr@218.185.248.66) (*.net *.split)
2023-11-29 02:04:32 +0100shriekingnoise(~shrieking@186.137.175.87) (*.net *.split)
2023-11-29 02:04:32 +0100oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (*.net *.split)
2023-11-29 02:04:32 +0100xff0x(~xff0x@ai096045.d.east.v6connect.net) (*.net *.split)
2023-11-29 02:04:32 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (*.net *.split)
2023-11-29 02:04:32 +0100andjjj23_(~irc@107.170.228.47) (*.net *.split)
2023-11-29 02:04:32 +0100bliminse(~bliminse@user/bliminse) (*.net *.split)
2023-11-29 02:04:32 +0100motherfsck(~motherfsc@user/motherfsck) (*.net *.split)
2023-11-29 02:04:32 +0100TheCatCollective(NyaaTheKit@user/calculuscat) (*.net *.split)
2023-11-29 02:04:33 +0100Logio(em@kapsi.fi) (*.net *.split)
2023-11-29 02:04:33 +0100tomboy64(~tomboy64@user/tomboy64) (*.net *.split)
2023-11-29 02:04:33 +0100leeb(~leeb@tk2-243-31079.vs.sakura.ne.jp) (*.net *.split)
2023-11-29 02:04:33 +0100doyougnu(~doyougnu@45.46.170.68) (*.net *.split)
2023-11-29 02:04:33 +0100koz(~koz@121.99.240.58) (*.net *.split)
2023-11-29 02:04:33 +0100Maxdamantus(~Maxdamant@user/maxdamantus) (*.net *.split)
2023-11-29 02:04:33 +0100tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (*.net *.split)
2023-11-29 02:04:33 +0100hc(~hc@mail.hce.li) (*.net *.split)
2023-11-29 02:04:34 +0100Arsen(arsen@gentoo/developer/managarm.dev.Arsen) (*.net *.split)
2023-11-29 02:04:34 +0100dibblego(~dibblego@haskell/developer/dibblego) (*.net *.split)
2023-11-29 02:04:34 +0100hueso(~root@user/hueso) (*.net *.split)
2023-11-29 02:04:34 +0100benmachine(bm380@pip.srcf.societies.cam.ac.uk) (*.net *.split)
2023-11-29 02:04:34 +0100_________(~nobody@user/noodly) (*.net *.split)
2023-11-29 02:04:34 +0100pie_(~pie_bnc@user/pie/x-2818909) (*.net *.split)
2023-11-29 02:04:34 +0100tertek(~tertek@user/tertek) (*.net *.split)
2023-11-29 02:04:34 +0100dumptruckman(~dumptruck@23-239-13-136.ip.linodeusercontent.com) (*.net *.split)
2023-11-29 02:04:34 +0100Sgeo(~Sgeo@user/sgeo) (*.net *.split)
2023-11-29 02:04:35 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f) (*.net *.split)
2023-11-29 02:04:35 +0100infinity0(~infinity0@pwned.gg) (*.net *.split)
2023-11-29 02:04:35 +0100haasn`(~nand@haasn.dev) (*.net *.split)
2023-11-29 02:04:35 +0100TMA(tma@twin.jikos.cz) (*.net *.split)
2023-11-29 02:04:35 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (*.net *.split)
2023-11-29 02:04:35 +0100andreas303(andreas303@is.drunk.and.ready-to.party) (*.net *.split)
2023-11-29 02:04:35 +0100srk(~sorki@user/srk) (*.net *.split)
2023-11-29 02:04:35 +0100[exa](~exa@user/exa/x-3587197) (*.net *.split)
2023-11-29 02:04:35 +0100mulk(~mulk@p5b2dc93f.dip0.t-ipconnect.de) (*.net *.split)
2023-11-29 02:04:36 +0100chessai(sid225296@id-225296.lymington.irccloud.com) (*.net *.split)
2023-11-29 02:04:36 +0100astra(sid289983@user/amish) (*.net *.split)
2023-11-29 02:04:36 +0100bjs(sid190364@user/bjs) (*.net *.split)
2023-11-29 02:04:36 +0100shawwwn(sid6132@id-6132.helmsley.irccloud.com) (*.net *.split)
2023-11-29 02:04:36 +0100actioninja(~actioninj@user/actioninja) (*.net *.split)
2023-11-29 02:04:36 +0100son0p(~ff@181.136.122.143) (*.net *.split)
2023-11-29 02:04:36 +0100driib(~driib@vmi931078.contaboserver.net) (*.net *.split)
2023-11-29 02:04:36 +0100Buggys(Buggys@shelltalk.net) (*.net *.split)
2023-11-29 02:04:36 +0100mankyKitty(sid31287@id-31287.helmsley.irccloud.com) (*.net *.split)
2023-11-29 02:04:37 +0100riatre(~quassel@2001:310:6000:f::5198:1) (*.net *.split)
2023-11-29 02:04:37 +0100CAT_S(apic@brezn3.muc.ccc.de) (*.net *.split)
2023-11-29 02:04:37 +0100paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com) (*.net *.split)
2023-11-29 02:04:37 +0100duncan(~duncan@nat-server.ehlab.uk) (*.net *.split)
2023-11-29 02:04:38 +0100Lord_of_Life_Lord_of_Life
2023-11-29 02:05:57 +0100dsrt^(~cd@c-98-242-74-66.hsd1.ga.comcast.net)
2023-11-29 02:06:13 +0100caef^(~cd@c-98-242-74-66.hsd1.ga.comcast.net)
2023-11-29 02:06:33 +0100AlexNoo(~AlexNoo@178.34.151.29)
2023-11-29 02:06:33 +0100komikat(~akshitkr@218.185.248.66)
2023-11-29 02:06:33 +0100shriekingnoise(~shrieking@186.137.175.87)
2023-11-29 02:06:33 +0100oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl)
2023-11-29 02:06:33 +0100xff0x(~xff0x@ai096045.d.east.v6connect.net)
2023-11-29 02:06:33 +0100andjjj23_(~irc@107.170.228.47)
2023-11-29 02:06:33 +0100bliminse(~bliminse@user/bliminse)
2023-11-29 02:06:33 +0100motherfsck(~motherfsc@user/motherfsck)
2023-11-29 02:06:33 +0100TheCatCollective(NyaaTheKit@user/calculuscat)
2023-11-29 02:06:33 +0100Logio(em@kapsi.fi)
2023-11-29 02:06:33 +0100tomboy64(~tomboy64@user/tomboy64)
2023-11-29 02:06:33 +0100leeb(~leeb@tk2-243-31079.vs.sakura.ne.jp)
2023-11-29 02:06:33 +0100doyougnu(~doyougnu@45.46.170.68)
2023-11-29 02:06:33 +0100koz(~koz@121.99.240.58)
2023-11-29 02:06:33 +0100Maxdamantus(~Maxdamant@user/maxdamantus)
2023-11-29 02:06:33 +0100tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-11-29 02:06:33 +0100hc(~hc@mail.hce.li)
2023-11-29 02:06:33 +0100Arsen(arsen@gentoo/developer/managarm.dev.Arsen)
2023-11-29 02:06:33 +0100dibblego(~dibblego@haskell/developer/dibblego)
2023-11-29 02:06:33 +0100hueso(~root@user/hueso)
2023-11-29 02:06:33 +0100benmachine(bm380@pip.srcf.societies.cam.ac.uk)
2023-11-29 02:06:33 +0100_________(~nobody@user/noodly)
2023-11-29 02:06:33 +0100pie_(~pie_bnc@user/pie/x-2818909)
2023-11-29 02:06:36 +0100targetdi1k(~daemonchi@45-33-4-162.ip.linodeusercontent.com)
2023-11-29 02:06:36 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-11-29 02:06:36 +0100teqwve(teqwve@2a01:4f8:c2c:e5b0::1)
2023-11-29 02:06:36 +0100yahb2(~yahb2@static.56.27.47.78.clients.your-server.de)
2023-11-29 02:06:36 +0100troydm(~troydm@user/troydm)
2023-11-29 02:06:36 +0100arahael(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net)
2023-11-29 02:06:36 +0100ridcully(~ridcully@p57b52dae.dip0.t-ipconnect.de)
2023-11-29 02:06:36 +0100nek0(~nek0@2a01:4f8:222:2b41::12)
2023-11-29 02:06:36 +0100John_Ivan(~John_Ivan@user/john-ivan/x-1515935)
2023-11-29 02:06:36 +0100benjaminl(~benjaminl@user/benjaminl)
2023-11-29 02:06:36 +0100Luj(~Luj@2a01:e0a:5f9:9681:5880:c9ff:fe9f:3dfb)
2023-11-29 02:06:36 +0100inedia(~irc@23.153.248.82)
2023-11-29 02:06:36 +0100steew(~steew@user/steew)
2023-11-29 02:06:36 +0100turlando(~turlando@user/turlando)
2023-11-29 02:06:36 +0100bramhaag7(~bramhaag@endeavour.server.bramh.me)
2023-11-29 02:06:36 +0100rncwnd(~quassel@2a01:4f8:221:27c6::1)
2023-11-29 02:06:36 +0100m1dnight(~christoph@78-22-4-67.access.telenet.be)
2023-11-29 02:06:36 +0100p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1)
2023-11-29 02:06:36 +0100cawfee_(~root@2406:3003:2077:2758::babe)
2023-11-29 02:06:36 +0100V(~v@ircpuzzles/2022/april/winner/V)
2023-11-29 02:06:36 +0100dyniec(~dyniec@dybiec.info)
2023-11-29 02:06:36 +0100arkeet(~arkeet@moriya.ca)
2023-11-29 02:06:36 +0100codedmart(codedmart@2600:3c01::f03c:92ff:fefe:8511)
2023-11-29 02:06:36 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-11-29 02:06:36 +0100noctux1(Hfi6K5vcqP@user/noctux)
2023-11-29 02:06:36 +0100dunj3(~dunj3@kingdread.de)
2023-11-29 02:06:36 +0100defanor(~defanor@tart.uberspace.net)
2023-11-29 02:06:36 +0100dminuoso_(~dminuoso@user/dminuoso)
2023-11-29 02:06:36 +0100Yumemi_(~Yumemi@2001:bc8:47a0:1b14::1)
2023-11-29 02:06:36 +0100SoF(~skius@user/skius)
2023-11-29 02:06:36 +0100erisco(~erisco@d24-141-66-165.home.cgocable.net)
2023-11-29 02:06:36 +0100Xe(~cadey@perl/impostor/xe)
2023-11-29 02:06:36 +0100sudden(~cat@user/sudden)
2023-11-29 02:06:36 +0100nicole(ilbelkyr@libera/staff/ilbelkyr)
2023-11-29 02:06:36 +0100blackfield(~aenima@85.255.4.218)
2023-11-29 02:06:36 +0100cross(~cross@spitfire.i.gajendra.net)
2023-11-29 02:06:36 +0100jjhoo(~jahakala@user/jjhoo)
2023-11-29 02:06:36 +0100iteratee(~kyle@162.218.222.207)
2023-11-29 02:06:36 +0100molybdenum.libera.chat+v yahb2
2023-11-29 02:06:39 +0100Xe(~cadey@perl/impostor/xe) (Quit: WeeChat 4.1.0)
2023-11-29 02:06:39 +0100haskellbridge(~haskellbr@069-135-003-034.biz.spectrum.com) (Excess Flood)
2023-11-29 02:06:40 +0100pie_(~pie_bnc@user/pie/x-2818909) (Max SendQ exceeded)
2023-11-29 02:06:40 +0100_________(~nobody@user/noodly) (Max SendQ exceeded)
2023-11-29 02:06:40 +0100Arsen(arsen@gentoo/developer/managarm.dev.Arsen) (Max SendQ exceeded)
2023-11-29 02:06:44 +0100kaol_(~kaol@94-237-42-30.nl-ams1.upcloud.host)
2023-11-29 02:06:44 +0100tertek(~tertek@user/tertek)
2023-11-29 02:06:44 +0100dumptruckman(~dumptruck@23-239-13-136.ip.linodeusercontent.com)
2023-11-29 02:06:44 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-29 02:06:44 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f)
2023-11-29 02:06:44 +0100infinity0(~infinity0@pwned.gg)
2023-11-29 02:06:44 +0100040AADFUL(~nand@haasn.dev)
2023-11-29 02:06:44 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-11-29 02:06:44 +0100TMA(tma@twin.jikos.cz)
2023-11-29 02:06:44 +0100andreas303(andreas303@is.drunk.and.ready-to.party)
2023-11-29 02:06:44 +0100srk(~sorki@user/srk)
2023-11-29 02:06:44 +0100[exa](~exa@user/exa/x-3587197)
2023-11-29 02:06:44 +0100mulk(~mulk@p5b2dc93f.dip0.t-ipconnect.de)
2023-11-29 02:06:44 +0100astra(sid289983@user/amish)
2023-11-29 02:06:44 +0100chessai(sid225296@id-225296.lymington.irccloud.com)
2023-11-29 02:06:44 +0100bjs(sid190364@user/bjs)
2023-11-29 02:06:44 +0100shawwwn(sid6132@id-6132.helmsley.irccloud.com)
2023-11-29 02:06:44 +0100actioninja(~actioninj@user/actioninja)
2023-11-29 02:06:44 +0100son0p(~ff@181.136.122.143)
2023-11-29 02:06:44 +0100driib(~driib@vmi931078.contaboserver.net)
2023-11-29 02:06:44 +0100Buggys(Buggys@shelltalk.net)
2023-11-29 02:06:44 +0100mankyKitty(sid31287@id-31287.helmsley.irccloud.com)
2023-11-29 02:06:44 +0100riatre(~quassel@2001:310:6000:f::5198:1)
2023-11-29 02:06:44 +0100CAT_S(apic@brezn3.muc.ccc.de)
2023-11-29 02:06:44 +0100paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com)
2023-11-29 02:06:44 +0100duncan(~duncan@nat-server.ehlab.uk)
2023-11-29 02:06:44 +0100pie__(~pie_bnc@user/pie/x-2818909)
2023-11-29 02:06:50 +0100Arsen(arsen@gentoo/developer/managarm.dev.Arsen)
2023-11-29 02:06:53 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 02:06:54 +0100Xe(~cadey@perl/impostor/xe)
2023-11-29 02:07:04 +0100_________(~nobody@user/noodly)
2023-11-29 02:07:17 +0100cross(~cross@spitfire.i.gajendra.net) (Max SendQ exceeded)
2023-11-29 02:07:29 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 02:07:29 +0100end(~end@user/end/x-0094621)
2023-11-29 02:07:29 +0100remedan(~remedan@ip-94-112-0-18.bb.vodafone.cz)
2023-11-29 02:07:29 +0100potato44(uid421314@id-421314.lymington.irccloud.com)
2023-11-29 02:07:29 +0100ubert(~Thunderbi@91.141.52.8.wireless.dyn.drei.com)
2023-11-29 02:07:29 +0100cods(~fred@tuxee.net)
2023-11-29 02:07:29 +0100dexter2(dexter@2a01:7e00::f03c:91ff:fe86:59ec)
2023-11-29 02:07:29 +0100feetwind(~mike@user/feetwind)
2023-11-29 02:07:29 +0100incertia(~incertia@209.122.137.252)
2023-11-29 02:07:29 +0100swistak-(~swistak@185.21.216.141)
2023-11-29 02:07:29 +0100meinside(uid24933@id-24933.helmsley.irccloud.com)
2023-11-29 02:07:29 +0100nrr_______(sid20938@id-20938.lymington.irccloud.com)
2023-11-29 02:07:29 +0100hamess_(~hamess@user/hamess)
2023-11-29 02:07:29 +0100ft(~ft@p508db3bc.dip0.t-ipconnect.de)
2023-11-29 02:07:29 +0100nckx(~nckx@libera/staff/owl/nckx)
2023-11-29 02:07:29 +0100Pozyomka(~pyon@user/pyon)
2023-11-29 02:07:29 +0100connrs(~connrs@user/connrs)
2023-11-29 02:07:29 +0100kraftwerk28(~kraftwerk@164.92.219.160)
2023-11-29 02:07:29 +0100xsarnik(xsarnik@lounge.fi.muni.cz)
2023-11-29 02:07:29 +0100pieguy128(~pieguy128@bras-base-mtrlpq5031w-grc-49-67-70-103-21.dsl.bell.ca)
2023-11-29 02:07:29 +0100davetapley(sid666@uxbridge.irccloud.com)
2023-11-29 02:07:29 +0100koala_man(~vidar@157.146.251.23.bc.googleusercontent.com)
2023-11-29 02:07:29 +0100pointlessslippe1(~pointless@212.82.82.3)
2023-11-29 02:07:29 +0100lbseale(~quassel@user/ep1ctetus)
2023-11-29 02:07:29 +0100ggVGc(~ggVGc@a.lowtech.earth)
2023-11-29 02:07:29 +0100NiKaN(sid385034@id-385034.helmsley.irccloud.com)
2023-11-29 02:07:29 +0100gaze_____(sid387101@helmsley.irccloud.com)
2023-11-29 02:07:29 +0100conjunctive(sid433686@helmsley.irccloud.com)
2023-11-29 02:07:29 +0100tomku(~tomku@user/tomku)
2023-11-29 02:07:29 +0100nisstyre(wes@user/nisstyre)
2023-11-29 02:07:29 +0100hamster(~ham@user/ham)
2023-11-29 02:07:29 +0100vgtw(~vgtw@user/vgtw)
2023-11-29 02:07:29 +0100Deide(d0130db69a@user/deide)
2023-11-29 02:07:29 +0100mhatta(~mhatta@www21123ui.sakura.ne.jp)
2023-11-29 02:07:29 +0100g00gler(uid125351@id-125351.uxbridge.irccloud.com)
2023-11-29 02:07:29 +0100Katarushisu1(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net)
2023-11-29 02:07:30 +0100remedan(~remedan@ip-94-112-0-18.bb.vodafone.cz) (Max SendQ exceeded)
2023-11-29 02:07:31 +0100superbil(~superbil@1-34-176-171.hinet-ip.hinet.net) (*.net *.split)
2023-11-29 02:07:31 +0100Axman6(~Axman6@user/axman6) (*.net *.split)
2023-11-29 02:07:44 +0100mikess(~sam@user/mikess)
2023-11-29 02:09:51 +0100Axman6(~Axman6@user/axman6)
2023-11-29 02:09:51 +0100superbil(~superbil@1-34-176-171.hinet-ip.hinet.net)
2023-11-29 02:09:52 +0100NiKaN(sid385034@id-385034.helmsley.irccloud.com) (Ping timeout: 250 seconds)
2023-11-29 02:09:54 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-11-29 02:10:18 +0100raym(~ray@user/raym)
2023-11-29 02:11:44 +0100remedan(~remedan@ip-94-112-0-18.bb.vodafone.cz)
2023-11-29 02:12:53 +0100NiKaN(sid385034@id-385034.helmsley.irccloud.com)
2023-11-29 02:13:14 +0100cross(~cross@spitfire.i.gajendra.net)
2023-11-29 02:13:24 +0100rosco(~rosco@175.136.158.171)
2023-11-29 02:16:03 +0100eL_Bart0(eL_Bart0@dietunichtguten.org)
2023-11-29 02:17:46 +0100notzmv(~zmv@user/notzmv)
2023-11-29 02:18:06 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 02:19:53 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-29 02:22:16 +0100emmanuelux_(~emmanuelu@user/emmanuelux)
2023-11-29 02:24:11 +0100emmanuelux(~emmanuelu@user/emmanuelux) (Ping timeout: 260 seconds)
2023-11-29 02:24:14 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 256 seconds)
2023-11-29 02:25:23 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 02:26:07 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Remote host closed the connection)
2023-11-29 02:26:12 +0100haskellbridge(~haskellbr@069-135-003-034.biz.spectrum.com)
2023-11-29 02:26:12 +0100ChanServ+v haskellbridge
2023-11-29 02:26:21 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 02:31:07 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 02:32:29 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 02:32:48 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-11-29 02:34:11 +0100shailangsa(~shailangs@host109-152-9-157.range109-152.btcentralplus.com)
2023-11-29 02:34:14 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 02:36:06 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 02:40:40 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-29 02:42:39 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 02:43:17 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 02:47:37 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 02:50:22 +0100trev(~trev@user/trev)
2023-11-29 02:53:50 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 02:54:16 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 256 seconds)
2023-11-29 02:56:24 +0100nonzen_(~nonzen@user/nonzen) (Ping timeout: 252 seconds)
2023-11-29 02:56:40 +0100nonzen(~nonzen@user/nonzen)
2023-11-29 02:59:30 +0100ubert1(~Thunderbi@178.165.189.208.wireless.dyn.drei.com)
2023-11-29 02:59:59 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 03:00:01 +0100ubert(~Thunderbi@91.141.52.8.wireless.dyn.drei.com) (Ping timeout: 256 seconds)
2023-11-29 03:00:01 +0100ubert1ubert
2023-11-29 03:03:59 +0100pointlessslippe1(~pointless@212.82.82.3) (Ping timeout: 256 seconds)
2023-11-29 03:05:56 +0100pointlessslippe1(~pointless@212.82.82.3)
2023-11-29 03:08:44 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 03:10:39 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 03:11:29 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 03:14:03 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
2023-11-29 03:14:12 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-11-29 03:17:23 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 03:22:48 +0100marinelli(~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection)
2023-11-29 03:23:10 +0100rosco(~rosco@175.136.158.171) (Ping timeout: 256 seconds)
2023-11-29 03:23:22 +0100marinelli(~weechat@gateway/tor-sasl/marinelli)
2023-11-29 03:23:59 +0100rosco(~rosco@175.136.158.171)
2023-11-29 03:24:49 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 03:29:10 +0100matijja(~matijja@193.77.181.201) (Ping timeout: 260 seconds)
2023-11-29 03:29:11 +0100Feuermagier(~Feuermagi@user/feuermagier)
2023-11-29 03:29:19 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 255 seconds)
2023-11-29 03:30:00 +0100mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-11-29 03:30:58 +0100matijja(~matijja@193.77.181.201)
2023-11-29 03:32:01 +0100xff0x(~xff0x@ai096045.d.east.v6connect.net) (Ping timeout: 255 seconds)
2023-11-29 03:32:02 +0100Square2(~Square4@user/square)
2023-11-29 03:35:13 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 03:35:46 +0100justsomeguy(~justsomeg@user/justsomeguy)
2023-11-29 03:36:36 +0100Guest3(~Guest3@149.159.194.55)
2023-11-29 03:37:04 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 03:37:38 +0100 <Guest3> Why are partial functions bad? I am writing a IO action and trying to decide if I should just use error or if I should use Maybe and let the clients throw the error.
2023-11-29 03:38:01 +0100hgolden(~hgolden@2603-8000-9d00-3ed1-dd4f-298a-9c49-a0ed.res6.spectrum.com) (Remote host closed the connection)
2023-11-29 03:38:01 +0100 <Guest3> Using Maybe would force all the clients to pattern match
2023-11-29 03:39:09 +0100 <geekosaur> I don't see that as a bad thing
2023-11-29 03:39:25 +0100hgolden(~hgolden@2603-8000-9d00-3ed1-dd4f-298a-9c49-a0ed.res6.spectrum.com)
2023-11-29 03:40:19 +0100 <geekosaur> if you use `error` and someone does want to catch it, they have to do it in `IO` *and* make sure it is actually executed in the `try` or `handle` so the exception doesn't leak through unevaluated and "go off" somewhere else
2023-11-29 03:41:11 +0100 <Guest3> It is an IO action, so I suppose they have to be in IO to catch it.
2023-11-29 03:41:39 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 03:41:52 +0100 <geekosaur> all exceptions must be caught in `IO`
2023-11-29 03:42:11 +0100 <monochrom> Have you considered defining your own exception to throw so it is easily distinguishable from the millions of other exceptions out there?
2023-11-29 03:42:13 +0100 <Guest3> Yes, but I meant, I am using `error` inside and IO action.
2023-11-29 03:42:20 +0100 <[Leary]> Guest3: Since you're in IO; remove `error` from your list of options and replace it with `throwIO`.
2023-11-29 03:42:33 +0100 <[Leary]> Partial functions are bad, exceptions aren't.
2023-11-29 03:42:58 +0100 <Guest3> Why are partial functions bad? And isn't `error` just throwing an exception?
2023-11-29 03:43:09 +0100 <Guest3> I suppose it just throws a generic exception
2023-11-29 03:43:28 +0100 <geekosaur> there is a difference between synchronous exceptions like thrown by `throwIO` and asynchronous exceptions like thrown by `error`
2023-11-29 03:43:32 +0100 <Guest3> Actually, this is a partial action (not a partial function)
2023-11-29 03:43:37 +0100 <monochrom> That is not how I classify good vs bad.
2023-11-29 03:43:51 +0100 <Guest3> error isn't asynchronous if i recall correctly
2023-11-29 03:44:11 +0100 <monochrom> Making my life harder is bad. After that, making other people's lives harder is bad.
2023-11-29 03:44:37 +0100matijja(~matijja@193.77.181.201) (Ping timeout: 255 seconds)
2023-11-29 03:44:54 +0100 <monochrom> 1% of the time partial functions make my and people's lives easier. 99% of the time harder. I don't ban partial functions. I ban making lives harder.
2023-11-29 03:45:01 +0100 <geekosaur> but partial functions are bad because they raise exceptions in pure code (not `IO`) and are thus especially difficult to catch because you may have to `deepseq` it inside a `catch`/`handle`/etc. to ensure the exception is actually thrown inside the handler
2023-11-29 03:45:42 +0100 <geekosaur> if it isn't fully evaluated inside the handler, it may leak out and detonate outside the handler
2023-11-29 03:46:13 +0100 <Guest3> ah, laziness
2023-11-29 03:46:15 +0100 <monochrom> Likewise, if I expect other people to catch what I throw, 99% of the time their lives are harder if I throw error which is hugely generic and bland, and then what, they have to parse my string to see it's from me? Why would I inflict this on them?
2023-11-29 03:46:49 +0100 <monochrom> Therefore, I define my own exception type and throw it. Then they have a much easier time checking that it's my custom exception.
2023-11-29 03:47:11 +0100 <jackdk> I have found that avoiding partial functions is much easier than I thought when I first started learning Haskell. Becoming fluent with Functor/Applicative/Monad helped a lot there.
2023-11-29 03:47:11 +0100 <zzz> can i use stm for ipc?
2023-11-29 03:47:20 +0100 <Guest3> monochrom, good point. In my case, I don't expect anyone to catch it. Only possibility is crashing.
2023-11-29 03:47:21 +0100 <geekosaur> and if there is associated data, you can make it part of the exception instead of forcing users to parse it out of the message
2023-11-29 03:47:27 +0100matijja(~matijja@193.77.181.201)
2023-11-29 03:47:35 +0100 <Guest3> correct
2023-11-29 03:48:07 +0100 <Guest3> zzz, by ipc do you mean across process boundaries?
2023-11-29 03:48:26 +0100 <geekosaur> zzz, only between threads, not processes
2023-11-29 03:49:54 +0100 <zzz> yes. i figured
2023-11-29 03:50:00 +0100 <zzz> thanks
2023-11-29 03:50:45 +0100 <zzz> i'm no t sure which form of ipc to use
2023-11-29 03:51:15 +0100 <zzz> i think i'm on the fence between sockets and named pipes
2023-11-29 03:51:29 +0100 <geekosaur> sockets, if you value your sanity
2023-11-29 03:51:48 +0100 <monochrom> Well, it says i"p"c not i"t"c. :D
2023-11-29 03:52:34 +0100 <monochrom> Is that because socket is bidirectional, pipes are unidirectional and then you need two of them?
2023-11-29 03:52:38 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04)
2023-11-29 03:52:46 +0100 <geekosaur> partially
2023-11-29 03:53:12 +0100 <monochrom> I did inflict "make two pipes per child, there are n children" on my students in the exam. >:)
2023-11-29 03:53:33 +0100 <geekosaur> to use a named pipe reasonably you must open it `O_RDWR` and keep it open for as long as you are running, and have some way other than EOF to detect when another process closes it
2023-11-29 03:53:52 +0100 <geekosaur> if you use EOF and close it, the FIFO is subsequently dead and you have to remove and recreate it
2023-11-29 03:53:55 +0100 <monochrom> Ah right. That one is annoying yeah.
2023-11-29 03:54:41 +0100 <zzz> so sockets
2023-11-29 03:54:48 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 03:54:59 +0100 <zzz> which library is recommended?
2023-11-29 03:55:10 +0100 <zzz> for i"p"c
2023-11-29 03:56:32 +0100whatsupdoc(uid509081@id-509081.hampstead.irccloud.com)
2023-11-29 03:57:09 +0100 <zzz> Network.Socket ?
2023-11-29 03:57:42 +0100 <geekosaur> I don't think there currently exist higher level abstractions for AF_UNIX sockets
2023-11-29 03:58:02 +0100 <geekosaur> there's lots for TCP but not for other uses
2023-11-29 04:00:10 +0100johnw(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2023-11-29 04:01:11 +0100 <geekosaur> (I'm pretty used to the lower level ones anyway, since I spent years programming in C)
2023-11-29 04:05:37 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04) (Quit: Konversation terminated!)
2023-11-29 04:06:07 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 04:06:24 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04)
2023-11-29 04:06:42 +0100 <zzz> i want high lever. it's a pretty simple use case and i'm just avoiding using a simple text file
2023-11-29 04:06:45 +0100td_(~td@i5387092B.versanet.de) (Ping timeout: 256 seconds)
2023-11-29 04:06:52 +0100 <zzz> *level
2023-11-29 04:07:15 +0100 <zzz> i have no intention of exploring this subject deeply atm
2023-11-29 04:08:16 +0100 <tabemann> stupid question about partial functions - how does STM prevent partial functions from raising exceptions and them leaking out from atomically?
2023-11-29 04:08:21 +0100td_(~td@i5387091D.versanet.de)
2023-11-29 04:09:30 +0100 <tabemann> i.e. allowing state that shouldn't be visible to become visible to the outside world
2023-11-29 04:09:57 +0100 <tabemann> apparently this issue is a big impediment to the implementation of STM in many programming languages
2023-11-29 04:10:00 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 04:10:01 +0100 <zzz> atomically discards any transaction in the event of an exception
2023-11-29 04:10:36 +0100 <zzz> either it performs all or none
2023-11-29 04:10:38 +0100 <tabemann> zzz: what I mean is because of laziness the exception could escape from the atomically
2023-11-29 04:11:04 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 04:11:19 +0100 <zzz> the entire transaction is rolled back as far as i know
2023-11-29 04:11:34 +0100 <tabemann> to prevent that you'd have to deepseq the value returned from atomically
2023-11-29 04:11:37 +0100 <zzz> but it's easy enough to test
2023-11-29 04:11:59 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 04:14:34 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f) (Remote host closed the connection)
2023-11-29 04:14:48 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f)
2023-11-29 04:15:26 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-11-29 04:17:25 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-11-29 04:20:36 +0100Katarushisu1(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Read error: Connection reset by peer)
2023-11-29 04:22:23 +0100Katarushisu1(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net)
2023-11-29 04:25:27 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 04:26:06 +0100 <EvanR> Guest3, partial functions are just fine as long as no one uses it on the missing parts of the domain!
2023-11-29 04:26:47 +0100 <EvanR> > map head (group "hello world")
2023-11-29 04:26:48 +0100 <lambdabot> "helo world"
2023-11-29 04:27:18 +0100 <EvanR> but this is a big if and isn't tracked by the type system
2023-11-29 04:28:07 +0100marinelli(~weechat@gateway/tor-sasl/marinelli) (Ping timeout: 240 seconds)
2023-11-29 04:28:33 +0100marinelli(~weechat@gateway/tor-sasl/marinelli)
2023-11-29 04:28:51 +0100 <jackdk> In your instance, `group` should return `[NonEmpty a]`, right? But the general point stands
2023-11-29 04:29:12 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 04:29:18 +0100 <EvanR> (not that this applies to IO actions which aren't functions and no one would be surprised if they throwIO for some reason)
2023-11-29 04:29:56 +0100 <EvanR> yeah my example in fact has a way to be well typed, terrible example
2023-11-29 04:30:17 +0100edr(~edr@user/edr) (Quit: Leaving)
2023-11-29 04:30:17 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 04:30:21 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine)
2023-11-29 04:31:48 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 04:32:05 +0100 <probie> EvanR: There's a pretty spooky way to track this in the type system
2023-11-29 04:32:12 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-11-29 04:35:21 +0100ddellacosta(~ddellacos@ool-44c73d16.dyn.optonline.net) (Ping timeout: 245 seconds)
2023-11-29 04:37:11 +0100 <EvanR> tabemann, if the transaction succeeds the transaction succeeds. Of course it could have set something up which when evaluate crashes whatever thread. Which is why you probably want to evaluate anything you put in an MVar
2023-11-29 04:37:32 +0100ddellacosta(~ddellacos@ool-44c73d16.dyn.optonline.net)
2023-11-29 04:37:32 +0100 <EvanR> or a TVar
2023-11-29 04:38:03 +0100 <EvanR> but I can see use cases where you don't want to fully evaluate it
2023-11-29 04:39:29 +0100Noob_Programmer(~Noob_Prog@2409:408d:683:c243:a574:68ee:74be:cb54)
2023-11-29 04:41:00 +0100 <tabemann> https://pastebin.com/zRm42Nvf
2023-11-29 04:41:22 +0100 <tabemann> this somehow doesn't raise an exception
2023-11-29 04:42:07 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 240 seconds)
2023-11-29 04:42:37 +0100 <tabemann> because it ought to allow the divide-by-zero to escape the atomically
2023-11-29 04:42:51 +0100 <tabemann> because it is only forced by the "show" outside it
2023-11-29 04:43:33 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 04:43:41 +0100 <EvanR> uh, what does the basically putStrLn (show (1 `div` 0)) do if not crash
2023-11-29 04:43:49 +0100 <EvanR> should crash the thread right
2023-11-29 04:44:03 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2023-11-29 04:44:09 +0100 <EvanR> which is a silent affair by default
2023-11-29 04:46:13 +0100 <tabemann> I added a putStrLn $ show 256 to the loop to make it clear that the loop isn't crashing (because it outputs alternating 1's and 256's)
2023-11-29 04:46:34 +0100 <tabemann> while the main thread is outputting 'foo's
2023-11-29 04:46:50 +0100 <EvanR> % forkIO (print (1 `div` 0)) >> print "ok" >> threadDelay 100000
2023-11-29 04:46:50 +0100 <yahb2> <interactive>:5:1: error: ; Variable not in scope: forkIO :: IO () -> IO a1 ; ; <interactive>:5:45: error: ; Variable not in scope: threadDelay :: t0 -> IO b
2023-11-29 04:48:05 +0100 <Guest3> it's not crashing because, bar is always 1
2023-11-29 04:48:11 +0100 <[Leary]> tabemann: (writeTVar foo 0 >> writeTVar foo 1) = writeTVar foo 1
2023-11-29 04:48:17 +0100Noob_Programmer(~Noob_Prog@2409:408d:683:c243:a574:68ee:74be:cb54) (Quit: Client closed)
2023-11-29 04:48:23 +0100 <Guest3> oh, wait never mid
2023-11-29 04:48:35 +0100stiell(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2023-11-29 04:48:46 +0100 <Guest3> ah, no, i stand by it. bar is always 1
2023-11-29 04:48:56 +0100stiell(~stiell@gateway/tor-sasl/stiell)
2023-11-29 04:49:00 +0100 <tabemann> the key thing is that one thread is never seeing the case where foo is 0 in the other thread
2023-11-29 04:49:18 +0100 <EvanR> yeah, why would anyone see 0
2023-11-29 04:49:24 +0100 <tabemann> i.e. something must be protecting it from seeing this intermediate state and not allowing it to escape
2023-11-29 04:49:25 +0100 <Guest3> yes, because it's a transaction
2023-11-29 04:49:31 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 255 seconds)
2023-11-29 04:49:35 +0100 <EvanR> hence the atomically
2023-11-29 04:49:56 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 04:50:00 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 04:50:14 +0100 <EvanR> what I thought you were going to try to do was put an exploding value in the TVar
2023-11-29 04:50:29 +0100 <tabemann> this whole exercise was raised by the question of other language's STM implementations, where all kinds of nastiness can occur from things like divide-by-zeros occurring within transactions
2023-11-29 04:50:50 +0100 <EvanR> if divide by zero happens during the transaction, then transaction fails
2023-11-29 04:51:12 +0100 <EvanR> otherwise it may succeed but set some other thread up to crash by e.g. storing a bomb somewhere
2023-11-29 04:51:24 +0100 <tabemann> the key thing I was trying to do is to allow the divide by zero to escape by the divide only being forced later on, outside the transaction
2023-11-29 04:51:59 +0100 <monochrom> This transaction includes only reading bar.
2023-11-29 04:52:26 +0100 <Guest3> tabemann, that's not a problem.
2023-11-29 04:53:01 +0100 <monochrom> Unless you say something like "atomically (if div 1 0 then read/write this else read/write that)" you will not have a division by 0 inside a transaction.
2023-11-29 04:53:04 +0100 <tabemann> to avoid this it must do something like ensure that all variables read before and after the transaction not only having not changed state, but also having never changed state - and changed back - in between
2023-11-29 04:53:48 +0100 <EvanR> stuff you write to a TVar or MVar or Chan etc isn't necessarily evaluated yet
2023-11-29 04:54:06 +0100 <EvanR> certainly a tricky thing which could bite you
2023-11-29 04:54:21 +0100 <monochrom> And pure too. pure doesn't evaluate either.
2023-11-29 04:55:09 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-11-29 04:55:09 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-11-29 04:55:10 +0100 <Guest3> tabemann, the exception happening later won't affect the transaction. The only side-effect you can do inside an STM transaction is modify TVars
2023-11-29 04:55:11 +0100 <tabemann> monochrom: which I was doing with return (which is pure, but I'm using an older version of Stack because I haven't played with Haskell in ages and did not feel like installing a new version right now)
2023-11-29 04:55:13 +0100 <monochrom> pure (div 1 0), writeTVar v (div 1 0) all do not including performing the division insde the transaction.
2023-11-29 04:55:27 +0100 <Guest3> And you can't modify TVars outside a transaction
2023-11-29 04:55:34 +0100 <Guest3> The type system takes care of this
2023-11-29 04:56:10 +0100 <monochrom> But like I said you can play with a transaction that needs conditional branching that depends on div 1 0.
2023-11-29 04:57:12 +0100 <EvanR> modifyTVar' tv (`div` 0)
2023-11-29 04:57:12 +0100 <tabemann> Guest3: of course
2023-11-29 04:57:23 +0100johnw(~johnw@69.62.242.138)
2023-11-29 04:57:38 +0100 <EvanR> this will take the liberty of evaluating the division by zero for you now
2023-11-29 04:57:38 +0100 <monochrom> None of this should be surprising.
2023-11-29 04:57:51 +0100 <tabemann> the thing is the point of this was to enable one thread to see another thread's intermediate state
2023-11-29 04:57:57 +0100 <EvanR> without the "prime" you would be writing a bomb to the TVar
2023-11-29 04:58:12 +0100 <EvanR> (if you don't rollback)
2023-11-29 04:58:17 +0100 <tabemann> i.e. make atomically non-atomic
2023-11-29 04:58:29 +0100 <EvanR> what language lets you see STM transactions intermediate state? That sounds broken
2023-11-29 04:58:40 +0100 <monochrom> And Haskell is not nicer or nastier than other languages in this regard because if you insert enough $!'s you can recover other languages' evaluation order. Try pure $! div 1 0.
2023-11-29 04:59:05 +0100 <tabemann> EvanR: that's why STM hasn't really caught on outside of Haskell and Clojure
2023-11-29 04:59:22 +0100 <tabemann> Haskell is uniquely well-suited to STM
2023-11-29 04:59:26 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04) (Remote host closed the connection)
2023-11-29 04:59:26 +0100 <monochrom> All kinds of exceptions can still happen in STM too so what it does in response is already well-defined.
2023-11-29 04:59:28 +0100 <EvanR> because no one implements it correctly?
2023-11-29 04:59:32 +0100ddellacosta(~ddellacos@ool-44c73d16.dyn.optonline.net) (Quit: WeeChat 4.1.1)
2023-11-29 04:59:38 +0100 <EvanR> I figured clojure was correct
2023-11-29 05:00:09 +0100 <tabemann> EvanR: because most languages provide no mechanism to ensuring the correctness of STM
2023-11-29 05:00:20 +0100 <tabemann> it's up to the programmer to not fubar it
2023-11-29 05:00:26 +0100 <EvanR> well neither does haskell, STM is a GHC feature
2023-11-29 05:00:52 +0100 <tabemann> well yes, but Haskell enables constructing a type system that enforces STM
2023-11-29 05:00:53 +0100 <monochrom> I don't think you put the reason the right way.
2023-11-29 05:00:55 +0100 <EvanR> you can't program it with just forkIO
2023-11-29 05:01:16 +0100 <[Leary]> The real issue that stymies STM in other languages is impurity. Side effects in a transaction will be observed even if the transaction is cancelled.
2023-11-29 05:01:18 +0100 <tabemann> EvanR: exactly
2023-11-29 05:01:29 +0100 <tabemann> [Leary]: precisely
2023-11-29 05:01:53 +0100 <monochrom> I think the right way is this. By analogy to Haskell: Imagine inside atomically you can play with both TVar and IORef. That's what other languages allow, and that's why it becomes problematic.
2023-11-29 05:02:01 +0100 <[Leary]> However, execeptions themselves are not an issue, as the GHC implementation proves.
2023-11-29 05:02:25 +0100 <tabemann> so what I've discovered today is that atomically has some magic that prevents intermediate states from being read, to avoid constructing logic bombs that expose other threads' intemediate states
2023-11-29 05:02:51 +0100 <EvanR> I'm still not sure how the lazy division by zero would expose any intermediate states of anything
2023-11-29 05:03:06 +0100 <EvanR> if you divide by zero in the transaction it is canceled as expected
2023-11-29 05:03:16 +0100 <[Leary]> That's not deep magic, it's the core idea of using atomic transactions (however you implement them).
2023-11-29 05:03:17 +0100 <monochrom> Haskell's solution is to ban IORef inside STM, but still allow it in IO. Clojure's solution is to ban IORef altogether; all mutable vars are TVars.
2023-11-29 05:04:36 +0100 <tabemann> EvanR: laziness would still allow the divide by zero to escape; the magic must be to check all reads before and after to ensure that any updates, even if the actual values haven't changed before and after, abort the transaction
2023-11-29 05:06:11 +0100 <EvanR> your test of trying to read a zero from a TVar which is always left as 1 in the writing transaction just seems to test STM and not any exception case, your writing transaction never attempted to crash
2023-11-29 05:06:38 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 05:06:53 +0100 <tabemann> EvanR: I'm writing alternating 0's and 1's to the TVar
2023-11-29 05:07:09 +0100 <tabemann> in a transaction, such that from the outside PoV the TVar should always be 1
2023-11-29 05:07:10 +0100 <EvanR> yes but the changes are not visible until after the comment
2023-11-29 05:07:31 +0100 <EvanR> I'm not sure how a division by zero in an unrelated thread would have any effect anyway
2023-11-29 05:07:48 +0100Guest3(~Guest3@149.159.194.55) (Quit: Client closed)
2023-11-29 05:08:35 +0100 <monochrom> Sure. Any other transaction reading it will get 1. Albeit after much retries.
2023-11-29 05:08:52 +0100 <monochrom> What is the surprise again?
2023-11-29 05:09:13 +0100 <EvanR> you could have just tested the value for zero and printed an emoji if so
2023-11-29 05:09:18 +0100Guest3(~Guest3@149.159.194.55)
2023-11-29 05:09:20 +0100rosco(~rosco@175.136.158.171) (Quit: leaving)
2023-11-29 05:09:43 +0100 <tabemann> I basically was trying to see whether a naive approach that just catches exceptions within the reading thread is being applied
2023-11-29 05:10:27 +0100 <monochrom> Huh but you wrote no catcher.
2023-11-29 05:11:01 +0100 <EvanR> they mean try to show the runtime system doing something really dumb
2023-11-29 05:11:05 +0100 <tabemann> monochrome: what I meant is whether atomically just relies on catching exceptions and aborting if any are raised
2023-11-29 05:11:07 +0100 <monochrom> Are you sure you didn't mix up "catch" with "throw".
2023-11-29 05:11:21 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 256 seconds)
2023-11-29 05:12:02 +0100 <EvanR> is there a language which does STM this way?
2023-11-29 05:12:37 +0100 <tabemann> probably most, as most languages aren't lazy
2023-11-29 05:12:38 +0100 <EvanR> catching exceptions in everyone elses thread
2023-11-29 05:12:53 +0100 <EvanR> rather than the thread doing the atomically
2023-11-29 05:13:04 +0100 <tabemann> I mean in the thread doing the atomically
2023-11-29 05:13:07 +0100Alleria(~JohnGalt@user/alleria) (Read error: Connection reset by peer)
2023-11-29 05:13:20 +0100 <EvanR> oh ok, well you didn't cause an error within the atomically
2023-11-29 05:14:25 +0100 <tabemann> I just confirmed that GHC has magic that prevents intermediate read values from escaping even if no writes are applied out to the target TVar
2023-11-29 05:14:44 +0100 <tabemann> probably in the form of something like an update clock or like
2023-11-29 05:15:18 +0100 <EvanR> no, it just doesn't commit any changes when transactions fail
2023-11-29 05:16:00 +0100 <tabemann> that's what I was trying to disprove
2023-11-29 05:16:19 +0100 <tabemann> that's what I mean by a "naive" approach
2023-11-29 05:16:33 +0100 <EvanR> the naive approach to STM is to just write to memory normally? xD
2023-11-29 05:16:49 +0100 <EvanR> and hope no other threads actually run
2023-11-29 05:17:23 +0100 <tabemann> no, a naive approach to STM is to just ensure that no writes conflict with one another, and no exceptions occur within atomically blocks
2023-11-29 05:17:48 +0100 <monochrom> Don't hope. Enforce. Run the threads with sequential time sharing.
2023-11-29 05:18:24 +0100 <EvanR> it's true that SQL servers come with modes that don't enforce transaction semantics, maybe this is why you're confused
2023-11-29 05:18:25 +0100 <monochrom> This is why a select/poll/event loop does not have to worry about this. >:)
2023-11-29 05:19:17 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 268 seconds)
2023-11-29 05:19:17 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 05:19:39 +0100 <EvanR> but transaction is supposed to mean any sequence of writes AND reads are consistent within the transaction, as well as only seeing the final state of previous commits
2023-11-29 05:20:02 +0100 <tabemann> EvanR: and that's what I've confirmed here
2023-11-29 05:20:03 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 05:20:19 +0100 <tabemann> monochrom: of course there's always Erlang's approach
2023-11-29 05:20:20 +0100 <EvanR> just to clarify, you say clojure is busted?
2023-11-29 05:20:45 +0100 <EvanR> or only busted when they do side effects
2023-11-29 05:20:50 +0100 <tabemann> EvanR: nah, not Clojure, just the millions of STM frameworks which I highly suspect are crap
2023-11-29 05:21:05 +0100 <monochrom> Clojure can't be busted. It lacks one of retry or orElse, I forgot which.
2023-11-29 05:21:24 +0100rosco(~rosco@175.136.158.171)
2023-11-29 05:21:33 +0100 <tabemann> because they have no means of preventing side effects from within transactions
2023-11-29 05:21:46 +0100 <monochrom> I.e., you can't make more mistakes if you simply omit important features! >:)
2023-11-29 05:22:23 +0100 <EvanR> technically haskell also lets you do non-transactional effects within the transaction
2023-11-29 05:22:37 +0100 <tabemann> EvanR: i.e. unsafePerformIO
2023-11-29 05:23:01 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 05:23:05 +0100 <tabemann> but unsafePerformIO means that you've decided to press the button anyways
2023-11-29 05:23:28 +0100 <tabemann> after that point all bets are off
2023-11-29 05:23:29 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 05:24:16 +0100 <EvanR> I thought that was actually disallowed in stm
2023-11-29 05:24:35 +0100 <EvanR> there's this thing unsafeIOToSTM
2023-11-29 05:25:06 +0100 <monochrom> Yeah you need also that. unsafePerformIO alone is not enough, you don't even have IO inside STM, formally.
2023-11-29 05:25:07 +0100 <EvanR> anyway it comes down to culture again
2023-11-29 05:25:10 +0100 <tabemann> that's when you launch a nuclear strike on your own position to kill all the zombies
2023-11-29 05:26:01 +0100 <[Leary]> atomically-in-atomically is disallowed by the RTS. I don't think it takes issue with just `unsafePerformIO`, though?
2023-11-29 05:26:09 +0100 <EvanR> oh ok
2023-11-29 05:26:30 +0100 <EvanR> it was either atomically inside unsafePerformIO or the other way around that was failing
2023-11-29 05:26:48 +0100 <tabemann> I thought it was atomically within unsafePerformIO that was verboten
2023-11-29 05:27:10 +0100 <EvanR> that direction makes less sense
2023-11-29 05:27:32 +0100 <EvanR> maybe it was transitive nesting of atomically
2023-11-29 05:29:34 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 260 seconds)
2023-11-29 05:31:02 +0100 <[Leary]> % atomically (pure $! unsafePerformIO (atomically (pure 0)))
2023-11-29 05:31:03 +0100 <yahb2> *** Exception: Control.Concurrent.STM.atomically was nested
2023-11-29 05:32:03 +0100rosco(~rosco@175.136.158.171) (Quit: Lost terminal)
2023-11-29 05:32:28 +0100 <EvanR> oh sure, yahb has STM but not forkIO and threadDelay
2023-11-29 05:32:37 +0100 <EvanR> and uPIO
2023-11-29 05:32:51 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 05:32:53 +0100 <[Leary]> I imported them in PM.
2023-11-29 05:40:20 +0100rosco(~rosco@175.136.158.171)
2023-11-29 05:43:36 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 05:44:39 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 05:50:43 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 255 seconds)
2023-11-29 05:53:22 +0100aforemny(~aforemny@i59F516F2.versanet.de)
2023-11-29 05:53:29 +0100aforemny_(~aforemny@i59F516E0.versanet.de) (Ping timeout: 252 seconds)
2023-11-29 06:02:13 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 06:02:52 +0100johnw(~johnw@69.62.242.138) (Quit: ZNC - http://znc.in)
2023-11-29 06:04:08 +0100Guest3(~Guest3@149.159.194.55) (Ping timeout: 250 seconds)
2023-11-29 06:08:23 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 06:14:23 +0100Square2(~Square4@user/square) (Ping timeout: 264 seconds)
2023-11-29 06:19:51 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 06:25:53 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 06:27:57 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 06:33:54 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 06:45:55 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 06:51:11 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 245 seconds)
2023-11-29 07:03:20 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 07:07:26 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 245 seconds)
2023-11-29 07:07:51 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-11-29 07:08:25 +0100euleritian(~euleritia@dynamic-046-114-169-147.46.114.pool.telefonica.de)
2023-11-29 07:09:13 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 256 seconds)
2023-11-29 07:13:20 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2023-11-29 07:13:30 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 07:17:14 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-11-29 07:17:14 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-11-29 07:17:14 +0100finn_elijaFinnElija
2023-11-29 07:18:10 +0100euleritian(~euleritia@dynamic-046-114-169-147.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 07:18:28 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 07:19:49 +0100Alleria(~JohnGalt@user/alleria) (Read error: Connection reset by peer)
2023-11-29 07:20:20 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 07:22:18 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-11-29 07:25:16 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-29 07:25:57 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 07:26:07 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 276 seconds)
2023-11-29 07:26:26 +0100euleritian(~euleritia@dynamic-046-114-169-147.46.114.pool.telefonica.de)
2023-11-29 07:26:34 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 255 seconds)
2023-11-29 07:28:31 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 07:34:20 +0100johnw(~johnw@69.62.242.138)
2023-11-29 07:34:38 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 260 seconds)
2023-11-29 07:35:28 +0100chomwitt(~chomwitt@2a02:587:7a10:2a00:1ac0:4dff:fedb:a3f1)
2023-11-29 07:37:39 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-11-29 07:38:26 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection)
2023-11-29 07:39:01 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-11-29 07:46:29 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 07:48:27 +0100justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 256 seconds)
2023-11-29 07:52:47 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 07:53:19 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Remote host closed the connection)
2023-11-29 07:53:19 +0100azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-11-29 07:53:47 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-11-29 07:59:15 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 08:00:40 +0100komikat(~akshitkr@218.185.248.66) (Ping timeout: 255 seconds)
2023-11-29 08:03:27 +0100acidjnk(~acidjnk@p200300d6e72b9352dcea2d781ea8e5a4.dip0.t-ipconnect.de)
2023-11-29 08:04:12 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 08:07:11 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 264 seconds)
2023-11-29 08:10:07 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 255 seconds)
2023-11-29 08:13:57 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 256 seconds)
2023-11-29 08:14:20 +0100harveypwca(~harveypwc@2601:246:c280:7940:585a:99af:3e4c:209b)
2023-11-29 08:15:24 +0100kenran(~user@user/kenran)
2023-11-29 08:17:01 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-29 08:19:52 +0100mechap(~mechap@user/mechap) (Quit: WeeChat 4.1.1)
2023-11-29 08:21:57 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 08:22:09 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-11-29 08:23:23 +0100rosco(~rosco@175.136.158.171) (Read error: Connection reset by peer)
2023-11-29 08:24:22 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4)
2023-11-29 08:25:34 +0100rosco(~rosco@175.136.158.171)
2023-11-29 08:25:39 +0100rosco(~rosco@175.136.158.171) (Client Quit)
2023-11-29 08:25:50 +0100rosco(~rosco@175.136.158.171)
2023-11-29 08:28:02 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2023-11-29 08:28:11 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 08:29:53 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 08:30:03 +0100pr0ton(~pr0ton@176.254.244.83) (Ping timeout: 261 seconds)
2023-11-29 08:30:24 +0100 <srk> dminuoso_: considered transitioning to dhall and dhall-to-nix?
2023-11-29 08:35:45 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 252 seconds)
2023-11-29 08:36:21 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-29 08:42:25 +0100coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-11-29 08:43:20 +0100Umeaboy(~Umeaboy@94-255-145-133.cust.bredband2.com)
2023-11-29 08:43:24 +0100 <Umeaboy> Hi!
2023-11-29 08:44:20 +0100 <Umeaboy> Why is there no support for glibc 2.36 in the cabal-install rpm? I see 2.33, 2.34 and 2.38.
2023-11-29 08:44:49 +0100 <Umeaboy> I ran rpm -qpR cabal-install-3.8.1.0-2.fc40.x86_64.rpm to check.
2023-11-29 08:45:19 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-11-29 08:45:19 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-11-29 08:45:19 +0100finn_elijaFinnElija
2023-11-29 08:47:32 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 08:47:55 +0100shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 255 seconds)
2023-11-29 08:52:35 +0100euleritian(~euleritia@dynamic-046-114-169-147.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 08:53:04 +0100euleritian(~euleritia@dynamic-046-114-169-147.46.114.pool.telefonica.de)
2023-11-29 08:53:07 +0100fendor(~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c)
2023-11-29 08:53:21 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 252 seconds)
2023-11-29 08:53:22 +0100euleritian(~euleritia@dynamic-046-114-169-147.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 08:53:39 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 08:58:40 +0100Alatheia(~Alatheia@176.254.244.83)
2023-11-29 09:01:24 +0100gmg(~user@user/gehmehgeh)
2023-11-29 09:03:43 +0100cfricke(~cfricke@user/cfricke)
2023-11-29 09:05:12 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 09:07:01 +0100alp_(~alp@2001:861:e3d6:8f80:ba78:18cf:70dd:23bc)
2023-11-29 09:11:06 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 256 seconds)
2023-11-29 09:11:16 +0100 <sclv> you will have to ask the debian or whatever maintainers.
2023-11-29 09:11:25 +0100 <sclv> ie its a distro question
2023-11-29 09:13:27 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2023-11-29 09:15:35 +0100kenran`(~user@user/kenran)
2023-11-29 09:16:12 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-11-29 09:17:23 +0100kenran(~user@user/kenran) (Ping timeout: 264 seconds)
2023-11-29 09:20:53 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-11-29 09:22:24 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 09:28:16 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 245 seconds)
2023-11-29 09:31:09 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 09:35:04 +0100Jackneill(~Jackneill@20014C4E1E0B5A0069081ECE081E635B.dsl.pool.telekom.hu)
2023-11-29 09:36:53 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-11-29 09:37:22 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 268 seconds)
2023-11-29 09:44:49 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 09:57:19 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 260 seconds)
2023-11-29 09:58:16 +0100tzh_(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz)
2023-11-29 09:58:51 +0100econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-11-29 09:59:55 +0100lbseale(~quassel@user/ep1ctetus) (Ping timeout: 256 seconds)
2023-11-29 10:02:04 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-11-29 10:02:09 +0100mikess(~sam@user/mikess) (Read error: Connection reset by peer)
2023-11-29 10:06:20 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f) (Remote host closed the connection)
2023-11-29 10:06:30 +0100komikat(~akshitkr@218.185.248.66)
2023-11-29 10:09:35 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 10:11:02 +0100CiaoSen(~Jura@2a05:5800:28a:6100:2a3a:4dff:fe84:dbd5)
2023-11-29 10:15:35 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it) (Ping timeout: 264 seconds)
2023-11-29 10:24:31 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Remote host closed the connection)
2023-11-29 10:24:32 +0100jrm(~jrm@user/jrm) (Ping timeout: 268 seconds)
2023-11-29 10:24:44 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 10:24:59 +0100jrm(~jrm@user/jrm)
2023-11-29 10:26:09 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-11-29 10:26:27 +0100pandry(~Pandry@93-41-34-64.ip79.fastwebnet.it)
2023-11-29 10:27:02 +0100danza(~francesco@151.43.234.166)
2023-11-29 10:28:52 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-11-29 10:30:42 +0100harveypwca(~harveypwc@2601:246:c280:7940:585a:99af:3e4c:209b) (Quit: Leaving)
2023-11-29 10:31:01 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-11-29 10:31:58 +0100danza(~francesco@151.43.234.166) (Ping timeout: 255 seconds)
2023-11-29 10:41:48 +0100manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck) (Ping timeout: 268 seconds)
2023-11-29 10:42:02 +0100manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck)
2023-11-29 10:43:54 +0100danse-nr3(~danse@151.43.234.166)
2023-11-29 10:43:57 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f)
2023-11-29 10:47:57 +0100alp_(~alp@2001:861:e3d6:8f80:ba78:18cf:70dd:23bc) (Remote host closed the connection)
2023-11-29 10:48:14 +0100alp_(~alp@2001:861:e3d6:8f80:455d:a197:398e:7c06)
2023-11-29 10:49:26 +0100 <dminuoso_> Servant question: Say Im making a typeclass class HasSummary api where toSummary :: Proxy api -> String; instance forall sym ty. KnownSymbol sym => HasSummary (Summary sym :> ty) where toSummary _ = symbolVal (Proxy :: Proxy sym)
2023-11-29 10:49:53 +0100 <dminuoso_> And I hold a generic endpoint record selector in my hand, Im a bit confused how to apply toSummary to that endpoint record selector.
2023-11-29 10:56:31 +0100rosco(~rosco@175.136.158.171) (Quit: Lost terminal)
2023-11-29 10:57:26 +0100manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck) (Ping timeout: 245 seconds)
2023-11-29 10:58:38 +0100manwithluck(manwithluc@gateway/vpn/protonvpn/manwithluck)
2023-11-29 10:58:52 +0100CiaoSen(~Jura@2a05:5800:28a:6100:2a3a:4dff:fe84:dbd5) (Ping timeout: 246 seconds)
2023-11-29 10:59:00 +0100__monty__(~toonn@user/toonn)
2023-11-29 11:00:52 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 11:01:29 +0100CiaoSen(~Jura@5.83.179.237)
2023-11-29 11:03:38 +0100danse-nr3(~danse@151.43.234.166) (Read error: Connection reset by peer)
2023-11-29 11:03:57 +0100danse-nr3(~danse@151.57.228.14)
2023-11-29 11:04:50 +0100 <kuribas> Welcome to the nastiness that is the Servant implementation.
2023-11-29 11:10:06 +0100chele(~chele@user/chele)
2023-11-29 11:11:10 +0100Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-11-29 11:12:35 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds)
2023-11-29 11:13:25 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving)
2023-11-29 11:14:08 +0100Lord_of_Life_Lord_of_Life
2023-11-29 11:23:42 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 256 seconds)
2023-11-29 11:34:28 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-11-29 11:34:32 +0100[_](~itchyjunk@user/itchyjunk/x-7353470)
2023-11-29 11:36:04 +0100hamess_hamess
2023-11-29 11:38:14 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 268 seconds)
2023-11-29 11:38:20 +0100shapr(~user@2600:1700:c640:3100:c355:fe3e:4f9f:d5b6) (Remote host closed the connection)
2023-11-29 11:38:34 +0100shapr(~user@2600:1700:c640:3100:af48:8802:e8a5:3ea1)
2023-11-29 11:48:48 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04)
2023-11-29 11:50:10 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 255 seconds)
2023-11-29 11:57:56 +0100Philonous(~Philonous@user/philonous) (Quit: ZNC - https://znc.in)
2023-11-29 11:58:21 +0100Philonous(~Philonous@user/philonous)
2023-11-29 11:58:44 +0100chele(~chele@user/chele) (Remote host closed the connection)
2023-11-29 12:04:45 +0100coot(~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 252 seconds)
2023-11-29 12:04:49 +0100coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-11-29 12:06:22 +0100mc47(~mc47@xmonad/TheMC47)
2023-11-29 12:06:42 +0100shOkEy(~shOkEy@178-164-206-123.pool.digikabel.hu) (Ping timeout: 260 seconds)
2023-11-29 12:08:32 +0100shOkEy(~shOkEy@91-83-3-30.pool.digikabel.hu)
2023-11-29 12:12:24 +0100xff0x(~xff0x@2405:6580:b080:900:9a48:ce0:12d3:d0ae)
2023-11-29 12:14:09 +0100not_reserved(~not_reser@45.144.113.234)
2023-11-29 12:25:02 +0100 <danse-nr3> morning all. I think one needs dependent types to get type safety with matrices, do you have a solution you like in a non-dependent haskell library?
2023-11-29 12:27:15 +0100 <danse-nr3> i know it sounds like a contradiction, but i am not sure about the first statement and i am curious about other compromises
2023-11-29 12:30:55 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-11-29 12:31:45 +0100gmg(~user@user/gehmehgeh)
2023-11-29 12:35:32 +0100 <lortabac> dependent types are needed when you have terms whose type is determined at runtime
2023-11-29 12:35:57 +0100 <lortabac> so for example if the size of the matrix is known statically there is no need for dependent types
2023-11-29 12:37:00 +0100 <danse-nr3> i see, i have a wrong understanding of dependent types then. Any matrix typing you find elegant or nice to work with?
2023-11-29 12:38:25 +0100arahael(~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) ()
2023-11-29 12:38:49 +0100 <danse-nr3> (i am surprised that lists with encoded length are not more common then, at least i never stumble upon them)
2023-11-29 12:39:01 +0100 <lortabac> if the size of the matrix is only known at runtime, then you need some way to reason generically over any size, and that's where dependent types become useful
2023-11-29 12:39:54 +0100 <danse-nr3> right, but usually the size is known in function signatures (add one to rows, transpose etcetera)
2023-11-29 12:40:15 +0100chele(~chele@user/chele)
2023-11-29 12:40:35 +0100 <lortabac> I've never worked with matrixes in Haskell, but I suppose there are libraries that do what you are looking for
2023-11-29 12:42:15 +0100rosco(~rosco@175.136.158.171)
2023-11-29 12:42:50 +0100 <danse-nr3> yes i think i saw some years ago, maybe repa or some custom types for some neural network lib, i don't recall now. I guess a type like `a n -> a (n+1)` cannot be written in vanilla haskell and it requires some extension?
2023-11-29 12:44:49 +0100CiaoSen(~Jura@5.83.179.237) (Ping timeout: 256 seconds)
2023-11-29 12:45:07 +0100 <lortabac> yes you need TypeFamilies, TypeOperators and maybe more
2023-11-29 12:45:17 +0100 <danse-nr3> cheers lortabac
2023-11-29 12:47:50 +0100 <lortabac> danse-nr3: imagine you want a function 'generateMatrix' that fills a matrix of size NxM with a given value
2023-11-29 12:48:15 +0100 <lortabac> generateMatrix :: Int -> Int -> Matrix n m
2023-11-29 12:48:21 +0100 <danse-nr3> is that where dependent types come in the picture?
2023-11-29 12:48:35 +0100 <danse-nr3> i guess one could have an `n` encoding for ints
2023-11-29 12:48:38 +0100 <lortabac> you need a way to tell the type system that the first Int should be 'n' and the second one should be 'm'
2023-11-29 12:48:48 +0100 <lortabac> but in Haskell you can't
2023-11-29 12:49:13 +0100akegalj(~akegalj@78-2-198-3.adsl.net.t-com.hr)
2023-11-29 12:49:30 +0100 <danse-nr3> that would be a very long haskell file though, probably unfeasible
2023-11-29 12:49:49 +0100 <lortabac> in a dependently-typed language it would be something like 'generateMatrix : (n : Nat) -> (m : Nat) -> Matrix n m
2023-11-29 12:50:06 +0100 <danse-nr3> yeah makes more sense like this
2023-11-29 12:52:11 +0100 <lortabac> where the type of the first argument is 'Nat' and 'n' is a name that refers to its value
2023-11-29 12:54:36 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 12:58:58 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 13:00:01 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 13:00:50 +0100 <bwe> think of hlint noting those spots in my code that make it probably very slow. is there a tool that does just that? instead of mapM use forM... or is there just a checklist of how to optimise my haskell code "instead ... use"
2023-11-29 13:00:58 +0100 <lortabac> oops the signature should be 'generateMatrix : (n : Nat) -> (m : Nat) -> a -> Matrix n m a'
2023-11-29 13:01:05 +0100 <lortabac> but you got the idea
2023-11-29 13:02:15 +0100 <danse-nr3> yes that syntax is clear
2023-11-29 13:02:39 +0100 <bwe> I know it's very basic but such a kind of list of rules of thumb would make all the difference for me.
2023-11-29 13:02:39 +0100 <danse-nr3> performance is more a matter of semantics bwe, i don't think linting goes that far
2023-11-29 13:04:05 +0100 <bwe> danse-nr3: so, if I'd ask you, which examples of instead … do … can you recall from your very experience?
2023-11-29 13:04:48 +0100 <danse-nr3> the different fold functions, i guess, but nothing to be automated, requires reasoning and understanding
2023-11-29 13:05:31 +0100 <bwe> danse-nr3: so along the lines of avoid iterating by putting everything into memory before giving it to the next function?
2023-11-29 13:06:34 +0100 <danse-nr3> well the considerations explained in wiki.haskell.org/Foldr_Foldl_Foldl'
2023-11-29 13:09:10 +0100 <bwe> so, great, I could find all those spots in my code and choose wisely. that implies mapM for example. Other than the intricacies of the different folds, what should I look at?
2023-11-29 13:10:48 +0100 <bwe> (also, how can I tell which function eventually calls a fold? is it possible to get that answer automated? I assume naïvely that this could be done because the execution does it anyways; but just a naïve approach)
2023-11-29 13:11:48 +0100kenran``(~user@user/kenran)
2023-11-29 13:12:58 +0100danse-nr3(~danse@151.57.228.14) (Remote host closed the connection)
2023-11-29 13:13:13 +0100Jackneill(~Jackneill@20014C4E1E0B5A0069081ECE081E635B.dsl.pool.telekom.hu) (Ping timeout: 276 seconds)
2023-11-29 13:13:16 +0100kenran`(~user@user/kenran) (Ping timeout: 245 seconds)
2023-11-29 13:13:22 +0100danse-nr3(~danse@151.57.228.14)
2023-11-29 13:14:56 +0100tremon(~tremon@83.80.159.219)
2023-11-29 13:15:23 +0100kenran```(~user@user/kenran)
2023-11-29 13:16:13 +0100 <ski> "you need a way to tell the type system that the first Int should be 'n' and the second one should be 'm'","but in Haskell you can't" -- you can do existentials
2023-11-29 13:17:31 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-11-29 13:17:59 +0100gmg(~user@user/gehmehgeh) (Remote host closed the connection)
2023-11-29 13:17:59 +0100kenran``(~user@user/kenran) (Ping timeout: 264 seconds)
2023-11-29 13:18:22 +0100danse-nr3(~danse@151.57.228.14) (Ping timeout: 255 seconds)
2023-11-29 13:18:24 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 13:18:51 +0100gmg(~user@user/gehmehgeh)
2023-11-29 13:18:53 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 13:22:46 +0100kenran```kenran
2023-11-29 13:22:47 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 256 seconds)
2023-11-29 13:24:03 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds)
2023-11-29 13:27:11 +0100 <komikat> b
2023-11-29 13:27:43 +0100 <komikat> been working with pytorch for sometime, is there any library to do deep learning with in #haskell
2023-11-29 13:28:30 +0100 <komikat> i've been meaning to write a dependency parser for natural languages and wanted to see if i could get that to work with a functional programming language
2023-11-29 13:37:42 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-11-29 13:42:27 +0100not_reserved(~not_reser@45.144.113.234) (Quit: Client closed)
2023-11-29 13:44:24 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 13:44:25 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net) (Ping timeout: 276 seconds)
2023-11-29 13:50:28 +0100remedan(~remedan@ip-94-112-0-18.bb.vodafone.cz) (Ping timeout: 256 seconds)
2023-11-29 13:51:20 +0100rosco(~rosco@175.136.158.171) (Quit: Lost terminal)
2023-11-29 13:52:51 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 13:52:57 +0100jespada(~jespada@cpc121308-nmal25-2-0-cust15.19-2.cable.virginm.net)
2023-11-29 13:53:01 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04) (Quit: Konversation terminated!)
2023-11-29 13:55:44 +0100remedan(~remedan@ip-94-112-0-18.bb.vodafone.cz)
2023-11-29 13:56:27 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-11-29 14:02:36 +0100 <bwe> btw what is the go-to language if I'd seek something like Gofer or Hugs?
2023-11-29 14:02:57 +0100 <bwe> sort of Haskell for educational purposes
2023-11-29 14:08:53 +0100 <haskellbridge> 14<m​auke> Isn't hugs just a Haskell interpreter?
2023-11-29 14:11:59 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-29 14:20:56 +0100edr(~edr@user/edr)
2023-11-29 14:26:24 +0100azimut(~azimut@gateway/tor-sasl/azimut)
2023-11-29 14:30:31 +0100Lycurgus(~georg@user/Lycurgus)
2023-11-29 14:33:20 +0100sawilagar(~sawilagar@user/sawilagar)
2023-11-29 14:34:07 +0100rosco(~rosco@175.136.158.171)
2023-11-29 14:34:30 +0100kimiamania46(~65804703@user/kimiamania) (Quit: PegeLinux)
2023-11-29 14:34:50 +0100kimiamania46(~65804703@user/kimiamania)
2023-11-29 14:38:07 +0100danse-nr3(~danse@151.57.228.14)
2023-11-29 14:39:02 +0100CiaoSen(~Jura@2a05:5800:28a:6100:2a3a:4dff:fe84:dbd5)
2023-11-29 14:40:22 +0100kimiamania46(~65804703@user/kimiamania) (Quit: PegeLinux)
2023-11-29 14:40:54 +0100danse-nr3(~danse@151.57.228.14) (Remote host closed the connection)
2023-11-29 14:41:18 +0100danse-nr3(~danse@151.57.228.14)
2023-11-29 14:42:47 +0100 <danse-nr3> how would you express that with existentials ski?
2023-11-29 14:43:07 +0100kimiamania46(~65804703@user/kimiamania)
2023-11-29 14:43:40 +0100akegalj(~akegalj@78-2-198-3.adsl.net.t-com.hr) (Quit: leaving)
2023-11-29 14:47:59 +0100 <danse-nr3> not any popular one i am afraid komikat
2023-11-29 14:53:53 +0100kimiamania46(~65804703@user/kimiamania) (Quit: PegeLinux)
2023-11-29 14:59:05 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 15:01:11 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 15:02:10 +0100kimiamania46(~65804703@user/kimiamania)
2023-11-29 15:02:39 +0100Alleria(~JohnGalt@user/alleria) (Ping timeout: 268 seconds)
2023-11-29 15:03:50 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 15:04:58 +0100danse-nr3(~danse@151.57.228.14) (Read error: Connection reset by peer)
2023-11-29 15:05:27 +0100danse-nr3(~danse@151.35.247.219)
2023-11-29 15:07:59 +0100shriekingnoise(~shrieking@186.137.175.87)
2023-11-29 15:16:01 +0100swamps(~swamps@static-a197.Irkutsk.golden.ru)
2023-11-29 15:16:57 +0100swamps(~swamps@static-a197.Irkutsk.golden.ru) (Client Quit)
2023-11-29 15:17:36 +0100swamps(~swamps@static-a197.Irkutsk.golden.ru)
2023-11-29 15:18:18 +0100kenran(~user@user/kenran) (Remote host closed the connection)
2023-11-29 15:19:16 +0100rosco(~rosco@175.136.158.171) (Quit: Lost terminal)
2023-11-29 15:19:47 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds)
2023-11-29 15:20:34 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 15:27:00 +0100fendor(~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c) (Remote host closed the connection)
2023-11-29 15:32:13 +0100danse-nr3(~danse@151.35.247.219) (Ping timeout: 246 seconds)
2023-11-29 15:32:43 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04)
2023-11-29 15:33:05 +0100Lycurgus(~georg@user/Lycurgus) (Quit: leaving)
2023-11-29 15:36:49 +0100danse-nr3(~danse@151.35.247.219)
2023-11-29 15:39:48 +0100Xyloes(~wyx@2400:dd01:103a:1012:5923:33ce:7857:fc04) (Quit: Konversation terminated!)
2023-11-29 15:43:56 +0100 <komikat> :(
2023-11-29 15:47:42 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2023-11-29 15:49:14 +0100 <trev> bwe: you could try idris
2023-11-29 15:49:58 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity)
2023-11-29 15:50:07 +0100 <danse-nr3> komikat, you could try julia XD
2023-11-29 15:50:30 +0100 <komikat> does julia have types?
2023-11-29 15:50:48 +0100 <komikat> as in strong typing
2023-11-29 15:51:10 +0100 <danse-nr3> i think it does yes
2023-11-29 15:51:10 +0100notzmv(~zmv@user/notzmv) (Ping timeout: 256 seconds)
2023-11-29 15:51:37 +0100 <komikat> interesting
2023-11-29 15:53:54 +0100seeg123456(~seeg12345@64.176.64.83)
2023-11-29 15:55:01 +0100shapr(~user@2600:1700:c640:3100:af48:8802:e8a5:3ea1) (Remote host closed the connection)
2023-11-29 15:55:14 +0100shapr(~user@2600:1700:c640:3100:a007:14d5:426f:261d)
2023-11-29 15:58:57 +0100 <komikat> damn "Julia's type system is dynamic, but gains some of the advantages of static type systems by making it possible to indicate that certain values are of specific types"
2023-11-29 16:00:09 +0100 <danse-nr3> yeah, looking at it again, i am not sure the types satisfy your requirements docs.julialang.org/en/v1/manual/types. Also not sure that the language is that functionaly ... someone mentioned julia to me some time ago relating it to haskell, but i am not seeing the connection right now
2023-11-29 16:00:26 +0100 <danse-nr3> *functional
2023-11-29 16:02:16 +0100 <danse-nr3> i was also told that R is quite functional but i don't know it, and it is "dynamically typed"
2023-11-29 16:03:05 +0100 <komikat> ah yeah
2023-11-29 16:03:28 +0100 <komikat> it doesn't seem *purely* functional but at least it doesn't have objects xD like python
2023-11-29 16:10:38 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection)
2023-11-29 16:10:59 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-11-29 16:16:00 +0100ivelten(~ivelten@2804:82b8:8:ee01:fda6:516:611b:3176)
2023-11-29 16:22:01 +0100mrmr15533(~mrmr@user/mrmr) (Ping timeout: 245 seconds)
2023-11-29 16:22:12 +0100mrmr155331(~mrmr@user/mrmr)
2023-11-29 16:24:47 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 16:25:18 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 16:29:42 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2023-11-29 16:30:18 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 16:31:56 +0100 <ski> danse-nr3 : `generateMatrix :: Int -> Int -> a -> exists m n. Matrix n m a'
2023-11-29 16:32:56 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 16:33:02 +0100 <ncf> that doesn't really express that m and n come from the first two arguments
2023-11-29 16:33:25 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 276 seconds)
2023-11-29 16:33:35 +0100 <ski> (btw, note that this is weaker than `generateMatrix : (n : Nat) -> (m : Nat) -> a -> Matrix n m a'. basically same thing as `(exists a. P a) -> (exists a. Q a)' being weaker than `forall a. P a -> Q a'. so, it's weaker because it doesn't link the two size arguments, to the corresponding parameters to the return type)
2023-11-29 16:33:44 +0100ystael_(~ystael@user/ystael)
2023-11-29 16:33:44 +0100 <ski> right
2023-11-29 16:33:59 +0100ystael(~ystael@user/ystael) (Ping timeout: 260 seconds)
2023-11-29 16:34:21 +0100ystael_ystael
2023-11-29 16:34:47 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2023-11-29 16:35:14 +0100 <ski> it could still be used, to express that there will be *some* sizes for the resulting matrix. while `generateMatrix :: Int -> Int -> a -> Matrix n m' would be incorrect, as that's saying as the sizes of the resulting matrix will be whatever the caller wants them to be (unrelated to the two size arguments)
2023-11-29 16:35:54 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 16:35:57 +0100 <danse-nr3> interesting, thanks
2023-11-29 16:37:13 +0100 <ski> anyway, the `exists' is obviously pseudo-Haskell. you can encode it in two different ways in Haskell. (a) using `ExistentialQuantification' (imho a misnomer, `ExistentialConstructors' would be better); or (b) using CPS with `Rank2Types'
2023-11-29 16:38:21 +0100 <danse-nr3> i agree that sounds like a misnomer
2023-11-29 16:38:44 +0100 <ski> (a) would be `generateMatrix :: Int -> Int -> a -> SomeMatrix a' where `data SomeMatrix a = forall n m. WrapMatrix (Matrix n m a)' (or `data SomeMatrix :: * -> * where WrapMatrix :: Matrix n m a -> SomeMatrix a', using `GADTSyntax')
2023-11-29 16:39:27 +0100 <ski> (b) would be `withGeneratedMatrix :: Int -> Int -> a -> (forall n m. Matrix n m a -> o) -> o'
2023-11-29 16:40:36 +0100 <danse-nr3> meh, with `exists` it looked way more readable, but maybe this is not such a common use case
2023-11-29 16:40:44 +0100cfricke(~cfricke@user/cfricke) (Quit: WeeChat 4.0.5)
2023-11-29 16:41:14 +0100 <ski> yes. that's why i presented it with that pseudo-Haskell syntax first, becauses it's easier to reason about and think about it, in that form
2023-11-29 16:42:28 +0100 <ski> ((a) tends to be better, when you're going to store the result in data-structures. while (b) tends to be better when you're going to use the result directly after the call)
2023-11-29 16:43:16 +0100 <ski> perhaps in some future, we could get actual `exists' syntax ..
2023-11-29 16:43:30 +0100 <lortabac> ski: unless I misunderstood something, this doesn't solve the problem I was talking about
2023-11-29 16:43:38 +0100 <ski> (Mercury has real existential quantification, like that)
2023-11-29 16:43:47 +0100 <danse-nr3> yeah that would be nice
2023-11-29 16:43:55 +0100 <danse-nr3> no it is not the same lortabac but somehow close
2023-11-29 16:43:58 +0100 <ski> it does not solve the problem of connecting the size arguments to the type of the result, no
2023-11-29 16:44:07 +0100 <lortabac> I want the matrix to have size NxM where N and M are the values of the first 2 arguments
2023-11-29 16:44:12 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 16:44:15 +0100 <ski> well, you do get that
2023-11-29 16:44:21 +0100tzh(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-11-29 16:44:27 +0100 <ski> it's just that you don't statically (in the types) know that that's what you get
2023-11-29 16:44:31 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 16:45:09 +0100 <lortabac> yes, my point was that with dependent types you can encode this piece of information in the types
2023-11-29 16:45:18 +0100 <ski> right
2023-11-29 16:45:50 +0100 <lortabac> (and also that if you don't have a similar use case you don't need full dependent types)
2023-11-29 16:46:11 +0100jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 245 seconds)
2023-11-29 16:46:46 +0100ivelten(~ivelten@2804:82b8:8:ee01:fda6:516:611b:3176) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-11-29 16:46:59 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-29 16:47:26 +0100 <ski> you could try something like `generateMatrix :: (KnownNat n,KnownNat m) => p m -> q n -> a -> Matrix n m a'
2023-11-29 16:48:58 +0100Maxdamantus(~Maxdamant@user/maxdamantus) (Ping timeout: 255 seconds)
2023-11-29 16:49:00 +0100vishnix(~vishwas@c-73-9-42-9.hsd1.il.comcast.net)
2023-11-29 16:49:16 +0100 <ski> (or, rolling your own singletons, `data Nat = Zero | Succ Nat; data IsNat :: Nat -> * where ZeroS :: IsNat Zero; SuccS :: IsNat n -> IsNat (Succ n)', then `generateMatrix :: IsNat n -> IsNat m -> a -> Matrix n m a')
2023-11-29 16:49:30 +0100vishnix(~vishwas@c-73-9-42-9.hsd1.il.comcast.net) (Client Quit)
2023-11-29 16:49:36 +0100 <lortabac> I don't think the solution with proxies would be usable if M and N are only known at runtime, for example fetched from a database
2023-11-29 16:49:38 +0100Maxdamantus(~Maxdamant@user/maxdamantus)
2023-11-29 16:49:40 +0100vishnix(~vishwas@c-73-9-42-9.hsd1.il.comcast.net)
2023-11-29 16:49:41 +0100ivelten(~ivelten@2804:82b8:8:ee01:fda6:516:611b:3176)
2023-11-29 16:53:06 +0100 <ski> (the `KnowNat' constraints would be carrying the run-time info. you could then use `natVal :: KnownNat n => proxy n -> Natural', or perhaps `natSing :: KnownNat n => SNat n')
2023-11-29 16:53:45 +0100 <c_wraith> You can use types that are only known at runtime
2023-11-29 16:53:47 +0100 <ski> (the operation that gets the `m' and `n' from the database would use existentials (in either encoding above)
2023-11-29 16:53:50 +0100 <ski> )
2023-11-29 16:54:07 +0100 <lortabac> I don't think you can fully solve this problem without singletons
2023-11-29 16:54:26 +0100 <lortabac> with the other solutions somewhere you lose information in the types
2023-11-29 16:54:32 +0100 <ski> getDBNat :: ... -> IO (exists n. KnownNat n *> Const n ())
2023-11-29 16:55:23 +0100 <ski> (with (b), that becomes `with DBNat :: ... -> (forall n. KnownNat n => IO o) -> IO o')
2023-11-29 16:57:41 +0100 <lortabac> if you use existentials, how do you pass the generated matrix to other functions and preserve the sizes in the types?
2023-11-29 16:57:56 +0100 <c_wraith> bizarrely enough, you just do
2023-11-29 16:58:32 +0100 <lortabac> I don't think that is possible without singletons
2023-11-29 16:58:41 +0100 <c_wraith> You have the KnownNat constraint available
2023-11-29 16:58:49 +0100 <c_wraith> you can always lower it to a value when needed
2023-11-29 16:59:14 +0100 <c_wraith> (as long as you are passing the constraint around)
2023-11-29 16:59:37 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 16:59:41 +0100 <lortabac> I'm not sure I follow
2023-11-29 16:59:58 +0100 <lortabac> (forall n. KnownNat n => IO o) the 'n' is lost here
2023-11-29 17:00:09 +0100 <c_wraith> No it's not.
2023-11-29 17:00:19 +0100 <c_wraith> it's right there in the type
2023-11-29 17:00:21 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 17:00:50 +0100 <lortabac> ok let's recapitulate
2023-11-29 17:01:17 +0100 <c_wraith> But you *do* need to use other extensions that allow you to use that formulation usefully
2023-11-29 17:01:26 +0100alp_(~alp@2001:861:e3d6:8f80:455d:a197:398e:7c06) (Ping timeout: 256 seconds)
2023-11-29 17:01:49 +0100 <c_wraith> Otherwise you'd end up needing a type more like (forall n. KnownNat n => proxy n -> IO o)
2023-11-29 17:02:09 +0100 <lortabac> I want to fetch M and N from the database, create a (Matrix m n Int) and pass it to a function that expects a matrix, keeping the size information in the types
2023-11-29 17:02:31 +0100 <lortabac> all this without singletons
2023-11-29 17:03:32 +0100 <c_wraith> have you read through GHC.TypeLits?
2023-11-29 17:04:19 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds)
2023-11-29 17:04:38 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 17:04:44 +0100 <lortabac> oh
2023-11-29 17:04:54 +0100 <lortabac> I wasn't aware that SNat is now in base
2023-11-29 17:05:02 +0100 <c_wraith> you don't even need it
2023-11-29 17:05:08 +0100 <c_wraith> you'd just call someNatVal twice
2023-11-29 17:05:16 +0100 <c_wraith> pattern match on the results, and go
2023-11-29 17:06:55 +0100 <lortabac> interesting
2023-11-29 17:07:48 +0100 <c_wraith> You do lose something over having literals in your types - you can't trivially generate new constraints like (0 < n) => ...
2023-11-29 17:08:12 +0100 <c_wraith> When all you have is KnownNat, that's the only constraint you get.
2023-11-29 17:08:30 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 17:13:08 +0100szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-11-29 17:13:43 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2023-11-29 17:14:40 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 17:16:02 +0100alp_(~alp@2001:861:e3d6:8f80:882f:ff0d:da80:ca07)
2023-11-29 17:16:04 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 17:16:21 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 17:16:46 +0100kaol_kaol
2023-11-29 17:18:18 +0100 <lortabac> c_wraith: I'm trying to write a minimal example without success
2023-11-29 17:18:23 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 256 seconds)
2023-11-29 17:19:12 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-11-29 17:19:42 +0100 <lortabac> this naive version doesn't compile https://paste.tomsmeding.com/DRwgbFdT
2023-11-29 17:20:37 +0100 <lortabac> ah wait, I think I understand
2023-11-29 17:20:49 +0100 <c_wraith> Oh. That's because KnownNat n doesn't imply KnownNat (n-1)
2023-11-29 17:22:49 +0100 <c_wraith> Though you're also going to need ScopeTypeVariables to talk about n (the type) in the function body like that
2023-11-29 17:22:56 +0100 <c_wraith> *ScopedTypeVariables
2023-11-29 17:23:00 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer)
2023-11-29 17:23:05 +0100 <lortabac> no, I'm lost
2023-11-29 17:23:09 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 17:23:09 +0100 <ski> the `Nat' `n' in the pattern in `n -> x :< generate (Proxy :: Proxy (n - 1)) x' is also unrelated to the `Nat' `n - 1' in the expressio there
2023-11-29 17:23:21 +0100 <c_wraith> yes, that's why you need ScopedTypeVariables
2023-11-29 17:23:24 +0100 <ski> yes
2023-11-29 17:23:26 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 17:23:44 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 17:23:52 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
2023-11-29 17:23:59 +0100 <ski> you need to replace the pattern `pn' with `(pn :: p n)'
2023-11-29 17:24:40 +0100 <ski> or, i suppose, just add `forall p n a. ' to the signature
2023-11-29 17:24:59 +0100 <lortabac> I tried but it still doesn't compile
2023-11-29 17:25:22 +0100 <lortabac> Couldn't match type ‘n’ with ‘0’
2023-11-29 17:25:55 +0100 <lortabac> anyway I have to go now, I'll try again tomorrow
2023-11-29 17:26:00 +0100 <ski> just matching on `n' will probably not be enough, yea
2023-11-29 17:26:07 +0100 <lortabac> you made me curious :)
2023-11-29 17:26:31 +0100 <danse-nr3> bye lortabac o/
2023-11-29 17:26:52 +0100lortabac(~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.1.1)
2023-11-29 17:27:12 +0100 <c_wraith> Honestly, that's like the single worst case for Nat, the way GHC works
2023-11-29 17:27:29 +0100 <c_wraith> (yes, I know lortabac is gone)
2023-11-29 17:27:44 +0100 <ski> i suspect they'll need to use `natSing', rather than `natVal', there
2023-11-29 17:28:45 +0100 <c_wraith> I don't think it matters. That definition of generate requires recursive generation of NatVal constraints
2023-11-29 17:29:04 +0100 <c_wraith> GHC makes that painful
2023-11-29 17:29:33 +0100 <ski> (s/NatVal/KnownNat/)
2023-11-29 17:29:34 +0100 <ski> yea
2023-11-29 17:29:37 +0100 <c_wraith> err, yes
2023-11-29 17:29:46 +0100harveypwca(~harveypwc@2601:246:c280:7940:585a:99af:3e4c:209b)
2023-11-29 17:30:15 +0100 <c_wraith> Amusingly, last time I looked through GHC typechecking plugins, I recall seeing one specifically intended for this purpose
2023-11-29 17:30:32 +0100 <ski> it says
2023-11-29 17:30:33 +0100bgamari_(~bgamari@64.223.175.94)
2023-11-29 17:30:38 +0100phma_(phma@2001:5b0:210d:4b88:3e7a:d751:236f:1da4)
2023-11-29 17:30:40 +0100 <ski> class KnownNat (n :: Nat) where
2023-11-29 17:30:44 +0100 <ski> GHC.TypeNats.natSing :: GHC.TypeNats.SNat n
2023-11-29 17:30:48 +0100 <ski> but i get nothing for `:i SNat'
2023-11-29 17:31:12 +0100 <c_wraith> are you on a GHC that uses base 4.19?
2023-11-29 17:31:24 +0100 <ski> hm, this was 8.8.4
2023-11-29 17:31:37 +0100 <c_wraith> Oh, I guess 4.18 is sufficient
2023-11-29 17:32:20 +0100 <ski> if it had something like `data SNat :: Nat -> * where ZeroS :: SNat 0; SuccS :: KnownNat n => SNat n -> SNat (1 + n)', then matching on the `SNat n' would help
2023-11-29 17:32:20 +0100 <c_wraith> but 4.18 means GHC 9.6+
2023-11-29 17:32:33 +0100bgamari(~bgamari@64.223.173.10) (Ping timeout: 256 seconds)
2023-11-29 17:33:10 +0100phma(~phma@host-67-44-208-32.hnremote.net) (Ping timeout: 256 seconds)
2023-11-29 17:34:03 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds)
2023-11-29 17:35:39 +0100 <c_wraith> Hmm. This probably does get a lot easier if you use SNat, but you can probably get away with only doing that internally.
2023-11-29 17:36:26 +0100mrvdb-(~mrvdb@2001:19f0:5000:8582:5400:ff:fe07:3df5) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-29 17:36:28 +0100 <c_wraith> Oh, I see. You can also use sameNat
2023-11-29 17:36:57 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds)
2023-11-29 17:36:58 +0100 <ski> hm, right
2023-11-29 17:37:17 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 17:37:48 +0100 <c_wraith> But yes, this stuff is painful. there's a reason I see it called "hasochism"
2023-11-29 17:38:59 +0100 <danse-nr3> well we were looking for ways to do the thing without the thing (dependent types), so no surprise if it results hacky
2023-11-29 17:40:44 +0100mrvdb(~mrvdb@185.92.221.186)
2023-11-29 17:40:50 +0100 <danse-nr3> although the lack of `exists` seems to have marked some significant increase in complexity... but maybe that is just my impression because i lost track of the problem afterwards
2023-11-29 17:41:02 +0100mikess(~sam@user/mikess)
2023-11-29 17:43:21 +0100 <c_wraith> It does add complexity, but it's purely mechanical complexity
2023-11-29 17:44:00 +0100 <c_wraith> the workarounds are known and don't require creativity
2023-11-29 17:45:11 +0100phma_phma
2023-11-29 18:01:47 +0100mmhat(~mmh@p200300f1c71a22b9ee086bfffe095315.dip0.t-ipconnect.de)
2023-11-29 18:02:27 +0100ivelten(~ivelten@2804:82b8:8:ee01:fda6:516:611b:3176) (Quit: Textual IRC Client: www.textualapp.com)
2023-11-29 18:04:26 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-11-29 18:07:00 +0100 <c_wraith> actually, it's worse than I thought. I don't see any way at all to relate n-1 as a value to n-1 as a type, no matter what you know about n as a type
2023-11-29 18:08:38 +0100Alleria(~JohnGalt@user/alleria) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-11-29 18:10:51 +0100 <c_wraith> So, like.. you're just going to have to unsafeCoerce, I guess!
2023-11-29 18:11:58 +0100danse-nr3(~danse@151.35.247.219) (Ping timeout: 268 seconds)
2023-11-29 18:12:45 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2023-11-29 18:18:32 +0100danza(~francesco@151.35.247.219)
2023-11-29 18:20:02 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 18:20:40 +0100Alleria(~JohnGalt@user/alleria) (Client Quit)
2023-11-29 18:21:20 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 18:21:41 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 18:21:57 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2023-11-29 18:25:39 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1))
2023-11-29 18:28:08 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds)
2023-11-29 18:28:18 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 18:34:40 +0100sawilagar(~sawilagar@user/sawilagar) (Quit: Leaving)
2023-11-29 18:36:38 +0100Alleria(~JohnGalt@user/alleria)
2023-11-29 18:38:20 +0100dhil(~dhil@2001:8e0:2014:3100:8e3a:5299:914c:abf4)
2023-11-29 18:38:42 +0100CiaoSen(~Jura@2a05:5800:28a:6100:2a3a:4dff:fe84:dbd5) (Ping timeout: 260 seconds)
2023-11-29 18:39:58 +0100cstml(~cstml@user/cstml)
2023-11-29 18:40:09 +0100sawilagar(~sawilagar@user/sawilagar)
2023-11-29 18:41:28 +0100Alleria(~JohnGalt@user/alleria) (Ping timeout: 255 seconds)
2023-11-29 18:41:28 +0100komikat(~akshitkr@218.185.248.66) (Ping timeout: 255 seconds)
2023-11-29 18:41:57 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
2023-11-29 18:46:55 +0100ChaiTRex(~ChaiTRex@user/chaitrex)
2023-11-29 18:49:58 +0100alp_(~alp@2001:861:e3d6:8f80:882f:ff0d:da80:ca07) (Ping timeout: 246 seconds)
2023-11-29 18:53:30 +0100chele(~chele@user/chele) (Remote host closed the connection)
2023-11-29 18:54:42 +0100shapr(~user@2600:1700:c640:3100:a007:14d5:426f:261d) (Remote host closed the connection)
2023-11-29 18:54:56 +0100shapr(~user@2600:1700:c640:3100:f067:6b60:6d79:cd2d)
2023-11-29 18:55:46 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:5836:1305:ce95:7f7f) (Remote host closed the connection)
2023-11-29 18:56:01 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920)
2023-11-29 19:02:34 +0100 <c_wraith> ski: (or anyone else) https://paste.tomsmeding.com/I2hpWpM9 Am I wrong? Can this be done without unsafeCoerce or a type checker plugin?
2023-11-29 19:03:55 +0100danza(~francesco@151.35.247.219) (Read error: Connection reset by peer)
2023-11-29 19:04:23 +0100qqq(~qqq@92.43.167.61)
2023-11-29 19:04:44 +0100 <c_wraith> well, ok. it can also be done by changing to an inductive Nat type instead of using a type literal.
2023-11-29 19:07:00 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 19:07:19 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 19:07:46 +0100 <dolio> Yeah, I think the reason you can't do it is because the instances for KnownNat aren't inductive.
2023-11-29 19:08:49 +0100 <ski> `KnownNat n => KnownNat (1 + n)' wouldn't help, would it ?
2023-11-29 19:09:31 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 245 seconds)
2023-11-29 19:09:32 +0100 <dolio> It would if the continuation had a KnownNat constraint.
2023-11-29 19:10:06 +0100 <c_wraith> which is a fine thing to add.
2023-11-29 19:11:13 +0100 <c_wraith> I'm honestly surprised the SNat stuff didn't have tools to do that
2023-11-29 19:11:39 +0100 <c_wraith> it seems like the right place to put them
2023-11-29 19:11:40 +0100 <ski> how would it help ?
2023-11-29 19:12:20 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-29 19:12:30 +0100 <c_wraith> something like SNatPlus :: SNat -> SNat -> SNat
2023-11-29 19:12:53 +0100harveypwca(~harveypwc@2601:246:c280:7940:585a:99af:3e4c:209b) (Quit: Leaving)
2023-11-29 19:13:01 +0100 <dolio> Because then it would instantiate to `forall n. KnownNat n => List (1 + n) a -> x`, which is used to build the continuation for the recursive call.
2023-11-29 19:13:16 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920) (Remote host closed the connection)
2023-11-29 19:13:37 +0100 <dolio> Assuming the cons has length 1 + n.
2023-11-29 19:14:04 +0100 <c_wraith> err. SNat m -> SNat n -> SNat (m + n)
2023-11-29 19:14:48 +0100 <c_wraith> the partial functions would need a more clever type, but it could be done
2023-11-29 19:15:32 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920)
2023-11-29 19:16:12 +0100 <ski> replicateExists k e (f :: forall n. KnownNat n => List n a -> o) = replicateExists (k - 1) e ((\ls -> f (e :< ls)) :: forall m. KnownNat m => List m a -> o)
2023-11-29 19:16:21 +0100 <dolio> Oh, but there's another problem. There's no connection between the supplied Integer argument and the type level natural.
2023-11-29 19:16:41 +0100 <ski> right, so `n = m + 1', and given `KnownNat m' we deduce `KnownNat n'
2023-11-29 19:17:24 +0100 <c_wraith> dolio: that doesn't actually matter if the KnownNat constraint is provided to the continuation, thanks to sameNat
2023-11-29 19:17:46 +0100 <ski> dolio : yea, that's what started this conversation branch, more or less
2023-11-29 19:18:01 +0100 <dolio> It matters in replicate, because e.g. `id` isn't a valid continuation.
2023-11-29 19:18:08 +0100 <dolio> It's a skolem escape.
2023-11-29 19:18:25 +0100 <c_wraith> you have to use sameNat and match it Just Refl
2023-11-29 19:18:27 +0100 <ski> right, you must use `n' locally
2023-11-29 19:18:48 +0100 <c_wraith> then you have proven the types are the same, and the skolem is safely trapped
2023-11-29 19:18:59 +0100 <dolio> You have to structure it differently, even if you have the inductive instances.
2023-11-29 19:19:36 +0100danza(~francesco@151.57.236.24)
2023-11-29 19:19:52 +0100 <c_wraith> I mean, you're correct that you can't use id
2023-11-29 19:20:12 +0100 <ski> (you could still use `WrapList :: KnownNat n => List n a -> SomeList a' as continuation)
2023-11-29 19:20:14 +0100 <c_wraith> but the tools you need are already there so long as the KnownNat constraint is there
2023-11-29 19:22:52 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2023-11-29 19:23:03 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de)
2023-11-29 19:31:22 +0100cstml19(~cstml@user/cstml)
2023-11-29 19:32:40 +0100cstml19(~cstml@user/cstml) (Client Quit)
2023-11-29 19:33:28 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2023-11-29 19:35:20 +0100notzmv(~zmv@user/notzmv)
2023-11-29 19:39:21 +0100 <c_wraith> yeah... the missing part here is that the singletons in GHC.TypeLits are incomplete. You should have operations in the singletons that mirror the type-level operations provided.
2023-11-29 19:39:23 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 19:40:30 +0100 <c_wraith> but those are missing. as a result, the tools aren't available to reflect between types and values after applying type-level operations
2023-11-29 19:43:39 +0100Umeaboy(~Umeaboy@94-255-145-133.cust.bredband2.com) (Quit: Leaving)
2023-11-29 19:46:20 +0100AWizzArd(~code@user/awizzard)
2023-11-29 19:47:09 +0100thegeekinside(~thegeekin@189.180.53.210) (Remote host closed the connection)
2023-11-29 19:47:48 +0100 <AWizzArd> When using hspec and hedgehog in the same project (using Cabal 3+), hspec seems to be consuming all tests. I am running hedgehog tests in main but they won't start. Does this ring a bell for anyone?
2023-11-29 19:49:29 +0100danza(~francesco@151.57.236.24) (Ping timeout: 252 seconds)
2023-11-29 19:49:52 +0100 <exarkun> "Consuming"?
2023-11-29 19:49:54 +0100 <c_wraith> .... wait, maybe the tools are there. I need to come back to this later with a fresh pov
2023-11-29 19:51:45 +0100 <c_wraith> whoops. forget later, I got there now. the tools are indeed absent.
2023-11-29 19:52:27 +0100 <AWizzArd> exarkun: my main is essentially: main = do runHspecTess runHedgehogTests (with correct indentation of course). The HH tests never run. Even if they put them before the hspec tests. This is ignored.
2023-11-29 19:52:37 +0100 <AWizzArd> I can even remove runHspecTests and yet still only they run. Only if I put HH tests before and configure one of the hspec tests to fail the HH tests run.
2023-11-29 19:53:43 +0100 <AWizzArd> It seems to me a bit like some Cabal magic possibly. It discovers the hspec tests and runs them and then quits.
2023-11-29 19:54:32 +0100 <geekosaur> sounds more like something is not being rebuilt, especially if you can remove them and they stilll run
2023-11-29 19:54:55 +0100jorik808(~jorik808@d51A48920.access.telenet.be)
2023-11-29 19:55:49 +0100euleritian(~euleritia@dynamic-046-114-032-227.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-29 19:56:09 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-29 19:57:10 +0100 <AWizzArd> geekosaur: yes, I deleted dist/ and new-dist/ but this didn’t change the outcome. Actually I had only one single hspec test. Now I have two. If I outcomment the hspec tests I still get this result: 1 of 1 test suites (1 of 1 test cases) passed. — it should say 2 tests passed
2023-11-29 20:00:35 +0100marinelli(~weechat@gateway/tor-sasl/marinelli) (Quit: marinelli)
2023-11-29 20:03:27 +0100 <AWizzArd> I now found a log file that has been created. And the hedegehog tests do run, but they seem to log to that file and not to the screen!
2023-11-29 20:03:37 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-11-29 20:04:48 +0100 <geekosaur> are you using `cabal test`? if so then you want `--test-show-details=streaming`
2023-11-29 20:06:16 +0100justsomeguy(~justsomeg@user/justsomeguy)
2023-11-29 20:07:50 +0100cstml(~cstml@user/cstml) (Ping timeout: 260 seconds)
2023-11-29 20:08:09 +0100 <AWizzArd> geekosaur: aah, this displays the result on the screen!
2023-11-29 20:08:12 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 252 seconds)
2023-11-29 20:08:18 +0100cstml(~cstml@user/cstml)
2023-11-29 20:08:20 +0100 <AWizzArd> geekosaur: Excellent, thx!
2023-11-29 20:10:18 +0100 <AWizzArd> Is there also some kind of file watching capability built-in? Or would I be best advised to use some Linux tools for this?
2023-11-29 20:10:35 +0100 <geekosaur> I don't think there is
2023-11-29 20:10:43 +0100mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-11-29 20:11:03 +0100mc47(~mc47@xmonad/TheMC47)
2023-11-29 20:12:34 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920) (Remote host closed the connection)
2023-11-29 20:13:44 +0100 <haskellbridge> 06<s​m> can recommend watchexec
2023-11-29 20:18:48 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-11-29 20:20:10 +0100qhong(~qhong@rescomp-21-400677.stanford.edu)
2023-11-29 20:20:22 +0100 <AWizzArd> haskellbridge: will have a look, thx
2023-11-29 20:26:23 +0100 <ski> s/haskellbridge/sm/
2023-11-29 20:27:58 +0100skiidly notes haskellbridge adds ZWSP, not some diacritic
2023-11-29 20:28:24 +0100Feuermagier(~Feuermagi@user/feuermagier) (Remote host closed the connection)
2023-11-29 20:35:31 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920)
2023-11-29 20:36:40 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds)
2023-11-29 20:42:29 +0100cstml(~cstml@user/cstml) (Quit: WeeChat 3.7.1)
2023-11-29 20:45:01 +0100alp_(~alp@2001:861:e3d6:8f80:4342:868e:5cc7:17fd)
2023-11-29 20:53:36 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920) (Remote host closed the connection)
2023-11-29 20:55:53 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-29 20:58:42 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-29 20:59:03 +0100 <tomsmeding> ski: I saw some irc user elsewhere claim that that was "conventional" as a friently, i.e. non-notifying, mention
2023-11-29 20:59:38 +0100 <tomsmeding> not that I know how to type that character without going to https://tomsmeding.com/unicode
2023-11-29 21:00:10 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 21:00:22 +0100Pickchea(~private@user/pickchea)
2023-11-29 21:01:35 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 21:01:45 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-11-29 21:04:48 +0100 <ski> tomsmeding : yea. i'm just wondering to what extent it is an issue (compared to the complication it ensues)
2023-11-29 21:05:30 +0100 <tomsmeding> as in, that clients render it incorrectly or something?
2023-11-29 21:05:45 +0100 <ski> e.g. there is no nick "sm" in this channel, only on the other side of the bridge, so in this particular case that argument about non-notifying doesn't apply
2023-11-29 21:06:08 +0100 <ski> (and it does mean that if i search backlog for `<sm>', i won't find those abridged messages)
2023-11-29 21:07:02 +0100 <ski> tomsmeding : no, as in there's no issue with you getting noticed on the other side of the bridge, when saying something, if you're not actually also on the other side of the bridge (with the same nick)
2023-11-29 21:07:21 +0100 <tomsmeding> ski: ah, fair point
2023-11-29 21:08:07 +0100 <tomsmeding> though I believe there are indeed a few people who have a client on both sides of the bridge, at least occasionally
2023-11-29 21:08:19 +0100 <ski> (the ZWSP also renders as an extra unicode modification of the previous glyph, here .. making it looked like a dotted box above the character, which in turn makes it hard to make out the first character, so that i have to copy, and then delete the ZWSP in order to see which nick it's supposed to be)
2023-11-29 21:08:57 +0100 <ski> yes. but the bridge could, conceivably, only add ZWSP for messages from such nicks, and not to messages from all nicks
2023-11-29 21:08:59 +0100 <tomsmeding> ski: that sounds like a renderer problem :D https://ircbrowse.tomsmeding.com/browse/lchaskell?id=1153514#trid1153514
2023-11-29 21:09:03 +0100 <tomsmeding> true
2023-11-29 21:09:06 +0100 <ski> yes
2023-11-29 21:10:59 +0100 <ski> tomsmeding : oh .. for some reason the log doesn't seem to handle the color code gracefully
2023-11-29 21:11:09 +0100 <tomsmeding> yeah I saw that too
2023-11-29 21:11:13 +0100 <tomsmeding> I'm less concerned about that
2023-11-29 21:11:32 +0100 <tomsmeding> I suspect it's just not interpreting the color code at all and just piping it to the browser, which shrugs and gives you this
2023-11-29 21:11:38 +0100 <ski> (if it just displayed the escape as `C', rather than silently ignoring it, that would be fine)
2023-11-29 21:12:08 +0100 <tomsmeding> yeah the escape byte is there literally in the html
2023-11-29 21:12:26 +0100 <tomsmeding> a \x03 byte
2023-11-29 21:12:40 +0100 <EvanR> > '\3'
2023-11-29 21:12:41 +0100 <lambdabot> '\ETX'
2023-11-29 21:12:47 +0100 <tomsmeding> end-of-text
2023-11-29 21:12:52 +0100 <tomsmeding> ¯\_(ツ)_/¯
2023-11-29 21:13:00 +0100 <ski> (or `␃', yes)
2023-11-29 21:13:01 +0100 <EvanR> never seen that one before xD
2023-11-29 21:13:15 +0100 <tomsmeding> 03yes you have
2023-11-29 21:13:19 +0100 <EvanR> wtf
2023-11-29 21:13:46 +0100 <tomsmeding> https://modern.ircdocs.horse/formatting.html#color
2023-11-29 21:13:56 +0100ski11idly 07glances 13around
2023-11-29 21:14:18 +0100 <tomsmeding> EvanR: this is how haskellbridge does the coloured nicks :p
2023-11-29 21:15:03 +0100 <EvanR> when did all this happen
2023-11-29 21:15:09 +0100 <ski> since mIRC days
2023-11-29 21:15:21 +0100 <EvanR> I'm still recovering from ESC m
2023-11-29 21:15:21 +0100 <ski> it's not anything new
2023-11-29 21:15:38 +0100 <ski> (some of the other markup are new, though)
2023-11-29 21:15:46 +0100 <tomsmeding> bold
2023-11-29 21:15:59 +0100 <EvanR> how are you entering that
2023-11-29 21:16:03 +0100 <tomsmeding> italics are not always supported in terminals
2023-11-29 21:16:39 +0100 <tomsmeding> weechat has a hotkey, 'ctrl-c, c' produces a \x03 byte; but this depends on your client
2023-11-29 21:16:56 +0100 <tomsmeding> so to get bold I type ctrl-c, c, b, o, l, d, ctrl-c, o
2023-11-29 21:17:12 +0100 <tomsmeding> in irssi it's ctrl-c and ctrl-o iirc
2023-11-29 21:17:20 +0100 <tomsmeding> from a previous conversation about this :D
2023-11-29 21:17:48 +0100 <[exa]> oh irc colors are back, 1990 vibes
2023-11-29 21:17:48 +0100 <EvanR> bold
2023-11-29 21:18:09 +0100 <EvanR> I'm left out in the bold
2023-11-29 21:18:29 +0100trev(~trev@user/trev) (Quit: trev)
2023-11-29 21:18:40 +0100 <tomsmeding> (don't see any control characters, if that was your intention)
2023-11-29 21:18:46 +0100 <ski> (i believe BboldB,_underlinedB,VinverseV are quite old, while ]italicized],FblinkingF,^strukthrough^,QmonospacedQ are newer)
2023-11-29 21:19:00 +0100 <tomsmeding> how much effort took it to enter that
2023-11-29 21:19:04 +0100 <ski> yes
2023-11-29 21:19:09 +0100 <tomsmeding> right
2023-11-29 21:20:27 +0100 <ski> <https://modern.ircdocs.horse/formatting.html#characters>,<https://www.mirc.com/help/html/control_codes.html>,<https://www.mirc.com/colors.html>,<https://web.archive.org/web/20120211151852/http://ircle.com:80/colorfaq.shtml>
2023-11-29 21:20:40 +0100 <dminuoso_> Im getting an error `[...] This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance`
2023-11-29 21:20:43 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net)
2023-11-29 21:20:47 +0100 <ski> (note that the last link talks about a different (incompatible) color coding scheme)
2023-11-29 21:21:10 +0100 <dminuoso_> Before it just says "The constraint C matches an instance declaration D"
2023-11-29 21:21:12 +0100lbseale(~quassel@user/ep1ctetus)
2023-11-29 21:21:29 +0100 <dminuoso_> This is quite the terrible diagnostic, it really doesnt tell me whats going on or why its bad
2023-11-29 21:21:34 +0100 <tomsmeding> yeah, I knew which diagnostic that message fragment was from :p
2023-11-29 21:21:37 +0100 <tomsmeding> why it's bad I also don't know
2023-11-29 21:22:03 +0100 <geekosaur> I think it's described in the users guide under MonoLocalBinds
2023-11-29 21:22:30 +0100 <ski> tomsmeding : fwiw, most of the effort there was to not only turn on and off the markup formatting, but also to explicitly display which control codes were needed to do that
2023-11-29 21:22:47 +0100 <tomsmeding> ski: I recognised that, hence my response :p
2023-11-29 21:24:04 +0100skiidly wonders what `C' and `D' would be, here
2023-11-29 21:24:23 +0100 <dminuoso_> • The constraint ‘GenericMode AsApi’ matches instance GenericMode AsApi -- Defined in ‘Servant.API.Generic’
2023-11-29 21:24:29 +0100 <geekosaur> https://downloads.haskell.org/ghc/9.8.1/docs/users_guide/exts/let_generalisation.html
2023-11-29 21:24:39 +0100 <tomsmeding> ski: isn't C colour?
2023-11-29 21:24:56 +0100 <ski> yes (but i was speaking of dminuoso_'s issue there)
2023-11-29 21:25:01 +0100 <tomsmeding> ah
2023-11-29 21:25:36 +0100nate4(~nate@c-98-45-158-125.hsd1.ca.comcast.net) (Ping timeout: 268 seconds)
2023-11-29 21:25:55 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:f8e2:da48:b27b:3920)
2023-11-29 21:26:12 +0100 <dminuoso_> geekosaur: Yeah even with that user guide, I cant figure out whats going on here.
2023-11-29 21:26:46 +0100 <dminuoso_> It feels like "fragility" is something you might find in some exotic paper on the subject.
2023-11-29 21:27:06 +0100 <dminuoso_> I mean yes. the constraint "GenericMode AsApi" matches "instance GenericMode AsApi".
2023-11-29 21:27:21 +0100 <dminuoso_> And "Functor Maybe" matches "instance Functor Maybe"
2023-11-29 21:27:45 +0100 <dminuoso_> The way GHC presents this error, it suggests that constraints matching instances is a deep problem.
2023-11-29 21:27:51 +0100 <dminuoso_> As if this should never occur.
2023-11-29 21:27:52 +0100 <ski> the matrix bridge (in the earlier mode, before the change), would use monospace, i assume for fragments that were entered in some kind of quotes, but then wouldn't use it again to turn it off, but rather just use "turn off all color and markup" (being `O') .. with the result that i could see where the monospaced part started (since my client displayed it as `Q', not understanding that escape code),
2023-11-29 21:27:58 +0100 <ski> while, otoh, not being able to see where it ended (since `O' is recognized)
2023-11-29 21:28:21 +0100 <tomsmeding> I think it's mostly not about trivial constraints like 'Functor Maybe', but more about things like 'Semigroup (Maybe a)', which is apparently (?) more fragile (?) than 'Semigroup a'
2023-11-29 21:28:45 +0100 <ski> `FlexibleConstraints' ?
2023-11-29 21:28:54 +0100 <geekosaur> is either a GADT or a type family involved? I get the impression those are the fragile ones
2023-11-29 21:29:05 +0100 <ski> (er, s/Constraints/Contexts/)
2023-11-29 21:29:38 +0100 <dminuoso_> ski: Its on, yes. My main issue here is just that GHC isnt really communicating whats going on.
2023-11-29 21:29:51 +0100 <ski> yes
2023-11-29 21:30:07 +0100 <dminuoso_> It feels like the condition "constraint C matches instance D" is problematic under a very specific inference... thing.
2023-11-29 21:30:08 +0100 <ski> would be interesting to see a, perhaps minimal, example of this in action
2023-11-29 21:30:13 +0100 <tomsmeding> well, it's communicating that you shouldn't do this, but not why
2023-11-29 21:30:16 +0100 <dminuoso_> But GHC is completely silent on what the "very specific inference thing is"
2023-11-29 21:30:22 +0100 <tomsmeding> yep
2023-11-29 21:30:35 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-11-29 21:30:50 +0100 <dminuoso_> So Im carrying away "constraints should not match instances", which of course is in direct conflict with "No instance found" errors.
2023-11-29 21:31:01 +0100 <dminuoso_> GHC has a way of driving me crazy sometimes.
2023-11-29 21:31:11 +0100 <tomsmeding> constraints should not be _manually simplifiable using instances_
2023-11-29 21:31:14 +0100 <tomsmeding> that's what the error is saying
2023-11-29 21:31:18 +0100 <tomsmeding> again, why, I don't know
2023-11-29 21:32:47 +0100 <dminuoso_> Okay as usual, a look inside GHC seems to help
2023-11-29 21:32:49 +0100 <dminuoso_> Note [Simplifiable given constraints]
2023-11-29 21:33:21 +0100 <dminuoso_> Note [Instance and Given overlap] too
2023-11-29 21:34:15 +0100 <dminuoso_> heh! that last note is referenced, but seems to have been lost/deleted.
2023-11-29 21:34:41 +0100 <dminuoso_> Some modules point to GHC.Tc.Solver.Dict, others point to TcInteract
2023-11-29 21:35:18 +0100 <dminuoso_> Ohh! No, it just uses {--} style comments, strange.
2023-11-29 21:56:45 +0100justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 256 seconds)
2023-11-29 21:57:55 +0100shapr(~user@2600:1700:c640:3100:f067:6b60:6d79:cd2d) (Remote host closed the connection)
2023-11-29 21:58:08 +0100shapr(~user@2600:1700:c640:3100:cd00:5363:89ce:baba)
2023-11-29 22:13:24 +0100mmhat(~mmh@p200300f1c71a22b9ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 268 seconds)
2023-11-29 22:13:46 +0100mmhat(~mmh@p200300f1c71a22daee086bfffe095315.dip0.t-ipconnect.de)
2023-11-29 22:17:43 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-11-29 22:28:47 +0100justsomeguy(~justsomeg@user/justsomeguy)
2023-11-29 22:38:01 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-11-29 22:40:51 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-11-29 22:43:36 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1)
2023-11-29 22:48:08 +0100dhil(~dhil@2001:8e0:2014:3100:8e3a:5299:914c:abf4) (Ping timeout: 252 seconds)
2023-11-29 22:48:08 +0100bratwurst(~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8)
2023-11-29 22:53:12 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com)
2023-11-29 22:56:38 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)
2023-11-29 22:57:02 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 252 seconds)
2023-11-29 23:03:14 +0100bratwurst(~blaadsfa@2604:3d09:207f:f650:216:3eff:fe5a:a1f8) (Remote host closed the connection)
2023-11-29 23:06:22 +0100chexum_(~quassel@gateway/tor-sasl/chexum)
2023-11-29 23:07:27 +0100alp_(~alp@2001:861:e3d6:8f80:4342:868e:5cc7:17fd) (Ping timeout: 256 seconds)
2023-11-29 23:08:00 +0100talismanick(~user@2601:204:ef00:bb0::f34e)
2023-11-29 23:08:07 +0100chexum(~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds)
2023-11-29 23:13:15 +0100peterbecich(~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 256 seconds)
2023-11-29 23:25:11 +0100justsomeguy(~justsomeg@user/justsomeguy) (Ping timeout: 264 seconds)
2023-11-29 23:30:05 +0100Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-11-29 23:32:28 +0100justsomeguy(~justsomeg@user/justsomeguy)
2023-11-29 23:33:15 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 268 seconds)
2023-11-29 23:34:34 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-11-29 23:37:21 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-11-29 23:37:42 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-29 23:38:11 +0100[_](~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds)
2023-11-29 23:40:09 +0100terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-11-29 23:44:54 +0100mengu(~mengu@c83-254-18-254.bredband.tele2.se)
2023-11-29 23:48:46 +0100coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-11-29 23:55:22 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-11-29 23:56:04 +0100acidjnk(~acidjnk@p200300d6e72b9352dcea2d781ea8e5a4.dip0.t-ipconnect.de) (Ping timeout: 276 seconds)
2023-11-29 23:56:55 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883) (Read error: Connection reset by peer)
2023-11-29 23:57:16 +0100JeremyB99(~JeremyB99@2600:1702:21b0:a500:6581:2a34:dec3:8883)