IRCBrowse

2023/05/19

2023-05-19 00:00:15 +0200comarrrrrrrrrrrr(~comarrrrr@73.237.206.60)
2023-05-19 00:04:05 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 256 seconds)
2023-05-19 00:09:45 +0200abrantesasf(~abrantesa@177.137.232.92) (Remote host closed the connection)
2023-05-19 00:22:52 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-05-19 00:22:59 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-05-19 00:25:41 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.)
2023-05-19 00:26:51 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-05-19 00:34:28 +0200acidjnk(~acidjnk@p200300d6e7072f04d4d0d87b774f7a3f.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
2023-05-19 00:49:05 +0200vandita(~vandit@193-226-238-208.pool.digikabel.hu) (Ping timeout: 240 seconds)
2023-05-19 00:50:59 +0200vandita(~vandit@92-249-150-219.static.digikabel.hu)
2023-05-19 00:52:23 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 264 seconds)
2023-05-19 00:57:10 +0200mechap(~mechap@user/mechap) (Quit: WeeChat 3.8)
2023-05-19 01:03:03 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net)
2023-05-19 01:11:33 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 01:11:59 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-05-19 01:14:06 +0200xameer(~xameer@144.48.224.179) (Remote host closed the connection)
2023-05-19 01:14:22 +0200xameer(~xameer@144.48.224.179)
2023-05-19 01:14:41 +0200Inst__(~Inst@2601:6c4:4081:2fc0:4f54:13aa:bf33:bb41)
2023-05-19 01:14:45 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 240 seconds)
2023-05-19 01:15:45 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 01:17:31 +0200Inst_(~Inst@2601:6c4:4081:2fc0:4f54:13aa:bf33:bb41) (Ping timeout: 240 seconds)
2023-05-19 01:20:34 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-05-19 01:25:08 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 01:31:21 +0200xff0x(~xff0x@2405:6580:b080:900:7953:b19f:2f45:6449) (Ping timeout: 256 seconds)
2023-05-19 01:32:46 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2023-05-19 01:33:04 +0200xff0x(~xff0x@178.255.149.135)
2023-05-19 01:33:15 +0200mauke_(~mauke@user/mauke)
2023-05-19 01:33:28 +0200mncheck(~mncheck@193.224.205.254) (Ping timeout: 240 seconds)
2023-05-19 01:35:17 +0200cheater(~Username@user/cheater) (Read error: Connection reset by peer)
2023-05-19 01:35:19 +0200mauke(~mauke@user/mauke) (Ping timeout: 265 seconds)
2023-05-19 01:35:19 +0200mauke_mauke
2023-05-19 01:36:02 +0200cheater(~Username@user/cheater)
2023-05-19 01:36:33 +0200zeenk(~zeenk@2a02:2f04:a105:f00::7fe) (Quit: Konversation terminated!)
2023-05-19 01:37:01 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 240 seconds)
2023-05-19 01:40:48 +0200evincar(~evincar@user/evincar) (Ping timeout: 240 seconds)
2023-05-19 01:45:42 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net) (Quit: Client closed)
2023-05-19 01:48:23 +0200abrar(~abrar@pool-72-78-199-186.phlapa.fios.verizon.net)
2023-05-19 01:52:23 +0200xff0x(~xff0x@178.255.149.135) (Ping timeout: 240 seconds)
2023-05-19 01:52:59 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-05-19 01:52:59 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-05-19 01:52:59 +0200wroathe(~wroathe@user/wroathe)
2023-05-19 01:54:32 +0200xff0x(~xff0x@2405:6580:b080:900:7953:b19f:2f45:6449)
2023-05-19 01:57:11 +0200evincar(~evincar@user/evincar)
2023-05-19 01:58:00 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 01:59:30 +0200darchitect(~darchitec@2a00:23c6:3584:df01:617c:9829:ef2d:1384)
2023-05-19 02:00:58 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-19 02:02:13 +0200abrar(~abrar@pool-72-78-199-186.phlapa.fios.verizon.net) (Quit: WeeChat 3.7.1)
2023-05-19 02:02:23 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 02:03:04 +0200abrar(~abrar@pool-72-78-199-186.phlapa.fios.verizon.net)
2023-05-19 02:04:13 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 256 seconds)
2023-05-19 02:07:05 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-19 02:09:36 +0200 <xameer> Hi , could anyone here share a good reference to yahb2 ?
2023-05-19 02:09:54 +0200 <xameer> It's commands
2023-05-19 02:11:34 +0200 <ski> GHCi
2023-05-19 02:12:08 +0200 <ski> (prefix `% ' in front of the GHCi commands)
2023-05-19 02:12:40 +0200 <probie> % :?
2023-05-19 02:12:40 +0200 <yahb2> Commands available from the prompt: ; ; <statement> evaluate/run <statement> ; : repeat last command ; :{\n ..lines.. \n:}\n multiline comm...
2023-05-19 02:13:09 +0200 <int-e> https://downloads.haskell.org/~ghc/9.2.5/docs/html/users_guide/ghci.html
2023-05-19 02:13:35 +0200 <int-e> % GHC.Version.cProjectVersion
2023-05-19 02:13:35 +0200 <yahb2> "9.2.5"
2023-05-19 02:18:06 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 02:19:12 +0200 <probie> Is there a canonical name for something like `class F t where fun :: (forall a b . f a b -> g a b) -> t f -> t g`. Functor2 I suppose?
2023-05-19 02:22:25 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 02:28:38 +0200jmdaemon(~jmdaemon@user/jmdaemon)
2023-05-19 02:29:43 +0200shapr(~user@76.29.230.19) (Ping timeout: 256 seconds)
2023-05-19 02:35:18 +0200rf(~rf@2605:59c8:179c:f610:aa75:7d92:845a:e973)
2023-05-19 02:39:35 +0200jmdaemon(~jmdaemon@user/jmdaemon) (Ping timeout: 240 seconds)
2023-05-19 02:39:49 +0200xameer`(~user@144.48.224.179)
2023-05-19 02:42:40 +0200 <xameer`> bwrap-files/make-chroot.sh
2023-05-19 02:42:47 +0200 <xameer`> 2+2
2023-05-19 02:44:12 +0200xameer`(~user@144.48.224.179) (Remote host closed the connection)
2023-05-19 02:46:08 +0200vandita(~vandit@92-249-150-219.static.digikabel.hu) (Ping timeout: 240 seconds)
2023-05-19 02:48:18 +0200vandita(~vandit@92-249-150-197.static.digikabel.hu)
2023-05-19 02:53:07 +0200califax(~califax@user/califx) (Remote host closed the connection)
2023-05-19 02:54:12 +0200califax(~califax@user/califx)
2023-05-19 03:10:58 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-19 03:16:58 +0200wroathe(~wroathe@user/wroathe) (Ping timeout: 250 seconds)
2023-05-19 03:17:07 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-19 03:21:51 +0200esph(~weechat@104.207.141.174) (Ping timeout: 256 seconds)
2023-05-19 03:30:20 +0200juano(~juano@189.172.239.161)
2023-05-19 03:34:05 +0200 <juano> Reese from Malcolm in the Middle gets seduced by Mrs. Edna Skilton from Regina, Saskatchewan! He fills her love canal full of his turds and then screws the shit out of her! Dewey listens through the walls and asks Malcolm, who is shellshocked, if he can heat up some hot pockets for that crazy lady! Season 8 Episode 1 https://justpaste.it/Reese_Fucks_Edna_Skilton_Malcolm
2023-05-19 03:36:13 +0200juano(~juano@189.172.239.161) (K-Lined)
2023-05-19 03:36:53 +0200evincar(~evincar@user/evincar) (Ping timeout: 250 seconds)
2023-05-19 03:44:01 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds)
2023-05-19 03:47:30 +0200 <DigitalKiwi> https://i.imgur.com/pO6eZ8b.png
2023-05-19 03:48:08 +0200 <DigitalKiwi> haskell on dos > haskell on windows
2023-05-19 03:50:48 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 03:55:01 +0200 <pavonia> Oh, good old memories
2023-05-19 03:55:05 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 03:55:35 +0200cheater_(~Username@user/cheater)
2023-05-19 03:57:57 +0200evincar(~evincar@user/evincar)
2023-05-19 03:57:59 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 03:58:01 +0200cheater_cheater
2023-05-19 04:03:14 +0200bilegeek(~bilegeek@2600:1008:b067:ea26:84a2:b278:96d5:fcf7)
2023-05-19 04:08:54 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2023-05-19 04:09:36 +0200td_(~td@i5387093A.versanet.de) (Read error: Connection reset by peer)
2023-05-19 04:09:48 +0200[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer)
2023-05-19 04:10:44 +0200xff0x(~xff0x@2405:6580:b080:900:7953:b19f:2f45:6449) (Ping timeout: 246 seconds)
2023-05-19 04:11:01 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds)
2023-05-19 04:13:04 +0200td_(~td@i53870931.versanet.de)
2023-05-19 04:13:31 +0200xameer(~xameer@144.48.224.179) (Ping timeout: 240 seconds)
2023-05-19 04:27:21 +0200img(~img@user/img)
2023-05-19 04:31:23 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:4c1f:3b38:25a9:d6c3)
2023-05-19 04:32:54 +0200cheater_(~Username@user/cheater)
2023-05-19 04:35:08 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2023-05-19 04:35:16 +0200cheater__(~Username@user/cheater)
2023-05-19 04:35:25 +0200img(~img@user/img)
2023-05-19 04:35:59 +0200cheater(~Username@user/cheater) (Ping timeout: 268 seconds)
2023-05-19 04:36:02 +0200cheater__cheater
2023-05-19 04:36:03 +0200emmanuelux_(~emmanuelu@user/emmanuelux)
2023-05-19 04:37:11 +0200cheater_(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 04:38:47 +0200emmanuelux(~emmanuelu@user/emmanuelux) (Ping timeout: 240 seconds)
2023-05-19 04:41:34 +0200_leo___(~emmanuelu@user/emmanuelux)
2023-05-19 04:41:49 +0200 <albet70> filter g $ filter f alist ==?
2023-05-19 04:42:07 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::) (Quit: The Lounge - https://thelounge.chat)
2023-05-19 04:43:04 +0200cheater_(~Username@user/cheater)
2023-05-19 04:43:32 +0200terrorjack(~terrorjac@2a01:4f8:c17:87f8::)
2023-05-19 04:44:47 +0200emmanuelux_(~emmanuelu@user/emmanuelux) (Ping timeout: 265 seconds)
2023-05-19 04:45:11 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 04:45:16 +0200cheater__(~Username@user/cheater)
2023-05-19 04:45:16 +0200cheater__cheater
2023-05-19 04:46:33 +0200nate2(~nate@98.45.169.16)
2023-05-19 04:47:59 +0200cheater_(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 04:51:29 +0200econo(uid147250@user/econo) (Quit: Connection closed for inactivity)
2023-05-19 04:53:49 +0200finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-05-19 04:53:49 +0200FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-05-19 04:53:49 +0200finn_elijaFinnElija
2023-05-19 04:55:58 +0200 <ski> albet70 : `filter (\x -> f x && g x) alist'
2023-05-19 04:56:41 +0200comarrrrrrrrrrrr(~comarrrrr@73.237.206.60) (Remote host closed the connection)
2023-05-19 04:57:07 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-05-19 04:58:06 +0200_leo___(~emmanuelu@user/emmanuelux) (Quit: au revoir)
2023-05-19 04:59:26 +0200xameer(~xameer@144.48.224.179)
2023-05-19 05:08:09 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 05:12:40 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 250 seconds)
2023-05-19 05:19:35 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:d08e:309f:8c89:9b36) (Ping timeout: 265 seconds)
2023-05-19 05:25:57 +0200rf(~rf@2605:59c8:179c:f610:aa75:7d92:845a:e973) (Remote host closed the connection)
2023-05-19 05:34:16 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 05:34:30 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-05-19 05:41:15 +0200 <Inst__> any idea how to speed this up any further?
2023-05-19 05:41:16 +0200 <Inst__> https://paste.tomsmeding.com/UvhAZk9q
2023-05-19 05:41:20 +0200 <Inst__> i mean, without resorting to matrices
2023-05-19 05:41:25 +0200 <Inst__> here, we're about, ummm
2023-05-19 05:41:40 +0200 <Inst__> 30-40% slower than Julia
2023-05-19 05:42:31 +0200 <Inst__> you actually get the opposite result when working with the Integer type, but w/e, can't be helped
2023-05-19 05:48:47 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-05-19 05:51:04 +0200 <probie> How are you timing it?
2023-05-19 05:51:39 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net)
2023-05-19 05:52:06 +0200 <probie> and can you output the assembly that Julia is generating?
2023-05-19 05:52:26 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-05-19 05:54:11 +0200 <Inst__> tasty-bench
2023-05-19 05:55:51 +0200 <Inst__> julian;
2023-05-19 05:55:53 +0200 <Inst__> https://godbolt.org/z/E1e8co76T
2023-05-19 05:57:19 +0200freeside_(~mengwong@122.11.212.99)
2023-05-19 05:57:19 +0200 <Inst__> ours
2023-05-19 05:57:22 +0200 <Inst__> https://godbolt.org/z/djxo7bfGq
2023-05-19 05:59:20 +0200 <Inst__> https://godbolt.org/z/Pfa9jaeTG
2023-05-19 05:59:23 +0200 <Inst__> slightly revised, ours
2023-05-19 06:01:40 +0200 <Inst__> ehhh, is there some way to pull ahead? I guess I briefly got deluded by the fact that if you rig it to work on integer return type, the Haskell is more efficient, probably because our bigNum type is better
2023-05-19 06:06:07 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 06:07:08 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 240 seconds)
2023-05-19 06:07:23 +0200 <DigitalKiwi> Inst__: buy a faster computer
2023-05-19 06:07:38 +0200 <Inst__> doesn't change the relative performance of julia vs haskell
2023-05-19 06:07:47 +0200 <Inst__> anyways, the C assembly is so beautiful
2023-05-19 06:07:48 +0200 <Inst__> https://godbolt.org/z/ozzzb1Wz6
2023-05-19 06:08:01 +0200 <DigitalKiwi> oh i hadn't reaed that far lol
2023-05-19 06:08:05 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-05-19 06:08:09 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-05-19 06:08:34 +0200 <probie> I don't think you can easily make GHC faster here. GHC isn't producing particularly slow code, but it's saving `rightAcc` via the stack, whilst Julia has just put aside an extra register for that.
2023-05-19 06:08:55 +0200 <DigitalKiwi> buy a slower computer and use julia don't waste time making the haskell faster and go spend time with your friends
2023-05-19 06:09:54 +0200 <DigitalKiwi> ...buy a reallllly expensive computer and use haskell anyway even though julia is faster lol
2023-05-19 06:10:39 +0200 <probie> You might be able to beat Julia by manually unrolling the loop, but that's probably cheating (since I'm pretty sure the only reason Julia hasn't unrolled the loop is because it's not sure how big/small `n` is going to be) :p
2023-05-19 06:12:29 +0200 <Inst__> the more stunning observation from benchmarking this
2023-05-19 06:12:32 +0200vglfr(~vglfr@209.198.137.192) (Ping timeout: 246 seconds)
2023-05-19 06:12:37 +0200 <Inst__> is how much faster the accparam version is if you strict it
2023-05-19 06:12:40 +0200 <Inst__> otherwise the thunks pile up
2023-05-19 06:12:49 +0200 <Inst__> the benchmark is 35 ns per run under strict
2023-05-19 06:13:00 +0200 <Inst__> 35 ms per run without the bangs?
2023-05-19 06:13:52 +0200 <Inst__> well, actually closer to 778 us
2023-05-19 06:14:05 +0200xameer(~xameer@144.48.224.179) (Ping timeout: 240 seconds)
2023-05-19 06:14:21 +0200freeside_(~mengwong@122.11.212.99) (Read error: Connection reset by peer)
2023-05-19 06:14:40 +0200 <Inst__> 462 ns vs 35 ns with and without stricting
2023-05-19 06:14:55 +0200 <Inst__> iirc the bangs add an overhead, right?
2023-05-19 06:16:46 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:9c37:7744:24df:2b60)
2023-05-19 06:18:11 +0200 <probie> Inst__: sort of? The bangs in your `go` for `fibTab` are effectively "free" here. You pay the cost once for `n` when you call `fibTab` (and you'd have had to pay it anyway to pattern match against it).
2023-05-19 06:18:46 +0200 <Inst__> i guess, but `seq` gets expensive quickly, no?
2023-05-19 06:18:56 +0200 <Inst__> the let foo = ... in seq foo foo
2023-05-19 06:21:39 +0200 <probie> `seq` (and bang patterns) aren't free, but if something is already known to be in whnf, the compiler can erase the call to `seq`
2023-05-19 06:26:07 +0200 <davean> They're not free but they're a prepayment that can come at a discount.
2023-05-19 06:27:43 +0200 <Inst__> this is just interesting to know because i use accumulating parameter idiom a lot
2023-05-19 06:28:09 +0200 <Inst__> i was just really shocked that we managed to somehow mildly outperform julia on bigint
2023-05-19 06:28:16 +0200 <Inst__> or rather Integer vs Big
2023-05-19 06:29:00 +0200 <davean> oh have you used the LLVM backend yet?
2023-05-19 06:29:08 +0200 <davean> that can help this specific sort of code.
2023-05-19 06:30:08 +0200 <davean> Its been a while since I optimized Haskell on this level sadly.
2023-05-19 06:30:09 +0200 <probie> Inst__: By default, GHC uses gmp for `Integer`, which is known to be pretty fast. I'm not sure if Julia uses gmp or rolls their own, but it's unlikely to be faster
2023-05-19 06:30:10 +0200 <davean> I'm rusty
2023-05-19 06:30:29 +0200 <Inst__> i'm on windows :(
2023-05-19 06:31:05 +0200 <Inst__> and not going to go al lthe way to LLVM / do my dual boot, once I saw the gcc C version, I sort of lost interest
2023-05-19 06:31:59 +0200 <davean> -fregs-graph ?
2023-05-19 06:32:10 +0200 <davean> -fregs-graph ?
2023-05-19 06:32:37 +0200 <Inst__> -fregs-graph?
2023-05-19 06:33:10 +0200 <davean> I'm too rusty to be sure what ticklets what ATM but thats an option that changes the register allocation pass.
2023-05-19 06:33:38 +0200 <davean> I forget whats default, what catches what, etc. I've been doing much higher level optimizations.
2023-05-19 06:34:27 +0200 <davean> It wasn't in -O2 for a while at least
2023-05-19 06:34:51 +0200 <Inst__> added freqs-graph
2023-05-19 06:35:03 +0200captnemo(~captnemo@193.32.127.232) (Quit: WeeChat 3.8)
2023-05-19 06:35:54 +0200 <Inst__> stabilized around 33 seconds, vs previous 35 seconds, but could have been affected by what else was running on the machine
2023-05-19 06:36:11 +0200 <davean> yah ok, that didn't do the thing I hoped it might
2023-05-19 06:37:23 +0200evincar(~evincar@user/evincar) (Ping timeout: 264 seconds)
2023-05-19 06:38:38 +0200evincar(~evincar@user/evincar)
2023-05-19 06:40:32 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:9c37:7744:24df:2b60) (Ping timeout: 248 seconds)
2023-05-19 06:43:57 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 06:45:23 +0200freeside_(~mengwong@122.11.135.1)
2023-05-19 06:45:37 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:9c37:7744:24df:2b60)
2023-05-19 06:48:09 +0200 <probie> davean: `-fregs-graph` did the right thing (at least on godbolt). It no longer uses the stack when it doesn't need to
2023-05-19 06:52:58 +0200 <probie> unfortunately GHC still generates an additional `testq` op, which Julia doesn't, and I don't think there's a way to get rid of that (although I think the llvm backend might?)
2023-05-19 06:54:49 +0200 <probie> (it's extra, because you've actually set the flags you want to test against as part of the `n - 1`, but even with the args reordered to make sure that op is at the end, it generates `decq %r14 testq %r14,%r14`
2023-05-19 06:57:38 +0200 <davean> probie: oh! Ok, so I'm rusty but not THAT rusty
2023-05-19 06:58:07 +0200 <davean> I expect llvm would elide that
2023-05-19 07:06:01 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 240 seconds)
2023-05-19 07:06:26 +0200kimjetwav(~user@2607:fea8:235e:b600:7132:be12:79fb:18e8)
2023-05-19 07:11:59 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-05-19 07:13:10 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 07:27:47 +0200freeside_(~mengwong@122.11.135.1) (Ping timeout: 264 seconds)
2023-05-19 07:38:58 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net)
2023-05-19 07:40:57 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-05-19 07:45:43 +0200nate2(~nate@98.45.169.16)
2023-05-19 07:47:26 +0200xameer(~xameer@144.48.224.179)
2023-05-19 07:50:01 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-05-19 07:53:07 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-05-19 07:55:49 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Read error: Connection reset by peer)
2023-05-19 07:57:34 +0200takuan(~takuan@178-116-218-225.access.telenet.be)
2023-05-19 08:00:26 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 08:04:47 +0200shriekingnoise(~shrieking@186.137.175.87) (Ping timeout: 240 seconds)
2023-05-19 08:05:36 +0200michalz(~michalz@185.246.204.73)
2023-05-19 08:06:16 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 268 seconds)
2023-05-19 08:08:02 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67)
2023-05-19 08:10:09 +0200bilegeek(~bilegeek@2600:1008:b067:ea26:84a2:b278:96d5:fcf7) (Quit: Leaving)
2023-05-19 08:12:47 +0200mncheck(~mncheck@193.224.205.254)
2023-05-19 08:12:54 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 08:14:35 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 264 seconds)
2023-05-19 08:15:59 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds)
2023-05-19 08:18:02 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net)
2023-05-19 08:25:45 +0200viwor(~Thunderbi@IGLD-83-130-212-68.inter.net.il) (Quit: viwor)
2023-05-19 08:26:39 +0200iteratee(~kyle@162.218.222.207) (Read error: Connection reset by peer)
2023-05-19 08:26:50 +0200iteratee(~kyle@162.218.222.207)
2023-05-19 08:29:28 +0200vandita(~vandit@92-249-150-197.static.digikabel.hu) (Ping timeout: 240 seconds)
2023-05-19 08:30:39 +0200lottaquestions(~nick@2607:fa49:503f:6d00:5204:d8f3:4fdf:6a82)
2023-05-19 08:31:20 +0200vandita(~vandit@91-83-3-38.pool.digikabel.hu)
2023-05-19 08:31:41 +0200bontaq(~user@ool-45779b84.dyn.optonline.net)
2023-05-19 08:32:23 +0200lottaquestions_(~nick@2607:fa49:503f:6d00:e12c:3339:1e68:4fd9) (Ping timeout: 256 seconds)
2023-05-19 08:34:51 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
2023-05-19 08:35:10 +0200hrberg(~quassel@171.79-160-161.customer.lyse.net)
2023-05-19 08:35:30 +0200acidjnk(~acidjnk@p200300d6e7072f02cd847e0b0d4a295b.dip0.t-ipconnect.de)
2023-05-19 08:37:05 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 240 seconds)
2023-05-19 08:39:50 +0200vpan(~0@mail.elitnet.lt)
2023-05-19 08:50:24 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-19 08:52:52 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-05-19 08:54:30 +0200trev(~trev@user/trev)
2023-05-19 08:54:58 +0200coot_(~coot@89-69-206-216.dynamic.chello.pl)
2023-05-19 08:56:23 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 240 seconds)
2023-05-19 08:57:03 +0200CiaoSen(~Jura@dynamic-046-114-218-076.46.114.pool.telefonica.de)
2023-05-19 08:57:35 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Ping timeout: 240 seconds)
2023-05-19 08:57:35 +0200coot_coot
2023-05-19 09:06:25 +0200gnalzo(~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-05-19 09:10:59 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net)
2023-05-19 09:12:03 +0200zeenk(~zeenk@2a02:2f04:a105:f00::7fe)
2023-05-19 09:12:08 +0200azimut(~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds)
2023-05-19 09:16:01 +0200mauke(~mauke@user/mauke) (Ping timeout: 256 seconds)
2023-05-19 09:20:08 +0200mc47(~mc47@xmonad/TheMC47)
2023-05-19 09:20:30 +0200Inst__(~Inst@2601:6c4:4081:2fc0:4f54:13aa:bf33:bb41) (Read error: Connection reset by peer)
2023-05-19 09:22:29 +0200freeside_(~mengwong@122.11.248.245)
2023-05-19 09:23:28 +0200hsw(~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) (Ping timeout: 240 seconds)
2023-05-19 09:28:44 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-05-19 09:30:32 +0200hsw(~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net)
2023-05-19 09:33:37 +0200mmhat(~mmh@p200300f1c7066878ee086bfffe095315.dip0.t-ipconnect.de)
2023-05-19 09:33:46 +0200mmhat(~mmh@p200300f1c7066878ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2023-05-19 09:37:42 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:4c1f:3b38:25a9:d6c3) (Remote host closed the connection)
2023-05-19 09:39:01 +0200evincar(~evincar@user/evincar) (Ping timeout: 240 seconds)
2023-05-19 09:42:17 +0200potato44(uid421314@2a03:5180:f:2::6:6dc2) (Quit: Connection closed for inactivity)
2023-05-19 09:42:19 +0200alternateved(~user@77-253-195-69.adsl.inetia.pl)
2023-05-19 09:42:42 +0200gmg(~user@user/gehmehgeh)
2023-05-19 09:45:42 +0200Guest|77(~Guest|77@92.255.240.18)
2023-05-19 09:46:21 +0200Guest|77(~Guest|77@92.255.240.18) (Client Quit)
2023-05-19 09:49:32 +0200harveypwca(~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving)
2023-05-19 10:01:05 +0200CiaoSen(~Jura@dynamic-046-114-218-076.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-05-19 10:01:28 +0200phma_(~phma@2001:5b0:211f:ac38:3175:c9e:af7a:b437)
2023-05-19 10:03:18 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:9c37:7744:24df:2b60) (Ping timeout: 265 seconds)
2023-05-19 10:03:34 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 10:03:37 +0200phma(phma@2001:5b0:211f:7e48:7766:33a8:8fd1:3dba) (Ping timeout: 256 seconds)
2023-05-19 10:05:18 +0200ubert(~Thunderbi@2001:871:263:e49d:d09b:76e5:9a99:b8ab)
2023-05-19 10:07:29 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net)
2023-05-19 10:09:51 +0200evincar(~evincar@user/evincar)
2023-05-19 10:10:08 +0200Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-05-19 10:10:25 +0200vglfr(~vglfr@209.198.137.192) (Ping timeout: 256 seconds)
2023-05-19 10:11:35 +0200Feuermagier(~Feuermagi@user/feuermagier) (Ping timeout: 240 seconds)
2023-05-19 10:12:36 +0200chele(~chele@user/chele)
2023-05-19 10:13:09 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 10:13:16 +0200coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-05-19 10:14:24 +0200evincar(~evincar@user/evincar) (Ping timeout: 248 seconds)
2023-05-19 10:26:10 +0200titibandit(~titibandi@user/titibandit)
2023-05-19 10:26:47 +0200vglfr(~vglfr@209.198.137.192) (Ping timeout: 240 seconds)
2023-05-19 10:27:01 +0200evincar(~evincar@user/evincar)
2023-05-19 10:28:57 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de)
2023-05-19 10:30:15 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 10:31:35 +0200evincar(~evincar@user/evincar) (Ping timeout: 240 seconds)
2023-05-19 10:38:08 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4)
2023-05-19 10:42:26 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4) (Ping timeout: 250 seconds)
2023-05-19 10:42:26 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 10:42:49 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 10:43:37 +0200mechap(~mechap@user/mechap)
2023-05-19 10:43:57 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz)
2023-05-19 10:43:59 +0200 <absence> is there a way to get around the ambiguousness of the update functions? the get functions are not ambiguous... https://play.haskell.org/saved/sqDxEZxD
2023-05-19 10:47:51 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915)
2023-05-19 10:48:45 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds)
2023-05-19 10:49:09 +0200Lord_of_Life_Lord_of_Life
2023-05-19 10:50:13 +0200CiaoSen(~Jura@dynamic-046-114-218-076.46.114.pool.telefonica.de)
2023-05-19 10:51:39 +0200 <Profpatsch> Something that’s been preoccupying me
2023-05-19 10:53:05 +0200 <Profpatsch> nvm, I think it’s too hard to describe
2023-05-19 10:53:29 +0200 <sm> heh
2023-05-19 10:53:50 +0200phma_(~phma@2001:5b0:211f:ac38:3175:c9e:af7a:b437) (Read error: Connection reset by peer)
2023-05-19 10:54:24 +0200phma_(~phma@host-67-44-208-41.hnremote.net)
2023-05-19 10:57:11 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-05-19 11:00:52 +0200 <jackdk> absence: See https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0366-no-ambiguous-field-acces… ; there's an open proposal that's relevant: https://github.com/ghc-proposals/ghc-proposals/pull/537
2023-05-19 11:03:27 +0200titiband1t(~titibandi@user/titibandit)
2023-05-19 11:04:01 +0200inversed(~inversed@bcdcac82.skybroadband.com) (Ping timeout: 240 seconds)
2023-05-19 11:13:43 +0200__monty__(~toonn@user/toonn)
2023-05-19 11:13:51 +0200 <absence> jackdk: thanks, i'll have a look!
2023-05-19 11:15:26 +0200Inst(~Inst@2601:6c4:4081:2fc0:29d6:ec38:cf28:128e)
2023-05-19 11:15:36 +0200 <Inst> hmmm,m i'm wondering, what the hell is wrong with my accumulating parameter?
2023-05-19 11:16:04 +0200 <Inst> basically, if I'm looking at the Julian version, they seem to have a (O)log n time complexity on the arithmetic
2023-05-19 11:16:08 +0200 <Inst> the Haskell version is roughly linear
2023-05-19 11:16:25 +0200 <Rembane> Inst: Maybe it's having a bad day? Can you share the code with us?
2023-05-19 11:16:50 +0200 <Inst> i'm just using Julia as an analogue for a traditional for loop
2023-05-19 11:16:59 +0200 <Inst> I'm not WSLed onto OCaml so I can't use OCaml
2023-05-19 11:17:05 +0200 <Inst> for interpreter
2023-05-19 11:18:02 +0200 <Inst> julian:
2023-05-19 11:18:03 +0200 <Inst> https://godbolt.org/z/brY3sbKE1
2023-05-19 11:18:41 +0200 <Inst> ours
2023-05-19 11:18:42 +0200 <Inst> https://godbolt.org/z/xj13e156r
2023-05-19 11:19:15 +0200 <probie> Inst: you want to pass -O2
2023-05-19 11:19:45 +0200 <probie> also, one of those is fib, the other is fac
2023-05-19 11:20:57 +0200 <Inst> weird
2023-05-19 11:20:57 +0200 <Inst> https://godbolt.org/z/ovG4KfGn9
2023-05-19 11:21:01 +0200 <Inst> julian version
2023-05-19 11:22:48 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 240 seconds)
2023-05-19 11:24:32 +0200Pickchea(~private@user/pickchea)
2023-05-19 11:24:48 +0200 <Inst> so it's probably that they have a log n optimization firing, which creates a high initial time, but my algorithm is O n
2023-05-19 11:28:47 +0200 <probie> So, when n < 16, haskell and Julia are running pretty much the same code
2023-05-19 11:31:18 +0200 <probie> when n >= 16 Julia has unrolled the loop and is doing some crazy stuff something with vector ops. I'm moderately sure it's not O(log n) though
2023-05-19 11:32:53 +0200 <probie> The llvm backend for GHC might be able to generate something similar, but I don't think it will
2023-05-19 11:34:42 +0200freeside_(~mengwong@122.11.248.245) (Ping timeout: 268 seconds)
2023-05-19 11:35:07 +0200zeenk(~zeenk@2a02:2f04:a105:f00::7fe) (Remote host closed the connection)
2023-05-19 11:35:29 +0200zeenk(~zeenk@2a02:2f04:a105:f00::fba)
2023-05-19 11:39:16 +0200ubert(~Thunderbi@2001:871:263:e49d:d09b:76e5:9a99:b8ab) (Quit: ubert)
2023-05-19 11:39:36 +0200ubert(~Thunderbi@2001:871:263:e49d:9f32:772e:1ec6:8be6)
2023-05-19 11:40:13 +0200 <stefan-_> I have an issue with some typeclass instances in pandoc
2023-05-19 11:40:26 +0200 <stefan-_> previously there was: instance (Walkable [a] Pandoc, MonadIO m) => ToJSONFilter m (a -> [a]) where ...
2023-05-19 11:40:34 +0200 <stefan-_> now there is: instance (Walkable [a] Pandoc, MonadIO m) => ToJSONFilter m (a -> m [a]) where
2023-05-19 11:40:50 +0200 <stefan-_> the application code is here: https://gist.github.com/dozed/41c4c6b74d5fc1c06c306d6e1783e762
2023-05-19 11:41:09 +0200phma_phma
2023-05-19 11:41:32 +0200 <stefan-_> is there a simpler solution to turn an `Block -> [Block]` into `Block -> IO [Block]` than the two last snippets?
2023-05-19 11:41:45 +0200 <stefan-_> -n
2023-05-19 11:42:10 +0200 <ncf> :t (pure .)
2023-05-19 11:42:11 +0200 <lambdabot> Applicative f => (a1 -> a2) -> a1 -> f a2
2023-05-19 11:43:31 +0200ubert(~Thunderbi@2001:871:263:e49d:9f32:772e:1ec6:8be6) (Ping timeout: 240 seconds)
2023-05-19 11:43:38 +0200 <ncf> toJSONFilter (pure . toList . convertBlock) -- doesn't that do it?
2023-05-19 11:43:56 +0200 <ncf> oh, ambiguous
2023-05-19 11:44:19 +0200 <ncf> you could turn on TypeApplications and do pure @IO
2023-05-19 11:45:28 +0200 <stefan-_> nice, this works: `toJSONFilter $ (pure @IO .) $ toList . convertBlock`
2023-05-19 11:45:41 +0200 <ncf> pure @IO . toList . convertBlock
2023-05-19 11:45:50 +0200 <ncf> not sure why this is necessary though, since the type of main is known...
2023-05-19 11:46:24 +0200ubert(~Thunderbi@188-23-67-228.adsl.highway.telekom.at)
2023-05-19 11:46:55 +0200nate2(~nate@98.45.169.16)
2023-05-19 11:48:41 +0200 <stefan-_> ncf, ToJSONFilter has instances given `MonadIO`: https://github.com/jgm/pandoc-types/blob/master/src/Text/Pandoc/JSON.hs
2023-05-19 11:48:51 +0200 <stefan-_> could be related to this indirection
2023-05-19 11:49:46 +0200hamzahaskell1(~hamzahask@2a01:e0a:1ee:8c60:c112:84e5:1df:32b0)
2023-05-19 11:50:44 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-05-19 11:51:41 +0200nate2(~nate@98.45.169.16) (Ping timeout: 246 seconds)
2023-05-19 11:51:51 +0200puque(~puke@user/puke)
2023-05-19 11:51:51 +0200pyook(~puke@user/puke) (Killed (zirconium.libera.chat (Nickname regained by services)))
2023-05-19 11:51:51 +0200puquepyook
2023-05-19 11:53:46 +0200gensyst(~gensyst@user/gensyst)
2023-05-19 11:54:38 +0200 <gensyst> Is there no way to keep the current thread alive in the background somehow, and schedule something to run on that thread later? (long after the "main thing" i'm currently doing on my thread is over)
2023-05-19 11:54:56 +0200 <gensyst> s/that thread/that SAME thread
2023-05-19 11:55:27 +0200 <gensyst> it'd be cool if i could do this without channels (and run EVERYTHING through the channel) because running things on a channel has overhead
2023-05-19 11:55:46 +0200 <gensyst> it'd be cool if i could at least do the "main thing" without that overhead
2023-05-19 11:56:17 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de) (Ping timeout: 268 seconds)
2023-05-19 11:57:26 +0200pyook(~puke@user/puke) (Quit: Quit)
2023-05-19 11:58:41 +0200tcard_(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving)
2023-05-19 12:00:26 +0200tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
2023-05-19 12:01:01 +0200acidjnk(~acidjnk@p200300d6e7072f02cd847e0b0d4a295b.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-05-19 12:05:12 +0200xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 250 seconds)
2023-05-19 12:05:54 +0200 <ncf> stefan-_: wait, why aren't you just using the `ToJSONFilter IO (a -> a)` instance?
2023-05-19 12:06:21 +0200 <stefan-_> ncf, the composed function is `Block -> [Block]`
2023-05-19 12:06:53 +0200 <ncf> oh
2023-05-19 12:07:05 +0200 <absence> jackdk: hm, the migration guide suggests that my code should work as is, so i guess it's outdated. the only other option seems to be to rewrite the code to not use record update syntax, which is a bit unfortunate
2023-05-19 12:09:52 +0200 <absence> is there really no way to disambiguate record updates? https://play.haskell.org/saved/sqDxEZxD
2023-05-19 12:12:19 +0200 <stefan-_> ncf, the `a -> [a]` instance has been removed some weeks ago: https://github.com/jgm/pandoc-types/commit/183af9d9f1066be974ac55fd23a4c985999d3ce8
2023-05-19 12:12:46 +0200 <carbolymer> how can I find out what cabal knows about my custom package repository? I'm trying to debug famous 'Could not resolve dependencies'...
2023-05-19 12:15:26 +0200 <sm> carbolymer: cabal exec -- ghc-pkg list maybe ?
2023-05-19 12:17:00 +0200 <carbolymer> sm: wow, that just fails with the same error
2023-05-19 12:17:49 +0200 <sm> cabal exec does ?
2023-05-19 12:18:09 +0200 <sm> not ghc-pkg list, I assume
2023-05-19 12:18:11 +0200titiband1t(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-19 12:19:24 +0200 <carbolymer> yes, that's from cabal exec
2023-05-19 12:19:37 +0200 <sm> what error I wonder
2023-05-19 12:19:50 +0200 <carbolymer> weird,if I enforced the newer index-state from command line it worked
2023-05-19 12:20:04 +0200 <carbolymer> somehow it ignored index-state from cabal.project
2023-05-19 12:20:53 +0200 <carbolymer> sm: https://bpa.st/HKX5O
2023-05-19 12:21:43 +0200 <sm> I see.. yes I guess exec has to satisfy deps too, just like build
2023-05-19 12:23:23 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-05-19 12:25:44 +0200 <sm> carbolymer: I don't know where to see the deps of these packages.. but it looks like cardano-api requires cardano-cli >=8.1.0.1, and you are are asking it to install 8.1.0
2023-05-19 12:26:18 +0200 <sm> if you're not specifying 8.1.0 on the command line, maybe you need to cabal update ?
2023-05-19 12:27:20 +0200L29Ah(~L29Ah@wikipedia/L29Ah) ()
2023-05-19 12:28:18 +0200 <carbolymer> sm: I did cabal update, I updated index-states in cabal.project
2023-05-19 12:28:39 +0200 <carbolymer> sm: I think I had an old cabal.project.freeze
2023-05-19 12:28:45 +0200 <sm> ah, right
2023-05-19 12:28:47 +0200 <carbolymer> and that could the the culprit
2023-05-19 12:29:49 +0200ardell(~ardell@user/ardell)
2023-05-19 12:30:51 +0200 <absence> the ghc documentation seems to suggest that updates to records with duplicate record fields can be disambiguated using an explicit type signature: https://downloads.haskell.org/ghc/9.2.7/docs/html/users_guide/exts/duplicate_record_fields.html#re…
2023-05-19 12:31:00 +0200 <absence> however, it doesn't seem to work: https://play.haskell.org/saved/awVx87GB
2023-05-19 12:31:08 +0200 <absence> am i misunderstanding something, or is it a possible bug?
2023-05-19 12:33:45 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2023-05-19 12:37:49 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-19 12:38:29 +0200inversed(~inversed@bcdcac82.skybroadband.com)
2023-05-19 12:42:49 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de)
2023-05-19 12:44:19 +0200inversed(~inversed@bcdcac82.skybroadband.com) (Quit: Connection error?!)
2023-05-19 12:44:56 +0200reverse(~inversed@bcdcac82.skybroadband.com)
2023-05-19 12:57:00 +0200Feuermagier(~Feuermagi@user/feuermagier)
2023-05-19 13:05:29 +0200 <dminuoso> anderson: No, its documented quite clearly
2023-05-19 13:05:57 +0200 <probie> absence: "As of GHC 9.4.1, selector names have to be entirely unambiguous (under the usual name resolution rules), while for record updates, there must be at most one datatype that has all the field names being updated."
2023-05-19 13:06:04 +0200 <probie> those docs are for 9.2.7
2023-05-19 13:06:19 +0200 <dminuoso> Though, their play.haskell.org pad uses GHC 9.2.7
2023-05-19 13:06:27 +0200 <dminuoso> But it may be, that the manual is not up to date.
2023-05-19 13:06:59 +0200 <dminuoso> The whole business of record fields and updates is one gigantic mistake. :(
2023-05-19 13:07:56 +0200 <absence> probie: i'm using ghc 9.2.7
2023-05-19 13:08:05 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 13:08:57 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection)
2023-05-19 13:09:15 +0200 <probie> absence: it seems to be working to me, apart from the warning that it's not going to be supported in future releases
2023-05-19 13:09:16 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf)
2023-05-19 13:09:44 +0200 <absence> dminuoso: the documentation isn't clear enough that i can figure out how to change the code to not produce the warning :/
2023-05-19 13:10:38 +0200 <probie> absence: short of sticking those data types in a different module to the one you're using them in, or not using record update syntax, you can't get rid of the warning.
2023-05-19 13:11:20 +0200 <dminuoso> absence: Give https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0366-no-ambiguous-field-acces… a brief read
2023-05-19 13:11:31 +0200 <dminuoso> absence: Consider RecordDotSyntax and/or HasField
2023-05-19 13:12:06 +0200 <dminuoso> The GHC does mention this proposal right in the same sentence where it says that these rules are being removed.
2023-05-19 13:12:31 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 13:13:10 +0200img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2023-05-19 13:16:04 +0200img(~img@user/img)
2023-05-19 13:18:29 +0200kimiamania(~65804703@user/kimiamania) (Quit: PegeLinux)
2023-05-19 13:19:35 +0200kimiamania(~65804703@user/kimiamania)
2023-05-19 13:26:36 +0200YoungFrog(~youngfrog@2a02:a03f:ca07:f900:89a5:6020:579e:71c0) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in)
2023-05-19 13:26:56 +0200YoungFrog(~youngfrog@2a02:a03f:ca07:f900:2511:dd1a:efe6:cefd)
2023-05-19 13:30:23 +0200ubert(~Thunderbi@188-23-67-228.adsl.highway.telekom.at) (Ping timeout: 246 seconds)
2023-05-19 13:35:07 +0200gemmaro(~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc)
2023-05-19 13:48:52 +0200acidjnk(~acidjnk@p200300d6e7072f02cde83c9df9d46ae6.dip0.t-ipconnect.de)
2023-05-19 13:49:37 +0200bitdex(~bitdex@gateway/tor-sasl/bitdex) (Quit: = "")
2023-05-19 13:51:40 +0200euandreh(~Thunderbi@189.6.18.7)
2023-05-19 13:53:08 +0200 <absence> dminuoso: i don't think OverloadedRecordDot helps, and OverloadedRecordUpdate is flagged as experimental and requires RebindableSyntax. am i understanding correctly that the warning means "things will change", but there's not alternative syntax that will avoid the warning until then? that seems to be what probie suggests as well, so i should just disable the warning and wait for OverloadedRecordUpdate to
2023-05-19 13:53:14 +0200 <absence> stabilise?
2023-05-19 14:00:31 +0200Pickchea(~private@user/pickchea) (Quit: Leaving)
2023-05-19 14:02:45 +0200ddellacosta(~ddellacos@146.70.168.196) (Ping timeout: 256 seconds)
2023-05-19 14:05:48 +0200Vajb(~Vajb@2001:999:585:423d:44d3:48b0:adae:2d85) (Ping timeout: 240 seconds)
2023-05-19 14:06:53 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 14:09:41 +0200wootehfoot(~wootehfoo@user/wootehfoot) (Quit: Leaving)
2023-05-19 14:09:55 +0200elain4(~textual@2601:5c1:4402:cd30:79c9:ede3:4f08:7c96)
2023-05-19 14:09:59 +0200chomwitt(~chomwitt@2a02:587:7a09:2000:1ac0:4dff:fedb:a3f1)
2023-05-19 14:10:34 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-05-19 14:10:41 +0200jero98772(~jero98772@2800:484:1d84:9000::2) (Ping timeout: 256 seconds)
2023-05-19 14:14:23 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 14:15:25 +0200gensyst(~gensyst@user/gensyst) (Ping timeout: 240 seconds)
2023-05-19 14:21:45 +0200jero98772(~jero98772@2800:484:1d84:9000::2)
2023-05-19 14:27:34 +0200gemmaro(~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) (Remote host closed the connection)
2023-05-19 14:31:38 +0200TMA(tma@twin.jikos.cz) (Ping timeout: 246 seconds)
2023-05-19 14:31:53 +0200TMA(tma@twin.jikos.cz)
2023-05-19 14:31:59 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 14:34:06 +0200elain4(~textual@2601:5c1:4402:cd30:79c9:ede3:4f08:7c96) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2023-05-19 14:34:24 +0200xff0x(~xff0x@ai098135.d.east.v6connect.net)
2023-05-19 14:34:42 +0200vandita(~vandit@91-83-3-38.pool.digikabel.hu) (Ping timeout: 250 seconds)
2023-05-19 14:36:41 +0200vandita(~vandit@178-164-171-248.pool.digikabel.hu)
2023-05-19 14:41:52 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4)
2023-05-19 14:42:05 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-05-19 14:42:55 +0200L29Ah(~L29Ah@wikipedia/L29Ah)
2023-05-19 14:46:24 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4) (Ping timeout: 248 seconds)
2023-05-19 14:51:38 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de)
2023-05-19 15:00:50 +0200euandreh(~Thunderbi@189.6.18.7)
2023-05-19 15:00:57 +0200Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net) (Quit: The Lounge - https://thelounge.chat)
2023-05-19 15:01:47 +0200Katarushisu(~Katarushi@cpc147790-finc20-2-0-cust502.4-2.cable.virginm.net)
2023-05-19 15:05:11 +0200euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 240 seconds)
2023-05-19 15:07:25 +0200wiosna(~karangura@c-73-93-95-154.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-05-19 15:10:34 +0200euandreh(~Thunderbi@189.6.18.7)
2023-05-19 15:14:10 +0200ardell(~ardell@user/ardell) (Quit: Konversation terminated!)
2023-05-19 15:15:59 +0200jle`(~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds)
2023-05-19 15:17:15 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-05-19 15:18:18 +0200jle`(~jle`@cpe-23-240-75-236.socal.res.rr.com)
2023-05-19 15:19:48 +0200alternateved(~user@77-253-195-69.adsl.inetia.pl) (Remote host closed the connection)
2023-05-19 15:20:22 +0200jero98772(~jero98772@2800:484:1d84:9000::2) (Ping timeout: 265 seconds)
2023-05-19 15:20:23 +0200euandreh(~Thunderbi@189.6.18.7)
2023-05-19 15:20:26 +0200alternateved(~user@77-253-195-69.adsl.inetia.pl)
2023-05-19 15:23:51 +0200 <jackdk> absence: The deprecation warning appears overly aggressive and I don't think that feature is getting fully removed until the open proposal I linked you is implemented.
2023-05-19 15:24:14 +0200mei(~mei@user/mei) (Ping timeout: 265 seconds)
2023-05-19 15:25:46 +0200troydm(~troydm@user/troydm) (Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset)
2023-05-19 15:28:51 +0200troydm(~troydm@user/troydm)
2023-05-19 15:29:54 +0200YoungFrog(~youngfrog@2a02:a03f:ca07:f900:2511:dd1a:efe6:cefd) (Quit: ZNC 1.7.x-git-3-96481995 - https://znc.in)
2023-05-19 15:30:14 +0200YoungFrog(~youngfrog@39.129-180-91.adsl-dyn.isp.belgacom.be)
2023-05-19 15:33:40 +0200jero98772(~jero98772@2800:484:1d84:9000::2)
2023-05-19 15:34:21 +0200gemmaro(~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc)
2023-05-19 15:35:08 +0200CiaoSen(~Jura@dynamic-046-114-218-076.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-05-19 15:39:18 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com)
2023-05-19 15:39:18 +0200wroathe(~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host)
2023-05-19 15:39:18 +0200wroathe(~wroathe@user/wroathe)
2023-05-19 15:40:49 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 15:44:32 +0200wroathe(~wroathe@user/wroathe) (Quit: Lost terminal)
2023-05-19 15:45:11 +0200chomwitt(~chomwitt@2a02:587:7a09:2000:1ac0:4dff:fedb:a3f1) (Ping timeout: 264 seconds)
2023-05-19 15:45:59 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 15:47:04 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 250 seconds)
2023-05-19 15:48:25 +0200nate2(~nate@98.45.169.16)
2023-05-19 15:51:50 +0200Inst(~Inst@2601:6c4:4081:2fc0:29d6:ec38:cf28:128e) (Ping timeout: 250 seconds)
2023-05-19 15:53:11 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-05-19 15:55:33 +0200machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Remote host closed the connection)
2023-05-19 16:00:00 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection)
2023-05-19 16:04:25 +0200bontaq(~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 240 seconds)
2023-05-19 16:04:31 +0200cheater(~Username@user/cheater)
2023-05-19 16:05:45 +0200xff0x(~xff0x@ai098135.d.east.v6connect.net) (Quit: xff0x)
2023-05-19 16:06:07 +0200albet70(~xxx@2400:8902::f03c:92ff:fe60:98d8)
2023-05-19 16:08:52 +0200xff0x(~xff0x@ai098135.d.east.v6connect.net)
2023-05-19 16:10:20 +0200vglfr(~vglfr@209.198.137.192) (Ping timeout: 246 seconds)
2023-05-19 16:11:16 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 16:14:28 +0200gensyst(~gensyst@user/gensyst)
2023-05-19 16:16:16 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net)
2023-05-19 16:17:02 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 16:17:44 +0200 <gensyst> hi guys, if your irc client shows the ip address of a user who just joined.. what was my ip when i joined just now?
2023-05-19 16:17:56 +0200 <gensyst> was it the ..44.22 one?
2023-05-19 16:18:39 +0200 <TMA> you are cloaked: 16:14 -!- gensyst [~gensyst@user/gensyst] has joined #haskell
2023-05-19 16:18:54 +0200 <gensyst> ah ok, cool
2023-05-19 16:18:55 +0200 <gensyst> thanks!
2023-05-19 16:20:23 +0200shriekingnoise(~shrieking@186.137.175.87)
2023-05-19 16:21:11 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 16:25:33 +0200 <ski> (iirc `/whois' on yourself shows your host/ip, but not to others, if you have a cloak/vhost)
2023-05-19 16:25:58 +0200 <gensyst> thanks guys
2023-05-19 16:29:30 +0200ddellacosta(~ddellacos@146.70.185.10)
2023-05-19 16:30:27 +0200jero98772(~jero98772@2800:484:1d84:9000::2) (Ping timeout: 265 seconds)
2023-05-19 16:37:11 +0200chomwitt(~chomwitt@athedsl-351665.home.otenet.gr)
2023-05-19 16:37:57 +0200 <gensyst> How are foreign pointers implemented under the hood?
2023-05-19 16:38:02 +0200 <gensyst> esp. the finalization
2023-05-19 16:40:23 +0200euandreh(~Thunderbi@189.6.18.7) (Ping timeout: 264 seconds)
2023-05-19 16:42:08 +0200vandita(~vandit@178-164-171-248.pool.digikabel.hu) (Ping timeout: 248 seconds)
2023-05-19 16:43:44 +0200jero98772(~jero98772@2800:484:1d84:9000::2)
2023-05-19 16:44:08 +0200vandita(~vandit@94-21-233-127.pool.digikabel.hu)
2023-05-19 16:47:02 +0200 <geekosaur> the comments in https://downloads.haskell.org/ghc/9.2.5/docs/html/libraries/base-4.16.4.0/src/GHC.ForeignPtr.html are probably the best you will do with that
2023-05-19 16:55:39 +0200 <gensyst> geekosaur, can you search there for "The storage manager will start the finalizer"?
2023-05-19 16:55:57 +0200 <gensyst> "The storage manager will start the finalizer, in a separate thread, some time after the last reference to the @ForeignPtr@ is dropped."
2023-05-19 16:56:13 +0200 <gensyst> How is this acceptable? Many C libraries require the close/abort to be called on same thread :S
2023-05-19 16:57:00 +0200 <gensyst> oh, this "conc" thing is different from normal foreign ptrs?
2023-05-19 16:57:22 +0200 <gensyst> Do you see anything anywhere about the normal ForeignPtr finalizer beign called on same thread?
2023-05-19 16:57:49 +0200 <xilo> hi, what is the convention about error handling functions in haskell, should I put them in separate module?
2023-05-19 16:58:22 +0200 <Rembane> xilo: What's an error handling function to you?
2023-05-19 16:58:59 +0200j4th(~Thunderbi@node-1w7jra29eyptmu39fxgzo44wt.ipv6.telus.net)
2023-05-19 16:59:11 +0200 <geekosaur> gensyst, looks to me like "Conc" there means "conmcurrent" and the ForeignPtr in question is explicitly shared between multiple threads
2023-05-19 16:59:12 +0200j4th(~Thunderbi@node-1w7jra29eyptmu39fxgzo44wt.ipv6.telus.net) (Remote host closed the connection)
2023-05-19 16:59:44 +0200 <geekosaur> as opposed to, say, `withForeignPtr` which is explicitly in a single thread
2023-05-19 17:00:48 +0200 <xilo> like separate data constructor and Either Monad
2023-05-19 17:01:36 +0200 <geekosaur> gensyst, otherwise I would assume in the lack of other documentation that it obeys the usual thread rules: if it's a `forkOS` thread then it's guaranteed to use the same OS thread, otherwise there isn't any such guarnatee even for normal thread scheduling much less GC
2023-05-19 17:01:40 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-19 17:01:57 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-05-19 17:02:47 +0200elain4(~textual@static-71-251-226-194.rcmdva.fios.verizon.net) (Remote host closed the connection)
2023-05-19 17:03:19 +0200paulpaul1076(~textual@95-29-4-192.broadband.corbina.ru)
2023-05-19 17:03:34 +0200 <gensyst> geekosaur, by what mechanism do you think it can keep the original OS thread alive (in the forkOS case) and call the finalizer onto it later?
2023-05-19 17:03:48 +0200 <gensyst> that mechanism doesn't seem to be available in general, for other uses. (i.e. keep a thread alive like that, for later use)
2023-05-19 17:04:00 +0200 <geekosaur> that's the whole point of `forkOS` threads
2023-05-19 17:04:42 +0200 <geekosaur> and, ell, the I/O manager keeps the main thread pool, iirc. you'll need someone better versed in RTS internals to find out details though
2023-05-19 17:04:50 +0200 <gensyst> geekosaur, but the point of foreignptrs is that the fianlizer will get called after the code *I as the programmer wrote* is over.
2023-05-19 17:04:59 +0200 <gensyst> so somehow it manages to call back into it
2023-05-19 17:06:08 +0200 <geekosaur> you might note there is no way to destroy an OS thread
2023-05-19 17:06:29 +0200 <geekosaur> or even create one explicitly although IIRC in practice `forkOS` does create a dedicated OS thread
2023-05-19 17:06:49 +0200 <hololeap> this profiling report shows that 43.1% of time is used by IDLE and 41.9% is used by GC: http://sprunge.us/078r3P
2023-05-19 17:06:59 +0200 <geekosaur> anyway you need to ask about this in #ghc and hope an RTS concurrency expert is around
2023-05-19 17:07:29 +0200 <hololeap> it doesn't seem like it should be using the GC so much. here is the code. I can clarify anything if needed: https://github.com/hololeap/hackport/commit/e56050246476949f255cee9596d2c865471e5be8
2023-05-19 17:07:43 +0200hamzam3(~hamzam3@2a01:e0a:1ee:8c60:c112:84e5:1df:32b0)
2023-05-19 17:08:16 +0200 <hamzam3> Hey guys, I am creating a browser in Haskell if anyone wants to participate: https://github.com/HamzaM3/yes-browser
2023-05-19 17:08:23 +0200hamzam3(~hamzam3@2a01:e0a:1ee:8c60:c112:84e5:1df:32b0) (Client Quit)
2023-05-19 17:09:05 +0200hamzam3(~hamzam3@2a01:e0a:1ee:8c60:c112:84e5:1df:32b0)
2023-05-19 17:10:18 +0200 <hololeap> I _think_ I made the Trie datatype as strict as possible, or maybe that's not the issue here? I'm new to profiling so I'm not exactly sure what to glean from the report, but it does seem excessively slow
2023-05-19 17:11:08 +0200 <hololeap> also, this report is using the Trie cached in a file (deserialized using the binary package)
2023-05-19 17:16:34 +0200 <gensyst> geekosaur, thanks i'm going to ask on #ghc
2023-05-19 17:19:59 +0200hamzam3(~hamzam3@2a01:e0a:1ee:8c60:c112:84e5:1df:32b0) (Ping timeout: 264 seconds)
2023-05-19 17:19:59 +0200hamzahaskell1(~hamzahask@2a01:e0a:1ee:8c60:c112:84e5:1df:32b0) (Ping timeout: 264 seconds)
2023-05-19 17:20:55 +0200euandreh(~Thunderbi@189.6.18.7)
2023-05-19 17:22:06 +0200Sgeo(~Sgeo@user/sgeo)
2023-05-19 17:22:26 +0200ubert(~Thunderbi@188-23-67-228.adsl.highway.telekom.at)
2023-05-19 17:30:43 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de) (Ping timeout: 256 seconds)
2023-05-19 17:33:00 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 17:33:14 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 17:33:36 +0200dhil(~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 268 seconds)
2023-05-19 17:34:35 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 17:34:43 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4)
2023-05-19 17:38:07 +0200AlexNoo_(~AlexNoo@178.34.163.104)
2023-05-19 17:39:09 +0200ub(~Thunderbi@188-23-67-228.adsl.highway.telekom.at)
2023-05-19 17:39:12 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 17:40:08 +0200jero98772(~jero98772@2800:484:1d84:9000::2) (Ping timeout: 240 seconds)
2023-05-19 17:41:08 +0200AlexNoo(~AlexNoo@178.34.151.85) (Ping timeout: 240 seconds)
2023-05-19 17:41:11 +0200ubert(~Thunderbi@188-23-67-228.adsl.highway.telekom.at) (Ping timeout: 240 seconds)
2023-05-19 17:41:11 +0200ububert
2023-05-19 17:41:37 +0200Alex_test(~al_test@178.34.151.85) (Ping timeout: 268 seconds)
2023-05-19 17:42:14 +0200AlexZenon(~alzenon@178.34.151.85) (Ping timeout: 268 seconds)
2023-05-19 17:42:40 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de)
2023-05-19 17:46:08 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 248 seconds)
2023-05-19 17:48:09 +0200titibandit(~titibandi@user/titibandit)
2023-05-19 17:49:23 +0200Alex_test(~al_test@178.34.163.104)
2023-05-19 17:50:33 +0200vglfr(~vglfr@209.198.137.192) (Ping timeout: 256 seconds)
2023-05-19 17:51:46 +0200waleee(~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7)
2023-05-19 17:53:08 +0200jero98772(~jero98772@2800:484:1d84:9000::2)
2023-05-19 17:53:12 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 17:55:34 +0200AlexZenon(~alzenon@178.34.163.104)
2023-05-19 17:55:57 +0200 <texasmynsted> Could somebody please recommend some resources for data modeling (in Haskell). I have found a little here an there... Do you know of anything that takes a deep dive into this subject?
2023-05-19 17:59:52 +0200cheater_(~Username@user/cheater)
2023-05-19 18:02:17 +0200cheater(~Username@user/cheater) (Ping timeout: 265 seconds)
2023-05-19 18:02:18 +0200cheater_cheater
2023-05-19 18:03:15 +0200TheMatten[m](~thematten@2001:470:69fc:105::1:5ba1) (Remote host closed the connection)
2023-05-19 18:05:47 +0200 <[exa]> texasmynsted: that's a pretty wide topic tbh
2023-05-19 18:06:28 +0200alternateved(~user@77-253-195-69.adsl.inetia.pl) (Remote host closed the connection)
2023-05-19 18:06:31 +0200 <[exa]> texasmynsted: I assume you mean something like "how to represent stuff X best with algebraic data types" ?
2023-05-19 18:06:43 +0200econo(uid147250@user/econo)
2023-05-19 18:07:47 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4) (Remote host closed the connection)
2023-05-19 18:08:20 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 18:10:26 +0200AlexNoo_AlexNoo
2023-05-19 18:11:49 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-05-19 18:12:25 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 18:13:59 +0200vglfr(~vglfr@209.198.137.192) (Ping timeout: 240 seconds)
2023-05-19 18:16:07 +0200mauke(~mauke@user/mauke)
2023-05-19 18:16:42 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-19 18:17:04 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:ec99:a92:e82a:fcbf)
2023-05-19 18:18:14 +0200 <texasmynsted> It is a wide topic area. It feels big enough to devote an entire book to the subject.
2023-05-19 18:21:01 +0200vglfr(~vglfr@2a0d:3344:1b4f:9e10:ec99:a92:e82a:fcbf) (Ping timeout: 240 seconds)
2023-05-19 18:21:31 +0200 <texasmynsted> Something like: Model basic types like this... Model sum types like this, product types like this. Here is how and when we need explicit Universal/ existential quantification...
2023-05-19 18:21:54 +0200 <texasmynsted> When to use record types, when better alternatives should be considered...
2023-05-19 18:22:42 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 18:23:29 +0200 <texasmynsted> Something that takes the theory/ideas and shows how to apply them as practical solutions to common problems.
2023-05-19 18:27:00 +0200pavonia(~user@user/siracusa) (Quit: Bye!)
2023-05-19 18:28:45 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 18:37:52 +0200gemmaro(~user@240f:74:d1f0:1:ba1:e787:c9e:b1dc) (Remote host closed the connection)
2023-05-19 18:40:24 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-19 18:42:16 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-05-19 18:42:19 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 18:42:42 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 18:43:00 +0200wootehfoot(~wootehfoo@user/wootehfoot)
2023-05-19 18:44:09 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 18:45:57 +0200joeyh_(~joeyh@kitenet.net)
2023-05-19 18:46:14 +0200joeyh(~joeyh@kitenet.net) (Ping timeout: 265 seconds)
2023-05-19 18:46:48 +0200tureba(~tureba@tureba.org) (Ping timeout: 240 seconds)
2023-05-19 18:46:59 +0200dumptruckman(~dumptruck@143-42-239-71.ip.linodeusercontent.com) (Ping timeout: 268 seconds)
2023-05-19 18:47:28 +0200chele(~chele@user/chele) (Remote host closed the connection)
2023-05-19 18:47:57 +0200dumptruckman(~dumptruck@143-42-239-71.ip.linodeusercontent.com)
2023-05-19 18:49:55 +0200tzh(~tzh@c-24-21-73-154.hsd1.wa.comcast.net)
2023-05-19 18:50:35 +0200hamzam3(~hamzam3@2a01:e0a:1ee:8c60:6793:fba0:f7a2:38d2)
2023-05-19 18:50:37 +0200hamzahaskell1(~hamzahask@2a01:e0a:1ee:8c60:6793:fba0:f7a2:38d2)
2023-05-19 18:51:21 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 18:52:24 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4)
2023-05-19 18:53:45 +0200ubert(~Thunderbi@188-23-67-228.adsl.highway.telekom.at) (Remote host closed the connection)
2023-05-19 18:54:13 +0200vpan(~0@mail.elitnet.lt) (Quit: Leaving.)
2023-05-19 18:54:19 +0200gensyst(~gensyst@user/gensyst) (Quit: Leaving)
2023-05-19 18:54:50 +0200oo_miguel(~Thunderbi@77.252.47.84) (Ping timeout: 246 seconds)
2023-05-19 18:55:47 +0200azimut(~azimut@gateway/tor-sasl/azimut)
2023-05-19 18:57:23 +0200hamzahaskell1(~hamzahask@2a01:e0a:1ee:8c60:6793:fba0:f7a2:38d2) (Ping timeout: 265 seconds)
2023-05-19 18:57:23 +0200hamzam3(~hamzam3@2a01:e0a:1ee:8c60:6793:fba0:f7a2:38d2) (Ping timeout: 265 seconds)
2023-05-19 18:59:30 +0200tureba(~tureba@tureba.org)
2023-05-19 19:03:38 +0200emmanuelux(~emmanuelu@user/emmanuelux)
2023-05-19 19:04:52 +0200m1-s[m](~m1-smatri@2001:470:69fc:105::2:39da)
2023-05-19 19:06:02 +0200vandita(~vandit@94-21-233-127.pool.digikabel.hu) (Ping timeout: 246 seconds)
2023-05-19 19:07:54 +0200vandita(~vandit@85-238-77-50.pool.digikabel.hu)
2023-05-19 19:15:38 +0200oo_miguel(~Thunderbi@77.252.47.84)
2023-05-19 19:19:01 +0200raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds)
2023-05-19 19:21:32 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:21:40 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:23:20 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:23:32 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:24:45 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:25:51 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:25:53 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:26:14 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:26:20 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:26:32 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:28:28 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:30:14 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:34:45 +0200Inst(~Inst@2601:6c4:4081:2fc0:ddcc:91ce:26fa:a2d4)
2023-05-19 19:34:45 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:34:57 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:35:00 +0200vglfr(~vglfr@209.198.137.192) (Read error: Connection reset by peer)
2023-05-19 19:35:14 +0200vglfr(~vglfr@209.198.137.192)
2023-05-19 19:36:21 +0200ski. o O ( "Modelling Large Datasets Using Algebraic Datatypes: A Case Study of the CONFMAN Database" in 2002-05-15 at <https://ofai.at/papers/oefai-tr-2002-27.pdf>,"Using Algebraic Datatypes as Uniform Representation for Structured Data" in 2003 at <https://ofai.at/papers/oefai-tr-2003-07.pdf>, both by Markus Mottl )
2023-05-19 19:42:23 +0200Guest|41(~Guest|41@177.51.6.70)
2023-05-19 19:43:27 +0200Guest|41(~Guest|41@177.51.6.70) (Client Quit)
2023-05-19 19:49:55 +0200nate2(~nate@98.45.169.16)
2023-05-19 19:54:00 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4) (Remote host closed the connection)
2023-05-19 19:54:28 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-05-19 19:56:05 +0200cheater(~Username@user/cheater)
2023-05-19 19:56:26 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4)
2023-05-19 19:57:04 +0200titibandit(~titibandi@user/titibandit)
2023-05-19 20:01:41 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net)
2023-05-19 20:08:20 +0200 <Inst> welp, finally got Fumiaki Kinoshita's Objective working
2023-05-19 20:09:25 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds)
2023-05-19 20:09:46 +0200nick_(~nick@2600:8807:9103:b700:4573:4de0:330c:f2fa)
2023-05-19 20:15:31 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 20:23:59 +0200 <Inst> tbh, can I ask about strictness annotations on accum params?
2023-05-19 20:24:02 +0200cheater(~Username@user/cheater)
2023-05-19 20:24:03 +0200 <Inst> This is REALLY disappointing
2023-05-19 20:24:26 +0200 <Inst> like, I dislike XStrict because I think laziness is the point of Haskell
2023-05-19 20:24:52 +0200 <Inst> but the two seem rather related
2023-05-19 20:25:23 +0200 <Inst> accum param recursion (aka iteration) seems to require strictness all the time
2023-05-19 20:25:46 +0200 <Inst> bleh, maybe one day i'll finally get good enough to contribute to GHC and just render accum param recursion strict via strictness analyzer by default
2023-05-19 20:29:38 +0200Vajb(~Vajb@2001:999:489:89c8:241a:21c3:9f8f:9a9a)
2023-05-19 20:32:38 +0200 <Inst> ironically, the effect of finally learning objective, learning some OOP via Python and Ruby
2023-05-19 20:32:57 +0200 <Inst> is that I appreciate Haskell's purity more; i.e, Haskell is a fount of innovation and novel research
2023-05-19 20:33:19 +0200 <Inst> ad-hoc solutions result in band-aiding everything and result in, well, just Algol with new features
2023-05-19 20:33:32 +0200 <jade[m]> mhm, for me it was the other way around with the same effect
2023-05-19 20:33:49 +0200 <jade[m]> finally learning haskell after oop was such an enlightenment
2023-05-19 20:33:51 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net) (Quit: Client closed)
2023-05-19 20:34:31 +0200 <Inst> i mean I consider Haskell my first language, although I played around with BASIC, Visual Basic, C++ when I was a kid
2023-05-19 20:34:44 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net)
2023-05-19 20:34:55 +0200 <jade[m]> interesting
2023-05-19 20:34:57 +0200 <Inst> same effect of monomer, i.e, monomer, when I look through the codebase
2023-05-19 20:34:58 +0200 <texasmynsted> ski: thank you for the pdf link
2023-05-19 20:35:04 +0200 <Inst> {-# LANGUAGE Strict #-} everywhere
2023-05-19 20:35:18 +0200 <Inst> the widget model is very OOP-ish
2023-05-19 20:36:00 +0200 <Inst> I ask around about FRP, I'm told it's okay / good for games, bad for GUI, but that does make me think, i.e, there are quite a few unsolved problems in Haskell
2023-05-19 20:36:04 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net)
2023-05-19 20:36:27 +0200 <Inst> just band-aiding them with conventional solutions means that the research sucks, we just stick to the old paradigms and old ways of doing things, without aggressive blue-sky research on how to do it better
2023-05-19 20:36:37 +0200 <Inst> so I guess I'm less of a pragmatist now
2023-05-19 20:36:49 +0200 <[exa]> texasmynsted: btw there's this principle "single point of self-evident truth", most of the data structure design is about making this one work w.r.t. 1] hardware and 2] the operations you want to run quickly
2023-05-19 20:36:51 +0200 <texasmynsted> Inst: I am unclear how these are Haskell problems.
2023-05-19 20:37:07 +0200 <jade[m]> what unsolved problems in particular?
2023-05-19 20:37:12 +0200 <Inst> texasmynsted: what Haskell problems are you referring to?
2023-05-19 20:37:45 +0200 <texasmynsted> I refer to > Inst: I ask around about FRP, I'm told it's okay / good for games, bad for GUI, but that does make me think, i.e, there are quite a few unsolved problems in Haskell
2023-05-19 20:38:03 +0200 <[exa]> Inst: well it's kinda hard to grasp a unique point you're making in the last ~15 messages
2023-05-19 20:38:35 +0200 <[exa]> except for the "random band-aid is bad", that's clear :D
2023-05-19 20:38:59 +0200 <Inst> I believe that FP does not have a good solution for GUI; there's no "major" Haskell GUI app
2023-05-19 20:39:11 +0200 <Inst> That, FRP is still a work in progress
2023-05-19 20:39:26 +0200 <Inst> and problems are good, because they demand novel solutions
2023-05-19 20:39:41 +0200 <jade[m]> Inst: is that a FP or tooling/library issue in your opinion?
2023-05-19 20:39:50 +0200 <texasmynsted> [exa]: My coal is to abstract away from the hardware as much as possible. I want to be declarative and model data in such a way as it makes the most sense. (Like math). I can worry about the hardware if or when needed.
2023-05-19 20:39:56 +0200 <texasmynsted> s/coal/goal/
2023-05-19 20:40:15 +0200 <sm> not having a state of the art native GUI system is always more a matter of economics, not technology
2023-05-19 20:41:21 +0200 <sm> Haskell is technically perfectly capable of it
2023-05-19 20:42:36 +0200 <jade[m]> but what's the actual issue - is the way of programming the gui too <insert bad thing here> or does it just not look good, no matter what you try?
2023-05-19 20:42:42 +0200 <jade[m]> or is it something else entirely
2023-05-19 20:42:54 +0200 <Inst> oh, it just feels too imperative / OOP-ish
2023-05-19 20:43:02 +0200 <Inst> I was told that GUI is intrinsically stateful
2023-05-19 20:43:04 +0200 <[exa]> texasmynsted: at that point you're basically just following the SPOT rule and "mathematically easy" transformations, such as not having to do too much mental operation to have something changed... Did you see how zipper structures work? that's IMO a good demo of the tradeoffs
2023-05-19 20:43:12 +0200rf(~rf@142.99.241.246)
2023-05-19 20:43:26 +0200 <jade[m]> Inst: even with like gui combinators and state transition functions?
2023-05-19 20:43:30 +0200 <[exa]> Inst: I'd like to expand on that, I didn't see a good GUI solution yet, ever. Except maybe for imgui and brick, these are magique.
2023-05-19 20:43:49 +0200 <Inst> I need to go learn Linux for brick because of the vty / windows problem
2023-05-19 20:44:08 +0200 <[exa]> learning a unix is always a good investment tbh
2023-05-19 20:44:28 +0200 <jade[m]> [exa]: I wanted to bring up brick which seems very idiomatic in terms of functional ~~gui~~ tui desigm
2023-05-19 20:44:46 +0200 <[exa]> same for Elm probably
2023-05-19 20:44:50 +0200 <[exa]> Inst: ^
2023-05-19 20:45:15 +0200 <jade[m]> s/desigm/design
2023-05-19 20:46:09 +0200 <ski> texasmynsted : i think probably not quite what you were looking for. i was just reminded of it
2023-05-19 20:46:48 +0200 <sm> argh, when will a windows hacker make brick/vty work there
2023-05-19 20:47:48 +0200 <geekosaur> iirc that will require massive changes because while unix uses escape sequences windows uses the equivalent of ioctl()
2023-05-19 20:47:54 +0200 <sm> so many years now, it's odd. Windows hackers + free time + haskell + interested in terminal = 0 ?
2023-05-19 20:48:05 +0200 <geekosaur> so every single I/O operation has to be conditionalized on platform
2023-05-19 20:48:08 +0200 <texasmynsted> No I have not looked at how zipper structures work... So far that is pretty interesting.
2023-05-19 20:48:46 +0200 <sm> geekosaur: ouch
2023-05-19 20:49:11 +0200 <jade[m]> sm: I feel like most haskell users are on linux - and haskell also plays into that with ghcup for example being linux only
2023-05-19 20:49:19 +0200 <ski> @where zipper
2023-05-19 20:49:19 +0200 <lambdabot> http://www.haskell.org/haskellwiki/Zipper
2023-05-19 20:49:21 +0200 <jade[m]> it might have gotten windows support just recently
2023-05-19 20:49:36 +0200 <ski> [exa] : "SPOT" ?
2023-05-19 20:49:44 +0200 <geekosaur> huh? ghcup supports windows for everything but tui, which requires brick
2023-05-19 20:49:58 +0200 <geekosaur> there's been a powershell recipe to install it for over a year
2023-05-19 20:50:02 +0200 <texasmynsted> I am just surprised nobody has written "Data modeling in Haskell" or "Data Driven Design in Haskell" or "Haskell type tetris" . . . etc . . .
2023-05-19 20:50:44 +0200 <sm> ghcyup
2023-05-19 20:50:49 +0200 <jade[m]> geekosaur: yes? I might have thought of something else
2023-05-19 20:51:07 +0200 <sm> texasmynsted: there are a few things along that line.. maybe in
2023-05-19 20:51:07 +0200 <sm> @where books
2023-05-19 20:51:07 +0200 <lambdabot> https://www.extrema.is/articles/haskell-books is the best list of Haskell books. See also: LYAH, HTAC, RWH, PH, YAHT, SOE, HR, PIH, TFwH, wikibook, PCPH, HPFFP, FSAF, HftVB, TwT, FoP, PFAD, WYAH,
2023-05-19 20:51:07 +0200 <lambdabot> non-haskell-books
2023-05-19 20:53:40 +0200 <sm> dang that's a lot of books
2023-05-19 20:53:50 +0200cheater(~Username@user/cheater) (Ping timeout: 246 seconds)
2023-05-19 20:55:53 +0200evincar(~evincar@user/evincar)
2023-05-19 20:56:07 +0200 <sm> https://leanpub.com/thinking-with-types looks to be more "thinking about types"
2023-05-19 20:56:18 +0200cheater(~Username@user/cheater)
2023-05-19 20:57:00 +0200 <sm> https://www.packtpub.com/product/haskell-cookbook/9781786461353 is a practical cookbook, as is
2023-05-19 20:57:00 +0200 <sm> @where HTAC
2023-05-19 20:57:00 +0200 <lambdabot> "Haskell Tutorial and Cookbook" by Mark Watson in 2017-09-04 at <https://leanpub.com/haskell-cookbook>
2023-05-19 20:58:24 +0200 <Inst> sm
2023-05-19 20:58:38 +0200 <Inst> Haskell Windows support is atrocious, it's there, and that's great, but I think it was primarily because of Hugs and so on
2023-05-19 20:58:41 +0200 <sm> https://www.packtpub.com/product/haskell-design-patterns/9781783988723 looks good but still not seeing much talk of concrete modelling/design. I'm not totally sure what your book would look like, but I feel it might be out there
2023-05-19 20:59:23 +0200 <Inst> The sad thing is, I don't think any cheers will go up when Phyx and bgamari[m] finally get getChar and getLine working properly on Windows
2023-05-19 20:59:27 +0200skiidly remembers `WinHugs'
2023-05-19 20:59:56 +0200 <geekosaur> there's still (or used to be) WinGhci although it may have bitrotted
2023-05-19 21:00:03 +0200 <ski> yea. ndm
2023-05-19 21:00:29 +0200 <sm> (last one: don't miss https://leanpub.com/production-haskell )
2023-05-19 21:00:32 +0200 <texasmynsted> Wow, I found another Sandy Maguire book I need^^^^want!
2023-05-19 21:00:37 +0200 <Inst> is it supposed to work that way?
2023-05-19 21:00:38 +0200 <Inst> https://media.discordapp.net/attachments/968989726633779215/1109193869242929193/image.png?width=44…
2023-05-19 21:00:56 +0200 <texasmynsted> https://www.extrema.is/articles/haskell-books/algebra-driven-design
2023-05-19 21:01:05 +0200 <geekosaur> Inst, yes
2023-05-19 21:01:09 +0200 <Inst> wait, really?
2023-05-19 21:01:13 +0200 <geekosaur> by default input is line buffered
2023-05-19 21:01:20 +0200 <geekosaur> as with any other program
2023-05-19 21:01:36 +0200 <geekosaur> use `hSetBuffering stdin NoBuffering` to change this
2023-05-19 21:01:42 +0200cheater_(~Username@user/cheater)
2023-05-19 21:01:47 +0200 <texasmynsted> I have been sooo close to buying "Production Haskell" a number of times.
2023-05-19 21:02:17 +0200 <sm> I think I actually did (and promptly forgot it existed)
2023-05-19 21:02:28 +0200 <hololeap> in case anyone was interested, my program's speed increased significantly by putting the Trie in a compact region
2023-05-19 21:02:38 +0200 <mauke> induction haskell?
2023-05-19 21:02:38 +0200 <texasmynsted> I have far more books than I could read
2023-05-19 21:02:43 +0200 <sm> that's the power of a good TOC! All you need! :)
2023-05-19 21:03:01 +0200 <Inst> bleh, damnit, I'm going to reboot into my Deb partition
2023-05-19 21:03:07 +0200 <Inst> I swear it's not supposed to be this way
2023-05-19 21:03:13 +0200Inst(~Inst@2601:6c4:4081:2fc0:ddcc:91ce:26fa:a2d4) (Read error: Connection reset by peer)
2023-05-19 21:03:15 +0200 <tomsmeding> Inst: what's not supposed to be this way
2023-05-19 21:03:16 +0200 <tomsmeding> oh
2023-05-19 21:03:33 +0200 <tomsmeding> ah, on linux stdin seems to be in NoBuffering mode by default
2023-05-19 21:03:52 +0200 <tomsmeding> perhaps on windows, ghci reads from the terminal directly whereas getChar reads from stdin? Or something?
2023-05-19 21:04:01 +0200 <geekosaur> it varies, in ghci it's NoBuffering because of readline/haskeline, in a program it's line buffered
2023-05-19 21:04:16 +0200 <geekosaur> and yes, emulation of this on windows is weird
2023-05-19 21:04:25 +0200cheater(~Username@user/cheater) (Ping timeout: 240 seconds)
2023-05-19 21:04:29 +0200cheater_cheater
2023-05-19 21:04:30 +0200 <tomsmeding> geekosaur: on linux I'm not reproducing Inst's screenshot
2023-05-19 21:04:39 +0200 <geekosaur> interesting
2023-05-19 21:04:48 +0200 <tomsmeding> https://tomsmeding.com/ss/get/tomsmeding/cmN89k
2023-05-19 21:05:00 +0200 <tomsmeding> different behaviour all around
2023-05-19 21:05:24 +0200 <tomsmeding> here ghci is clearly reading command input from the same stream as getChar is reading from
2023-05-19 21:05:25 +0200 <geekosaur> yeh, that would make sense on linux, there's only one terminal I/O stream
2023-05-19 21:05:30 +0200 <tomsmeding> showing that on windows that's not the case
2023-05-19 21:05:34 +0200 <geekosaur> windows is different, as I said
2023-05-19 21:05:37 +0200 <tomsmeding> geekosaur: no, there's also /dev/tty
2023-05-19 21:05:43 +0200 <geekosaur> try it sometime
2023-05-19 21:05:48 +0200 <tomsmeding> ghci doesn't use it, and it shouldn't, so all is well
2023-05-19 21:05:52 +0200 <geekosaur> /dev/tty is an alias
2023-05-19 21:06:50 +0200Inst(~Inst@2601:6c4:4081:2fc0:e418:a15:6c7d:2dee)
2023-05-19 21:07:01 +0200 <Inst> tried it on Linux, getChar's behavior is not preferred, but adequate, under 9.6.1
2023-05-19 21:07:09 +0200 <tomsmeding> Inst: https://tomsmeding.com/ss/get/tomsmeding/cmN89k my linux experience
2023-05-19 21:07:10 +0200 <Inst> will take a char, then immediately return on GHCI
2023-05-19 21:07:17 +0200 <geekosaur> there's still only one input stream, which can be accessed as stdin when it's attached to the terminal, or /dev/tty, or in somewhat freakish other ways (for example session setup `dup()`s stdin onto stdout and stderr so it's possible to read from stdout when it's a terminal
2023-05-19 21:07:19 +0200 <geekosaur> )
2023-05-19 21:07:26 +0200 <Inst> possible this is a GHCI issue, not a GHC issue
2023-05-19 21:07:27 +0200 <tomsmeding> Inst: https://ircbrowse.tomsmeding.com/browse/lchaskell?id=965035#trid965035
2023-05-19 21:07:53 +0200vandita(~vandit@85-238-77-50.pool.digikabel.hu) (Ping timeout: 265 seconds)
2023-05-19 21:08:02 +0200 <tomsmeding> geekosaur: hm, you're probably right, somehow I thought this worked differently
2023-05-19 21:09:16 +0200vandita(~vandit@80-95-69-243.pool.digikabel.hu)
2023-05-19 21:09:36 +0200 <tomsmeding> geekosaur: ah I was confusing reading from /dev/tty with writing to /dev/tty
2023-05-19 21:09:42 +0200 <tomsmeding> writing to /dev/tty is not the same as writing to stdout
2023-05-19 21:09:47 +0200 <geekosaur> right
2023-05-19 21:10:20 +0200 <tomsmeding> iirc sudo writes the prompt to /dev/tty so that it works even if its output is piped to a pager or something
2023-05-19 21:10:23 +0200merijn(~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds)
2023-05-19 21:10:50 +0200 <tomsmeding> Inst: what's your preferred behaviour
2023-05-19 21:10:59 +0200 <geekosaur> yeh, all I/O to /dev/tty so you can pipe to/from it
2023-05-19 21:11:24 +0200 <Inst> https://media.discordapp.net/attachments/968989726633779215/1109196545523458149/image.png?width=12…
2023-05-19 21:11:58 +0200 <Inst> https://paste.tomsmeding.com/Y69PQ49f
2023-05-19 21:12:31 +0200 <tomsmeding> you're not outputting anything, so seems right?
2023-05-19 21:13:11 +0200 <Inst> is this some unsafeInterleaveIO thing with getChar?
2023-05-19 21:13:16 +0200 <tomsmeding> what?
2023-05-19 21:13:20 +0200 <tomsmeding> what did you expect to happen
2023-05-19 21:13:35 +0200 <tomsmeding> in a program, stdin is line-buffered by default
2023-05-19 21:13:36 +0200 <Inst> ah, okay, I guess this is intended behavior
2023-05-19 21:13:43 +0200 <Inst> I was expecting it to set up two different input prompts
2023-05-19 21:13:55 +0200 <tomsmeding> ghci on linux sets it to unbuffered to be able to read your commands as they come
2023-05-19 21:13:57 +0200 <Inst> and I turned off the line-buffering via hSetBuffering stdin NoBuffering?
2023-05-19 21:14:02 +0200 <tomsmeding> oh right
2023-05-19 21:14:30 +0200 <Inst> as to your question of preferred behavior, i.e, read two separate keypresses
2023-05-19 21:14:42 +0200mapniv(~mapniv@user/Mapniv)
2023-05-19 21:14:42 +0200 <tomsmeding> interesting, on linux that does work
2023-05-19 21:15:22 +0200 <tomsmeding> Inst: what happens on windows if you do 'c <- getChar; c' <- getChar; print (c, c')'
2023-05-19 21:15:24 +0200 <Inst> iirc there was a discussion of issues with haskelline
2023-05-19 21:15:44 +0200 <tomsmeding> with your man program, no haskeline is involved
2023-05-19 21:15:53 +0200 <Inst> the Winio RTSopts are even more of a mess
2023-05-19 21:16:58 +0200 <tomsmeding> if printing the read characters only prints them after you press enter, it indeed seems as geekosaur said that NoBuffering doesn't work well on windows
2023-05-19 21:17:04 +0200 <tomsmeding> s/well/at all/?
2023-05-19 21:17:28 +0200 <geekosaur> windows is technically always in NoBuffering mode
2023-05-19 21:17:34 +0200 <Inst> re phyx, iirc, there was discussion that ghc / ghci was running haskelline under the hood
2023-05-19 21:17:38 +0200 <Inst> and it was blowing up
2023-05-19 21:17:50 +0200 <Inst> also, the GHC compile on Linux (Deb) was far faster than the Windows compile
2023-05-19 21:17:50 +0200 <tomsmeding> ghci uses haskeline, right?
2023-05-19 21:17:54 +0200 <geekosaur> yes
2023-05-19 21:17:57 +0200 <Inst> i think
2023-05-19 21:18:04 +0200 <tomsmeding> any ghc-compiled program is not going to use haskeline without you explicitly using it
2023-05-19 21:18:13 +0200 <Inst> https://media.discordapp.net/attachments/968989726633779215/1109198308037107802/image.png?width=12…
2023-05-19 21:18:23 +0200 <geekosaur> but more to the point, BCO uses haskeline so anything run under ghci or runghc gets it
2023-05-19 21:18:37 +0200 <tomsmeding> BCO?
2023-05-19 21:18:48 +0200 <geekosaur> but compiled programs don't unless you explicitly use it
2023-05-19 21:18:53 +0200 <geekosaur> the bytecode backend
2023-05-19 21:18:55 +0200 <tomsmeding> Inst: what step is slow on windows, Compiling or Linking?
2023-05-19 21:19:03 +0200mc47(~mc47@xmonad/TheMC47) (Remote host closed the connection)
2023-05-19 21:19:09 +0200 <tomsmeding> geekosaur: ah
2023-05-19 21:19:26 +0200 <tomsmeding> only on windows I guess?
2023-05-19 21:19:35 +0200 <tomsmeding> or is the input of any runghc program really passed through haskeline
2023-05-19 21:19:40 +0200 <tomsmeding> that sounds dumb and redundant
2023-05-19 21:19:41 +0200 <geekosaur> it really is
2023-05-19 21:19:48 +0200coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-05-19 21:19:49 +0200 <tomsmeding> what's haskeline doing
2023-05-19 21:20:04 +0200 <geekosaur> nothing much, it's just how things are implemented
2023-05-19 21:20:09 +0200 <tomsmeding> its functionality is completely useless
2023-05-19 21:20:26 +0200 <sm> wow, this is some serious terminal I/O lore that deserves its own.. page or something
2023-05-19 21:20:44 +0200 <tomsmeding> except if you need to manually implement backspace on windows, but then that hardly warrants haskeline
2023-05-19 21:20:50 +0200sm. o O ( ..podcast.. )
2023-05-19 21:21:11 +0200 <Inst> possibly linking, could just be clang's fault
2023-05-19 21:21:19 +0200tomsmeding. o O ( Everything You Did and Did Not Want to Know About Terminal IO in Haskell )
2023-05-19 21:21:45 +0200 <geekosaur> basically it's much easier and saner to do things this way because constantly switching between haskeline and line oriented mode in ghci would be slow and produce unexpected behavior at times
2023-05-19 21:21:47 +0200 <tomsmeding> Inst: linking haskell programs is indeed excessively slow on windows
2023-05-19 21:22:00 +0200 <geekosaur> and runghc inherits it because it's secretly ghci in the background
2023-05-19 21:22:00 +0200 <tomsmeding> interesting
2023-05-19 21:23:11 +0200tomsmedingwould expect ghci to do said switching
2023-05-19 21:23:18 +0200 <geekosaur> the shell can also have these weirdnesses happen because it does switch between line and character/readline mode, and zsh actually has some hacks to warn you when it thinks it's happened (reverse video percent sign)
2023-05-19 21:23:22 +0200 <Inst> ehhh, but i'd say getting GHCI / compiled Haskell terminal programs to work properly on getLine / getChar on Windows is higher priority than getting vty working
2023-05-19 21:23:38 +0200 <Inst> https://www.reddit.com/r/haskell/comments/ht4ehe/comment/fyeo644/?utm_source=share&utm_medium=web2…
2023-05-19 21:23:41 +0200 <tomsmeding> and do the work to pass retain the leftover input buffer from line-buffered mode to pass that to haskeline
2023-05-19 21:24:56 +0200 <geekosaur> tomsmeding, the reason ghci doesn't is that you can have threads running while the ghci prompt is up and there's no way to stop them from doing I/O
2023-05-19 21:25:05 +0200 <Inst> do windows hackers have a cladic allergic to Haskell? ;_;
2023-05-19 21:25:07 +0200 <geekosaur> (shells *can* stop them, they get SIGTTIN)
2023-05-19 21:25:09 +0200 <mauke> the zsh reverse percent sign is for incomplete output (unterminated line), not input, though
2023-05-19 21:25:15 +0200 <tomsmeding> geekosaur: lol that's true
2023-05-19 21:25:41 +0200tomsmedingthought the same as mauke, fish also does that with a neat ⏎ sign
2023-05-19 21:26:57 +0200rf(~rf@142.99.241.246) (Remote host closed the connection)
2023-05-19 21:27:20 +0200rf(~rf@142.99.241.246)
2023-05-19 21:29:08 +0200 <tomsmeding> Inst: I suspect that Haskell programmers typically find programming fun (otherwise they'd stay with languages that pay), and such people also typically find tinkering with software fun, and such people typically want a unixy system and not a windows system
2023-05-19 21:29:16 +0200 <Inst> btw, one thing, thanks for putting up with me, at least, the folks who've been willing to do so, you guys are a great introduction to CS / programming and I wish everyone could have a similar experience, except without the cost involved on your side
2023-05-19 21:30:53 +0200 <Inst> it's more a newbie thing, I think starting with Haskell is a great way to get into proper CS / programming as a science / art beyond copy pasting button labels
2023-05-19 21:31:20 +0200 <jade[m]> I like the programming as art concept
2023-05-19 21:31:23 +0200 <tomsmeding> that's also a path to haskell, but it's one that few people take
2023-05-19 21:31:56 +0200 <Inst> i.e, tons of beginnesr are on haskell, starting with haskell and leraning full CS that way is better than the alternatives
2023-05-19 21:32:10 +0200 <Inst> erm, beginners are on Windows
2023-05-19 21:32:18 +0200 <tomsmeding> I think the number of people that had haskell as their first programming language, where this was not because their uni was radical enough to start with haskell, and that continued learning long enough to get decent at haskell, is very very small
2023-05-19 21:32:50 +0200 <tomsmeding> that uni side-condition can be removed because I know of only 1 uni that does this, which is Oxford iirc
2023-05-19 21:33:04 +0200 <sm> Inst 👍️
2023-05-19 21:33:08 +0200 <tomsmeding> most haskellers already knew programming
2023-05-19 21:33:15 +0200 <[exa]> nice thing about haskells today is that it makes the learning kinda constructive and rewarding (as opposed to learning which library monkeypatched half of your core libraries to oblivion again, as in one certain other language)
2023-05-19 21:33:17 +0200 <tomsmeding> but you're right, most of these very small group are on windows
2023-05-19 21:34:33 +0200 <sm> uh.. maybe. <cough>tools, dependency hell, ghc bugs..</cough>
2023-05-19 21:37:30 +0200 <EvanR> most haskellers already knew programming and many of them then had to unlearn it and relearn it in the process xD
2023-05-19 21:37:43 +0200 <__monty__> [exa]: Is this a language that starts with E or R? (Yes, one extra level of indirection to obfuscate a tiny bit more.)
2023-05-19 21:40:08 +0200AkechiShiro(~licht@user/akechishiro)
2023-05-19 21:41:31 +0200 <[exa]> __monty__: ...but why would you omit the one that starts with P?
2023-05-19 21:42:17 +0200pavonia(~user@user/siracusa)
2023-05-19 21:44:09 +0200 <Inst> on the ruby Discord, besides whinging about their classes with 1000+ methods
2023-05-19 21:44:12 +0200 <__monty__> Because there are too many of those. And if it's the one I'm thinking of I never ran into such extensive monkeypatching there. I've also only heard things about the others though.
2023-05-19 21:44:20 +0200 <Inst> there are apparently quite a few devs who started with Haskell
2023-05-19 21:44:52 +0200 <hololeap> I'm a bit confused on the nuances of compact regions. if I have (s :: Compact Seq) and I use (toList (getCompact s)), will the resulting list be in the compact region?
2023-05-19 21:44:58 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 21:45:18 +0200 <hololeap> or do I have to run compactAdd on every intermediate value?
2023-05-19 21:45:45 +0200rf(~rf@142.99.241.246) (Ping timeout: 240 seconds)
2023-05-19 21:46:26 +0200rf(~rf@142.99.241.246)
2023-05-19 21:46:33 +0200 <Inst> https://media.discordapp.net/attachments/280033776820813825/1108983771404959786/image.png?width=28…
2023-05-19 21:47:21 +0200comarrrrrrrrrrrr(~comarrrrr@73.237.206.60)
2023-05-19 21:54:13 +0200oo_miguel(~Thunderbi@77.252.47.84) (Ping timeout: 256 seconds)
2023-05-19 21:55:48 +0200 <[exa]> Inst: a fun observation is that e.g. for me there was no way to start with haskell because there was no haskell
2023-05-19 21:56:23 +0200shapr(~user@76.29.230.19)
2023-05-19 21:58:05 +0200 <geekosaur> same
2023-05-19 21:58:40 +0200 <int-e> you could've waited
2023-05-19 21:59:44 +0200 <geekosaur> lol, try to get a kid to wait a decade…
2023-05-19 22:00:32 +0200 <int-e> :)
2023-05-19 22:02:08 +0200 <geekosaur> actually more like a decade and a half, I recall playing in a study room with a TRS-80 in middle school
2023-05-19 22:02:29 +0200mapniv(~mapniv@user/Mapniv) (Sleepy)
2023-05-19 22:04:11 +0200 <hololeap> this seems like it would work to take the guessing out and make sure everything is part of the same compacted region: http://sprunge.us/y3yrem
2023-05-19 22:11:54 +0200phma(~phma@host-67-44-208-41.hnremote.net) (Read error: Connection reset by peer)
2023-05-19 22:12:31 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf) (Remote host closed the connection)
2023-05-19 22:12:35 +0200chomwitt(~chomwitt@athedsl-351665.home.otenet.gr) (Remote host closed the connection)
2023-05-19 22:12:49 +0200use-value(~Thunderbi@2a00:23c6:8a03:2f01:75c2:a71f:beaa:29bf)
2023-05-19 22:12:57 +0200phma(~phma@host-67-44-208-177.hnremote.net)
2023-05-19 22:14:45 +0200gmg(~user@user/gehmehgeh)
2023-05-19 22:14:58 +0200titibandit(~titibandi@user/titibandit) (Remote host closed the connection)
2023-05-19 22:15:15 +0200Lycurgus(~juan@user/Lycurgus)
2023-05-19 22:18:53 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 246 seconds)
2023-05-19 22:21:02 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com)
2023-05-19 22:21:29 +0200merijn(~merijn@86.86.29.250)
2023-05-19 22:22:30 +0200Lycurgus(~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz)
2023-05-19 22:26:44 +0200Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-05-19 22:27:39 +0200mncheck(~mncheck@193.224.205.254) (Ping timeout: 256 seconds)
2023-05-19 22:32:47 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de) (Ping timeout: 240 seconds)
2023-05-19 22:33:36 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net) (Quit: Client closed)
2023-05-19 22:36:52 +0200trev(~trev@user/trev) (Quit: trev)
2023-05-19 22:41:18 +0200szkl(uid110435@id-110435.uxbridge.irccloud.com)
2023-05-19 22:48:31 +0200 <probie> hololeap: the list itself won't be part of the compact region, but all the elements in this will be
2023-05-19 22:48:44 +0200 <probie> s/in this/in this list/
2023-05-19 22:49:05 +0200 <probie> (assuming that they were already in the compact region)
2023-05-19 22:51:01 +0200Inst[m](~instrmatr@2001:470:69fc:105::1:903e)
2023-05-19 22:51:58 +0200 <hololeap> probie, what I'm trying to do is very quickly spin up using a binary-encoded trie from a file, use the trie to search and return the resulting strings, then spin down
2023-05-19 22:52:20 +0200 <hololeap> (it's for bash completion)
2023-05-19 22:52:36 +0200 <hololeap> the GC keeps being the biggest bottleneck
2023-05-19 22:52:51 +0200 <hololeap> I wonder if there's a way to just disable the GC altogether
2023-05-19 22:54:04 +0200 <hololeap> decoding the trie into a compact region was a 6x speedup compared to just doing it normally
2023-05-19 22:55:00 +0200 <hololeap> but my .prof file still shows GC being 34.2% time
2023-05-19 22:56:09 +0200merijn(~merijn@86.86.29.250) (Ping timeout: 265 seconds)
2023-05-19 22:58:01 +0200 <probie> hololeap: if you want to "disable GC", you can add the RTS options to disable idle time garbage collection and make the nursery very big and (if needed) manually call performGC in your code
2023-05-19 22:58:45 +0200 <EvanR> not doing GC at all is probably ineffective for haskell
2023-05-19 23:00:26 +0200takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-05-19 23:03:06 +0200_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-05-19 23:04:03 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4) (Remote host closed the connection)
2023-05-19 23:04:23 +0200bgs(~bgs@212-85-160-171.dynamic.telemach.net) (Remote host closed the connection)
2023-05-19 23:05:06 +0200spatchkaa(~spatchkaa@S010600fc8da47b63.gv.shawcable.net)
2023-05-19 23:09:08 +0200 <Inst> okay, why is it doing that?
2023-05-19 23:09:13 +0200eggplantade(~Eggplanta@2600:1700:38c5:d800:510d:16a:b9b3:3b4)
2023-05-19 23:09:46 +0200 <Inst> u <- newMVar id on ghci gives me MVar (GHC.Types.Any -> GHC.Types.Any)
2023-05-19 23:10:10 +0200 <geekosaur> it has to assign a type but can't
2023-05-19 23:10:30 +0200 <geekosaur> `Any` is a magical type that is used when ghc can't settle on a type any other way
2023-05-19 23:10:34 +0200 <Inst> in GHC, does it work?
2023-05-19 23:10:54 +0200 <Inst> I'm now thinking about porting Objective to STM, but I'd need to learn STM first
2023-05-19 23:10:56 +0200 <geekosaur> normally you have to use `AllowAmbiguousTypes` to see it
2023-05-19 23:11:24 +0200 <EvanR> STM is great and not that hard
2023-05-19 23:11:27 +0200 <geekosaur> but there's a few places where internals let it leak out, like you're seeing with `newMVar`
2023-05-19 23:12:16 +0200euandreh(~Thunderbi@189.6.18.7) (Remote host closed the connection)
2023-05-19 23:12:37 +0200zmt00(~zmt00@user/zmt00) (Read error: Connection reset by peer)
2023-05-19 23:12:53 +0200 <Inst> I need to study FRP more, to figure out what Haskell GUI looks like "the right way", but I'm thinking that with this library, if you're using objects, you should be honest you're using objects
2023-05-19 23:13:02 +0200euandreh(~Thunderbi@189.6.18.7)
2023-05-19 23:13:10 +0200 <Inst> an ADT that's a record of functions...
2023-05-19 23:13:18 +0200 <Inst> well, it might not be an object
2023-05-19 23:15:59 +0200vandita(~vandit@80-95-69-243.pool.digikabel.hu) (Ping timeout: 240 seconds)
2023-05-19 23:17:30 +0200Pickchea(~private@user/pickchea)
2023-05-19 23:17:31 +0200rf(~rf@142.99.241.246) (Ping timeout: 256 seconds)
2023-05-19 23:17:45 +0200vandita(~vandit@80-95-69-254.pool.digikabel.hu)
2023-05-19 23:19:23 +0200 <EvanR> record of functions (or other data) which operate on its own self is the theory-of-objects version of objects
2023-05-19 23:19:41 +0200 <hololeap> hm, maybe other changes to my program are what accounted for the 6x speedup, because removing the compact region code didn't change anything. also, +RTS -n999999999999 -I0 -RTS seems to slow it down if anything
2023-05-19 23:22:24 +0200 <EvanR> that's over 9000 cores
2023-05-19 23:22:30 +0200rf(~rf@142.99.241.246)
2023-05-19 23:22:59 +0200 <hololeap> wouldn't that be -N9999999999999999
2023-05-19 23:23:49 +0200comarrrrrrrrrrrr(~comarrrrr@73.237.206.60) (Remote host closed the connection)
2023-05-19 23:23:51 +0200 <geekosaur> cores is -N not -n (number of allocation areas; you probably don't want zillions of those)
2023-05-19 23:24:41 +0200 <geekosaur> you're probably making a lot of tiny areas so ghc has to do a lot of work
2023-05-19 23:25:36 +0200 <geekosaur> maybe -A64G would help?
2023-05-19 23:26:00 +0200 <geekosaur> s/ghc has/the RTS has/
2023-05-19 23:28:43 +0200 <hololeap> yeah lots of tiny branches to encode ~100000 strings into my Trie
2023-05-19 23:28:53 +0200 <hololeap> data Trie = Bool :< Map Char Trie
2023-05-19 23:29:08 +0200 <hololeap> the GC is going out of control
2023-05-19 23:29:54 +0200michalz(~michalz@185.246.204.73) (Remote host closed the connection)
2023-05-19 23:30:31 +0200 <hololeap> -A64G blew the stack
2023-05-19 23:31:47 +0200 <hololeap> it triggered earlyoom
2023-05-19 23:32:33 +0200 <geekosaur> so you're actually generating a lot of garbage. that sounds like maybe you need some strictness annotations and maybe to clean up how you do your trie construction a bit
2023-05-19 23:33:06 +0200zmt00(~zmt00@user/zmt00)
2023-05-19 23:33:21 +0200 <hololeap> I have the Strict language extension enabled in my Data.Trie module
2023-05-19 23:34:06 +0200 <geekosaur> that can actually make things worse if used indiscriminately
2023-05-19 23:34:31 +0200rf(~rf@142.99.241.246) (Ping timeout: 240 seconds)
2023-05-19 23:34:31 +0200 <geekosaur> `Strict` does not magically solve problems, it is a tradeoff
2023-05-19 23:36:45 +0200__monty__(~toonn@user/toonn) (Quit: leaving)
2023-05-19 23:38:59 +0200 <hololeap> geekosaur: if you have any suggestions here, I'd love to hear them: https://github.com/hololeap/hackport/commit/bff9112
2023-05-19 23:39:17 +0200 <hololeap> this is the area of haskell that I find the most difficult
2023-05-19 23:39:34 +0200 <hololeap> I would love to get a solid understanding of how to solve this kind of problem
2023-05-19 23:39:56 +0200 <geekosaur> I'm not real great at it myself
2023-05-19 23:40:37 +0200 <geekosaur> I just know that people tend to try to bang everything or -XStrict / -XStrictData but you need to use profiling to guide putting them in appropriate spots or you can make things worse instead of better
2023-05-19 23:41:46 +0200 <hololeap> I have +RTS -hc -pa -RTS on my command line, but knowing how to use the generated files is another story
2023-05-19 23:44:22 +0200freeside_(~mengwong@103.252.202.151)
2023-05-19 23:45:19 +0200 <hololeap> isn't there some *oscope webapp that you can put the json profiler output into? would that be useful here?
2023-05-19 23:46:23 +0200werneta(~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 246 seconds)
2023-05-19 23:46:52 +0200 <geekosaur> probably but I don't know enough about that 😞
2023-05-19 23:47:39 +0200ctearrrrrrrrrrrr(~ctearrrrr@73.237.206.60)
2023-05-19 23:48:47 +0200freeside_(~mengwong@103.252.202.151) (Ping timeout: 240 seconds)
2023-05-19 23:49:59 +0200shapr(~user@76.29.230.19) (Ping timeout: 240 seconds)
2023-05-19 23:51:25 +0200nate2(~nate@98.45.169.16)
2023-05-19 23:53:37 +0200foul_owl(~kerry@71.212.137.212)
2023-05-19 23:54:25 +0200user____3(~user@dynamic-046-114-177-008.46.114.pool.telefonica.de)
2023-05-19 23:55:59 +0200motherfsck(~motherfsc@user/motherfsck) (Ping timeout: 264 seconds)
2023-05-19 23:56:05 +0200nate2(~nate@98.45.169.16) (Ping timeout: 240 seconds)
2023-05-19 23:56:25 +0200motherfsck(~motherfsc@user/motherfsck)
2023-05-19 23:57:32 +0200tessier(~treed@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 265 seconds)