| 2022-05-12 00:02:02 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 252 seconds) |
| 2022-05-12 00:04:12 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 00:04:44 +0200 | n3t | (n3t@s45.mydevil.net) (Read error: Connection reset by peer) |
| 2022-05-12 00:05:02 +0200 | n3t | (n3t@s45.mydevil.net) |
| 2022-05-12 00:05:23 +0200 | maerwald | (~maerwald@mail.hasufell.de) (Changing host) |
| 2022-05-12 00:05:23 +0200 | maerwald | (~maerwald@user/maerwald) |
| 2022-05-12 00:07:18 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 00:08:07 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 00:09:11 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2022-05-12 00:10:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 00:11:10 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 00:11:30 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-05-12 00:11:59 +0200 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 260 seconds) |
| 2022-05-12 00:15:29 +0200 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-05-12 00:18:12 +0200 | joo-_ | (~joo-_@fsf/member/joo--) (Ping timeout: 248 seconds) |
| 2022-05-12 00:19:55 +0200 | joo-_ | (~joo-_@87-49-45-5-mobile.dk.customer.tdc.net) |
| 2022-05-12 00:19:55 +0200 | joo-_ | (~joo-_@87-49-45-5-mobile.dk.customer.tdc.net) (Changing host) |
| 2022-05-12 00:19:55 +0200 | joo-_ | (~joo-_@fsf/member/joo--) |
| 2022-05-12 00:24:08 +0200 | <raehik> | Why does GHCi error with "couldn't match a lifted type with an unlifted type" when I write a Word# expression? Or even a literal |
| 2022-05-12 00:24:11 +0200 | <raehik> | > 1## |
| 2022-05-12 00:24:13 +0200 | <lambdabot> | error: |
| 2022-05-12 00:24:13 +0200 | <lambdabot> | • Couldn't match a lifted type with an unlifted type |
| 2022-05-12 00:24:14 +0200 | <lambdabot> | When matching types |
| 2022-05-12 00:25:08 +0200 | <raehik> | I can apparently work around it by wrapping with W# :: Word# -> Word . but I'm very very fuzzy on the details here |
| 2022-05-12 00:25:12 +0200 | <raehik> | > W# 1## |
| 2022-05-12 00:25:14 +0200 | <lambdabot> | error: |
| 2022-05-12 00:25:14 +0200 | <lambdabot> | Data constructor not in scope: W# :: GHC.Prim.Word# -> t |
| 2022-05-12 00:27:04 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Remote host closed the connection) |
| 2022-05-12 00:28:47 +0200 | <raehik> | Also confuses me that I have to use "W# (f x y)" rather than "W# $ f x y". guess that's to do with $ and levities or sth |
| 2022-05-12 00:30:38 +0200 | marquis_andras | (~marquis_a@110-175-153-86.static.tpgi.com.au) (Ping timeout: 252 seconds) |
| 2022-05-12 00:30:49 +0200 | <geekosaur> | yes |
| 2022-05-12 00:30:54 +0200 | marquis_andras | (~marquis_a@110-175-153-86.static.tpgi.com.au) |
| 2022-05-12 00:31:08 +0200 | <geekosaur> | with respect to ghci, try -fno-it |
| 2022-05-12 00:31:30 +0200 | <geekosaur> | (ghci by default binds expressions to `it`, but its type is lifted) |
| 2022-05-12 00:32:51 +0200 | <geekosaur> | mm, that might not be enough if it goes to print it because `print` isn't levity polymorphic in its argument |
| 2022-05-12 00:33:10 +0200 | <raehik> | yeah, I'm getting the same error. thx for -fno-it, I didn't know that was how ghci worked |
| 2022-05-12 00:33:11 +0200 | <geekosaur> | probably also why lambdabot doesn't like it |
| 2022-05-12 00:33:58 +0200 | <geekosaur> | levity polymorphism is still a work in progress, I think |
| 2022-05-12 00:34:00 +0200 | <raehik> | is this just because avg Haskell programmers don't use unlifted types at the interpreter? |
| 2022-05-12 00:34:14 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-12 00:36:22 +0200 | <sm> | https://haskell-links.org has a simple UI now |
| 2022-05-12 00:37:11 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 00:37:22 +0200 | <geekosaur> | @let {-# OPTIONS_GHC -fprint-explicit-runtime-reps #-} |
| 2022-05-12 00:37:23 +0200 | <lambdabot> | Defined. |
| 2022-05-12 00:37:30 +0200 | <geekosaur> | :t ($) |
| 2022-05-12 00:37:31 +0200 | <lambdabot> | (a -> b) -> a -> b |
| 2022-05-12 00:37:47 +0200 | <geekosaur> | hm |
| 2022-05-12 00:37:55 +0200 | <geekosaur> | :t print |
| 2022-05-12 00:37:57 +0200 | <lambdabot> | Show a => a -> IO () |
| 2022-05-12 00:38:31 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 246 seconds) |
| 2022-05-12 00:38:57 +0200 | <geekosaur> | mm, iirc you can't have levity polymorphic Show either. but I don;t think that option "took" because ($) is partially levity polymorphic |
| 2022-05-12 00:40:55 +0200 | <geekosaur> | "No variable may have a levity-polymorphic type." |
| 2022-05-12 00:40:59 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 256 seconds) |
| 2022-05-12 00:41:07 +0200 | <geekosaur> | :t undefined |
| 2022-05-12 00:41:08 +0200 | <lambdabot> | a |
| 2022-05-12 00:41:09 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-05-12 00:41:22 +0200 | <geekosaur> | right, so lb doesn't handle levity at all |
| 2022-05-12 00:41:46 +0200 | <geekosaur> | and yahb is still out to lunch apparently |
| 2022-05-12 00:42:02 +0200 | <geekosaur> | % :set -fprint-explicit-runtime-reps |
| 2022-05-12 00:42:07 +0200 | <geekosaur> | feh |
| 2022-05-12 00:43:01 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-05-12 00:45:12 +0200 | <EvanR> | you can't always throw $ at the problem |
| 2022-05-12 00:46:05 +0200 | ojsaki | (~ojsaki@84.64.137.140) (Ping timeout: 256 seconds) |
| 2022-05-12 00:46:30 +0200 | dhil | (~dhil@cpc103052-sgyl39-2-0-cust260.18-2.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-05-12 00:47:09 +0200 | jao | (~mail@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) |
| 2022-05-12 00:50:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 00:50:40 +0200 | dextaa490 | (~dextaa@user/dextaa) |
| 2022-05-12 00:50:44 +0200 | dextaa49 | (~dextaa@user/dextaa) (Ping timeout: 248 seconds) |
| 2022-05-12 00:50:44 +0200 | dextaa490 | dextaa49 |
| 2022-05-12 00:53:03 +0200 | <hpc> | i just realized certain types of continuation passing style are literal technical debt |
| 2022-05-12 00:53:09 +0200 | <hpc> | because it can have a value of ($100) |
| 2022-05-12 00:53:46 +0200 | <hpc> | https://ux.stackexchange.com/a/1875 :P |
| 2022-05-12 00:53:50 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Quit: Konversation terminated!) |
| 2022-05-12 00:54:25 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-05-12 00:56:48 +0200 | <EvanR> | negativity shouldn't be surprising or attention grabbing. It's part of nature. You can't have shadow without light, or something |
| 2022-05-12 00:56:53 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-05-12 00:58:04 +0200 | <hpc> | there's probably a joke in there about higher-ranked types and having forall in a negative position too :D |
| 2022-05-12 00:58:17 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 00:58:33 +0200 | jmcarthur | (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 2022-05-12 00:58:58 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 00:59:33 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-05-12 00:59:53 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-05-12 01:00:05 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 01:01:10 +0200 | dsrt^ | (~dsrt@128-092-160-234.biz.spectrum.com) (Ping timeout: 240 seconds) |
| 2022-05-12 01:01:28 +0200 | causal | (~user@50.35.83.177) |
| 2022-05-12 01:01:49 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 01:03:20 +0200 | m1dnight | (~christoph@78-22-9-5.access.telenet.be) (Ping timeout: 248 seconds) |
| 2022-05-12 01:04:35 +0200 | dsrt^ | (~dsrt@128-092-160-234.biz.spectrum.com) |
| 2022-05-12 01:04:44 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2022-05-12 01:08:03 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-12 01:11:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 01:12:07 +0200 | stackdroid18 | (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-05-12 01:12:28 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 246 seconds) |
| 2022-05-12 01:17:14 +0200 | Kaiepi | (~Kaiepi@156.34.47.253) (Read error: Connection reset by peer) |
| 2022-05-12 01:18:50 +0200 | mmhat | (~mmh@2001:4090:a243:802a:ee08:6bff:fe09:5315) (Quit: WeeChat 3.5) |
| 2022-05-12 01:19:44 +0200 | Kaiepi | (~Kaiepi@156.34.47.253) |
| 2022-05-12 01:20:27 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 01:23:06 +0200 | jmcarthur | (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…) |
| 2022-05-12 01:25:37 +0200 | Guest052 | (~Guest0@cpe-24-165-41-186.hawaii.res.rr.com) |
| 2022-05-12 01:25:46 +0200 | dsrt^ | (~dsrt@128-092-160-234.biz.spectrum.com) (Ping timeout: 246 seconds) |
| 2022-05-12 01:26:15 +0200 | Guest052 | (~Guest0@cpe-24-165-41-186.hawaii.res.rr.com) (Client Quit) |
| 2022-05-12 01:27:49 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5) |
| 2022-05-12 01:31:45 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-12 01:32:26 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Quit: leaving) |
| 2022-05-12 01:32:43 +0200 | bitmapper | (uid464869@id-464869.lymington.irccloud.com) |
| 2022-05-12 01:34:04 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 240 seconds) |
| 2022-05-12 01:34:26 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 01:34:47 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-05-12 01:39:23 +0200 | zer0bitz | (~zer0bitz@2001:2003:f444:8f00:64b4:113a:8a62:5026) (Ping timeout: 252 seconds) |
| 2022-05-12 01:41:03 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 256 seconds) |
| 2022-05-12 01:43:05 +0200 | littlebo1eep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 01:44:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 01:45:35 +0200 | Kaipei | (~Kaiepi@156.34.47.253) |
| 2022-05-12 01:45:58 +0200 | m1dnight | (~christoph@78-22-9-5.access.telenet.be) |
| 2022-05-12 01:46:45 +0200 | xff0x | (~xff0x@b133147.ppp.asahi-net.or.jp) (Ping timeout: 260 seconds) |
| 2022-05-12 01:48:08 +0200 | mbuf | (~Shakthi@27.58.139.1) |
| 2022-05-12 01:48:11 +0200 | Kaiepi | (~Kaiepi@156.34.47.253) (Ping timeout: 252 seconds) |
| 2022-05-12 01:48:20 +0200 | xff0x | (~xff0x@b133147.ppp.asahi-net.or.jp) |
| 2022-05-12 01:51:19 +0200 | kaph | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) (Remote host closed the connection) |
| 2022-05-12 01:55:04 +0200 | littlebo1eep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 01:56:10 +0200 | kaph | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) |
| 2022-05-12 02:00:24 +0200 | kadobanana | (~mud@user/kadoban) (Remote host closed the connection) |
| 2022-05-12 02:00:49 +0200 | kadobanana | (~mud@user/kadoban) |
| 2022-05-12 02:01:12 +0200 | akurilin_ | (uid322841@id-322841.ilkley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-12 02:01:35 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2022-05-12 02:02:11 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 02:03:33 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-05-12 02:05:20 +0200 | mud | (~mud@user/kadoban) |
| 2022-05-12 02:06:12 +0200 | kadobanana | (~mud@user/kadoban) (Ping timeout: 276 seconds) |
| 2022-05-12 02:09:06 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 02:11:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 02:14:00 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 276 seconds) |
| 2022-05-12 02:14:45 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 02:17:49 +0200 | cyphase | (~cyphase@user/cyphase) |
| 2022-05-12 02:20:49 +0200 | Sweet | (~user@s19427110.onlinehome-server.info) |
| 2022-05-12 02:21:04 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 02:23:59 +0200 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 240 seconds) |
| 2022-05-12 02:24:51 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 02:31:32 +0200 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) |
| 2022-05-12 02:36:01 +0200 | xff0x | (~xff0x@b133147.ppp.asahi-net.or.jp) (Ping timeout: 256 seconds) |
| 2022-05-12 02:37:29 +0200 | noteness_ | (~noteness@user/noteness) |
| 2022-05-12 02:37:34 +0200 | noteness | (~noteness@user/noteness) (Ping timeout: 240 seconds) |
| 2022-05-12 02:37:48 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-12 02:38:39 +0200 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:39 +0200 | Ash[m] | (~signal-wa@2001:470:69fc:105::1:2318) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:39 +0200 | sm | (~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:39 +0200 | jmcantrell | (~jmcantrel@user/jmcantrell) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:47 +0200 | VarikValefor[m] | (~varikvale@2001:470:69fc:105::a5d) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:47 +0200 | yoggurt[m] | (~yoggurtma@2001:470:69fc:105::2:ba5) (Ping timeout: 252 seconds) |
| 2022-05-12 02:38:59 +0200 | ozataman[m] | (~ozatamanm@2001:470:69fc:105::1:faa0) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:59 +0200 | Inst[m] | (~instrmatr@2001:470:69fc:105::1:903e) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:59 +0200 | boxscape | (~boxscape@user/boxscape) (Ping timeout: 240 seconds) |
| 2022-05-12 02:38:59 +0200 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) (Ping timeout: 240 seconds) |
| 2022-05-12 02:39:00 +0200 | geekosaur[m][m] | (~geekosaur@2001:470:69fc:105::2:cb7) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:07 +0200 | kadoban | (~kadoban@user/kadoban) (Ping timeout: 240 seconds) |
| 2022-05-12 02:39:15 +0200 | fgaz | (~fgaz@2001:470:69fc:105::842) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | lyiriyah[m] | (~lyiriyahm@2001:470:69fc:105::cc0) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | RajatVerma[m] | (~rajatvmat@2001:470:69fc:105::1:fb34) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | jinsun_ | (~jinsun@user/jinsun) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | maralorn | (~maralorn@2001:470:69fc:105::251) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | juhp[m] | (~juhpmatri@2001:470:69fc:105::6e9) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | vaibhavsagar[m] | (~vaibhavsa@2001:470:69fc:105::ffe) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:18 +0200 | hughjfchen[m] | (~hughjfche@2001:470:69fc:105::c29d) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:18 +0200 | Andy[m] | (~anparrama@2001:470:69fc:105::1:6826) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:19 +0200 | Bulby[m] | (~bulbyvrma@2001:470:69fc:105::1:fe0a) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:19 +0200 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:19 +0200 | DemiMarieObenour | (~alwayscur@2001:470:69fc:105::4886) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:19 +0200 | ongy[m] | (~ongymatri@2001:470:69fc:105::5018) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:19 +0200 | vestige[m] | (~vestigema@2001:470:69fc:105::1:f9dd) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:19 +0200 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) (Ping timeout: 240 seconds) |
| 2022-05-12 02:39:19 +0200 | sjanssen | (~sjanssenm@2001:470:69fc:105::1:61d8) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | reza[m] | (~rezaphone@2001:470:69fc:105::3eda) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | sekun[m] | (~hsekmatri@2001:470:69fc:105::d18f) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | Guillaum[m] | (~guiboumat@2001:470:69fc:105::1:72ac) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | moats | (~oats@user/oats) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | yosef36 | (~yosefweis@2001:470:69fc:105::1:e501) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:19 +0200 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:20 +0200 | Orbstheorem | (~orbstheor@2001:470:69fc:105::a56) (Ping timeout: 256 seconds) |
| 2022-05-12 02:39:20 +0200 | oak- | (~oakuniver@2001:470:69fc:105::fcd) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:20 +0200 | rsify | (~rsify@2001:470:69fc:105::1:fd44) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:20 +0200 | SridharRatnakuma | (~sridmatri@2001:470:69fc:105::1c2) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:20 +0200 | sibnull[m] | (~sibnullma@2001:470:69fc:105::1:1291) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:20 +0200 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:20 +0200 | abastro[m] | (~abastroma@2001:470:69fc:105::1:e119) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:20 +0200 | Matthew|m | (~arathorn@2001:470:69fc:105::1f) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:21 +0200 | cdsmith | (~cdsmithma@2001:470:69fc:105::284) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:32 +0200 | ormaaj | (~ormaaj@user/ormaaj) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:32 +0200 | ArshiaAghaei[m] | (~arshiaagh@2001:470:69fc:105::1:c382) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:32 +0200 | Frikraaa[m] | (~odirfjohr@2001:470:69fc:105::1:f483) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:32 +0200 | AdityaAlok[m] | (~mradityaa@2001:470:69fc:105::1:ee36) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:32 +0200 | ishaan[m] | (~ishaanvma@2001:470:69fc:105::1:fb72) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:39 +0200 | july541[m] | (~july541ma@2001:470:69fc:105::1:e416) (Ping timeout: 240 seconds) |
| 2022-05-12 02:39:50 +0200 | dyniec[m] | (~dyniecmat@2001:470:69fc:105::2:a85) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:50 +0200 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:50 +0200 | Pikachu[m] | (~pychaumat@2001:470:69fc:105::2:1ce) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:50 +0200 | shlevy[m] | (~shlevymat@2001:470:69fc:105::1:d3b1) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:50 +0200 | Yehoshua | (~yehoshua@2001:470:69fc:105::1:593f) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:50 +0200 | zfnmxt | (~zfnmxtzfn@2001:470:69fc:105::2b32) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:51 +0200 | Tisoxin | (~ikosit@user/ikosit) (Ping timeout: 252 seconds) |
| 2022-05-12 02:39:53 +0200 | pareto-optimal-d | (~pareto-op@2001:470:69fc:105::1:b61f) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | peddie | (~peddie@2001:470:69fc:105::25d) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | Deide | (~deide@user/deide) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | psydroid | (~psydroid@user/psydroid) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | siraben | (~siraben@user/siraben) (Ping timeout: 260 seconds) |
| 2022-05-12 02:39:53 +0200 | schuelermine[m] | (~schuelerm@user/schuelermine) (Ping timeout: 248 seconds) |
| 2022-05-12 02:39:53 +0200 | fendor[m] | (~fendormat@2001:470:69fc:105::fcbd) (Ping timeout: 256 seconds) |
| 2022-05-12 02:41:22 +0200 | Benzi-Junior | (~BenziJuni@88-149-64-179.du.xdsl.is) (Ping timeout: 246 seconds) |
| 2022-05-12 02:42:30 +0200 | Benzi-Junior | (~BenziJuni@dsl-149-64-179.hive.is) |
| 2022-05-12 02:42:49 +0200 | comerijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-12 02:43:28 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
| 2022-05-12 02:47:24 +0200 | Benzi-Junior | (~BenziJuni@dsl-149-64-179.hive.is) (Ping timeout: 240 seconds) |
| 2022-05-12 02:47:51 +0200 | shailangsa_ | (~shailangs@host86-186-127-233.range86-186.btcentralplus.com) () |
| 2022-05-12 02:47:57 +0200 | jmcarthur | (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 2022-05-12 02:53:36 +0200 | sagax | (~sagax_nb@user/sagax) (Remote host closed the connection) |
| 2022-05-12 03:03:45 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2022-05-12 03:06:46 +0200 | frost | (~frost@user/frost) |
| 2022-05-12 03:08:26 +0200 | RajatVerma[m] | (~rajatvmat@2001:470:69fc:105::1:fb34) |
| 2022-05-12 03:10:33 +0200 | VarikValefor[m] | (~varikvale@2001:470:69fc:105::a5d) |
| 2022-05-12 03:10:50 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) (Remote host closed the connection) |
| 2022-05-12 03:10:51 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-05-12 03:11:36 +0200 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) |
| 2022-05-12 03:11:37 +0200 | lyiriyah[m] | (~lyiriyahm@2001:470:69fc:105::cc0) |
| 2022-05-12 03:11:56 +0200 | mtjm | (~mutantmel@2604:a880:2:d0::208b:d001) |
| 2022-05-12 03:12:19 +0200 | sm | (~sm@plaintextaccounting/sm) |
| 2022-05-12 03:12:30 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 260 seconds) |
| 2022-05-12 03:13:14 +0200 | jinsun_ | (~jinsun@user/jinsun) |
| 2022-05-12 03:13:17 +0200 | DemiMarieObenour | (~alwayscur@2001:470:69fc:105::4886) |
| 2022-05-12 03:13:51 +0200 | jmcantrell | (~jmcantrel@user/jmcantrell) |
| 2022-05-12 03:14:01 +0200 | yoggurt[m] | (~yoggurtma@2001:470:69fc:105::2:ba5) |
| 2022-05-12 03:15:02 +0200 | juhp[m] | (~juhpmatri@2001:470:69fc:105::6e9) |
| 2022-05-12 03:15:08 +0200 | vaibhavsagar[m] | (~vaibhavsa@2001:470:69fc:105::ffe) |
| 2022-05-12 03:15:10 +0200 | maralorn | (~maralorn@2001:470:69fc:105::251) |
| 2022-05-12 03:15:57 +0200 | fgaz | (~fgaz@2001:470:69fc:105::842) |
| 2022-05-12 03:16:47 +0200 | kadoban | (~kadoban@user/kadoban) |
| 2022-05-12 03:16:58 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-05-12 03:17:17 +0200 | Ash[m] | (~signal-wa@2001:470:69fc:105::1:2318) |
| 2022-05-12 03:17:23 +0200 | vestige[m] | (~vestigema@2001:470:69fc:105::1:f9dd) |
| 2022-05-12 03:17:26 +0200 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) |
| 2022-05-12 03:18:58 +0200 | xff0x | (~xff0x@125x102x200x106.ap125.ftth.ucom.ne.jp) |
| 2022-05-12 03:19:51 +0200 | Guillaum[m] | (~guiboumat@2001:470:69fc:105::1:72ac) |
| 2022-05-12 03:20:35 +0200 | inversed_ | (~inversed@176.248.27.211) |
| 2022-05-12 03:20:35 +0200 | ubert1 | (~Thunderbi@p200300ecdf158806117918b760ecf219.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-05-12 03:20:47 +0200 | inversed | (~inversed@176.248.27.211) (Ping timeout: 256 seconds) |
| 2022-05-12 03:21:42 +0200 | psydroid | (~psydroid@user/psydroid) |
| 2022-05-12 03:22:14 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2022-05-12 03:22:21 +0200 | Orbstheorem | (~orbstheor@2001:470:69fc:105::a56) |
| 2022-05-12 03:22:44 +0200 | dextaa49 | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-05-12 03:22:57 +0200 | cdsmith | (~cdsmithma@2001:470:69fc:105::284) |
| 2022-05-12 03:26:23 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 2022-05-12 03:26:32 +0200 | yosef36 | (~yosefweis@2001:470:69fc:105::1:e501) |
| 2022-05-12 03:27:55 +0200 | geekosaur[m][m] | (~geekosaur@2001:470:69fc:105::2:cb7) |
| 2022-05-12 03:28:02 +0200 | reza[m] | (~rezaphone@2001:470:69fc:105::3eda) |
| 2022-05-12 03:28:39 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 240 seconds) |
| 2022-05-12 03:29:17 +0200 | shailangsa | (~shailangs@host86-186-127-233.range86-186.btcentralplus.com) |
| 2022-05-12 03:29:50 +0200 | sekun[m] | (~hsekmatri@2001:470:69fc:105::d18f) |
| 2022-05-12 03:30:16 +0200 | ishaan[m] | (~ishaanvma@2001:470:69fc:105::1:fb72) |
| 2022-05-12 03:31:21 +0200 | rekahsoft | (~rekahsoft@bras-base-wdston4533w-grc-02-142-113-160-8.dsl.bell.ca) |
| 2022-05-12 03:32:42 +0200 | ArshiaAghaei[m] | (~arshiaagh@2001:470:69fc:105::1:c382) |
| 2022-05-12 03:32:42 +0200 | hughjfchen[m] | (~hughjfche@2001:470:69fc:105::c29d) |
| 2022-05-12 03:32:59 +0200 | sagax | (~sagax_nb@user/sagax) |
| 2022-05-12 03:33:17 +0200 | boxscape | (~boxscape@user/boxscape) |
| 2022-05-12 03:33:56 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 03:35:01 +0200 | Matthew|m | (~arathorn@2001:470:69fc:105::1f) |
| 2022-05-12 03:35:12 +0200 | AdityaAlok[m] | (~mradityaa@2001:470:69fc:105::1:ee36) |
| 2022-05-12 03:35:29 +0200 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) |
| 2022-05-12 03:37:35 +0200 | Bulby[m] | (~bulbyvrma@2001:470:69fc:105::1:fe0a) |
| 2022-05-12 03:38:11 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 2022-05-12 03:38:21 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 2022-05-12 03:38:21 +0200 | schuelermine[m] | (~schuelerm@user/schuelermine) |
| 2022-05-12 03:38:56 +0200 | Andy[m] | (~anparrama@2001:470:69fc:105::1:6826) |
| 2022-05-12 03:39:03 +0200 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) |
| 2022-05-12 03:39:21 +0200 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) |
| 2022-05-12 03:40:02 +0200 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) |
| 2022-05-12 03:40:09 +0200 | ormaaj | (~ormaaj@user/ormaaj) |
| 2022-05-12 03:40:19 +0200 | sjanssen | (~sjanssenm@2001:470:69fc:105::1:61d8) |
| 2022-05-12 03:40:36 +0200 | ozataman[m] | (~ozatamanm@2001:470:69fc:105::1:faa0) |
| 2022-05-12 03:44:21 +0200 | Inst[m] | (~instrmatr@2001:470:69fc:105::1:903e) |
| 2022-05-12 03:44:22 +0200 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) |
| 2022-05-12 03:46:55 +0200 | <monochrom> | Late to the conversation, but indeed a forall in a negative position is usually inside parentheses, too. Perfect. |
| 2022-05-12 03:47:11 +0200 | feliix42 | (~felix@gibbs.uberspace.de) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2022-05-12 03:47:25 +0200 | feliix42 | (~felix@gibbs.uberspace.de) |
| 2022-05-12 03:48:07 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) (Ping timeout: 250 seconds) |
| 2022-05-12 03:48:08 +0200 | Orbstheorem | (~orbstheor@2001:470:69fc:105::a56) (Ping timeout: 250 seconds) |
| 2022-05-12 03:48:08 +0200 | lyiriyah[m] | (~lyiriyahm@2001:470:69fc:105::cc0) (Ping timeout: 250 seconds) |
| 2022-05-12 03:48:08 +0200 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) (Ping timeout: 250 seconds) |
| 2022-05-12 03:48:24 +0200 | reza[m] | (~rezaphone@2001:470:69fc:105::3eda) (Ping timeout: 250 seconds) |
| 2022-05-12 03:48:25 +0200 | kadoban | (~kadoban@user/kadoban) (Ping timeout: 250 seconds) |
| 2022-05-12 03:48:37 +0200 | Inst[m] | (~instrmatr@2001:470:69fc:105::1:903e) (Ping timeout: 240 seconds) |
| 2022-05-12 03:48:38 +0200 | ishaan[m] | (~ishaanvma@2001:470:69fc:105::1:fb72) (Ping timeout: 240 seconds) |
| 2022-05-12 03:48:46 +0200 | Deide | (~deide@user/deide) |
| 2022-05-12 03:49:22 +0200 | fendor[m] | (~fendormat@2001:470:69fc:105::fcbd) |
| 2022-05-12 03:49:46 +0200 | Frikraaa[m] | (~odirfjohr@2001:470:69fc:105::1:f483) |
| 2022-05-12 03:49:49 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-05-12 03:50:53 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 03:51:19 +0200 | jao | (~mail@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)) |
| 2022-05-12 03:52:14 +0200 | ongy[m] | (~ongymatri@2001:470:69fc:105::5018) |
| 2022-05-12 03:53:28 +0200 | slac91684 | (~slack1256@186.11.61.142) (Ping timeout: 246 seconds) |
| 2022-05-12 03:53:33 +0200 | moats | (~oats@user/oats) |
| 2022-05-12 03:54:07 +0200 | Pikachu[m] | (~pychaumat@2001:470:69fc:105::2:1ce) |
| 2022-05-12 03:55:30 +0200 | andrey__ | (~andrey@p200300dbcf15e00051e3a882b5958800.dip0.t-ipconnect.de) |
| 2022-05-12 03:55:41 +0200 | zfnmxt | (~zfnmxtzfn@2001:470:69fc:105::2b32) |
| 2022-05-12 03:55:47 +0200 | peddie | (~peddie@2001:470:69fc:105::25d) |
| 2022-05-12 03:56:14 +0200 | siraben | (~siraben@user/siraben) |
| 2022-05-12 03:56:15 +0200 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) |
| 2022-05-12 03:57:48 +0200 | andrey_ | (~andrey@p200300dbcf0a9400bb18378afbd4165e.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-05-12 03:57:49 +0200 | sibnull[m] | (~sibnullma@2001:470:69fc:105::1:1291) |
| 2022-05-12 03:58:11 +0200 | abastro[m] | (~abastroma@2001:470:69fc:105::1:e119) |
| 2022-05-12 03:58:25 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-12 03:58:33 +0200 | Las[m] | (~lasmatrix@2001:470:69fc:105::74e) |
| 2022-05-12 03:59:05 +0200 | rsify | (~rsify@2001:470:69fc:105::1:fd44) |
| 2022-05-12 03:59:46 +0200 | shlevy[m] | (~shlevymat@2001:470:69fc:105::1:d3b1) |
| 2022-05-12 04:01:12 +0200 | dyniec[m] | (~dyniecmat@2001:470:69fc:105::2:a85) |
| 2022-05-12 04:01:53 +0200 | pareto-optimal-d | (~pareto-op@2001:470:69fc:105::1:b61f) |
| 2022-05-12 04:02:39 +0200 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) |
| 2022-05-12 04:04:23 +0200 | <energizer> | is there a good document that says what 'composition' means? |
| 2022-05-12 04:04:25 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 256 seconds) |
| 2022-05-12 04:05:00 +0200 | SridharRatnakuma | (~sridmatri@2001:470:69fc:105::1c2) |
| 2022-05-12 04:05:12 +0200 | oak- | (~oakuniver@2001:470:69fc:105::fcd) |
| 2022-05-12 04:05:18 +0200 | <Axman6> | it means whatever you want it to mean when you use it. I composed my lunch with myself using the `eat` function |
| 2022-05-12 04:06:14 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Ping timeout: 252 seconds) |
| 2022-05-12 04:06:20 +0200 | <Axman6> | though, I feel like one common theme when talking about pomposition is that if you have two things of the same "type", composing them results in something also of the same "type" (using type losely here, more broad than Haskell type" |
| 2022-05-12 04:06:30 +0200 | july541[m] | (~july541ma@2001:470:69fc:105::1:e416) |
| 2022-05-12 04:06:31 +0200 | <Axman6> | composition too* |
| 2022-05-12 04:06:35 +0200 | <EvanR> | the cat class has a meow method, so you can compose cat with meow, to get... IO? |
| 2022-05-12 04:07:08 +0200 | Tisoxin | (~ikosit@user/ikosit) |
| 2022-05-12 04:07:30 +0200 | <Axman6> | so, we can compose functions to get more functions |
| 2022-05-12 04:07:49 +0200 | <Axman6> | we can compose monadic actions to get new monadic actions |
| 2022-05-12 04:08:14 +0200 | Yehoshua | (~yehoshua@2001:470:69fc:105::1:593f) |
| 2022-05-12 04:08:18 +0200 | <EvanR> | lego bricks of the appropriate type combine to form a bigger lego |
| 2022-05-12 04:08:35 +0200 | <monochrom> | At the basic level, it just means combining. At a more nuanced level, it also means that the meaning of the combined can be easily figured out from the individual meanings of the components. |
| 2022-05-12 04:09:03 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-05-12 04:09:03 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-05-12 04:09:03 +0200 | finn_elija | FinnElija |
| 2022-05-12 04:09:11 +0200 | <energizer> | that "more nuanced level" sounds like it means "denotational semantics" |
| 2022-05-12 04:09:26 +0200 | <EvanR> | in web languages, a pile of sand combines with a pile of sand to form a bigger pile of sand. So web programming is compositional |
| 2022-05-12 04:09:46 +0200 | <monochrom> | Yes that's one purpose of denotational semantics. |
| 2022-05-12 04:10:12 +0200 | <energizer> | EvanR: that's the `f a a -> a` signature that Axman6 was talking about |
| 2022-05-12 04:10:30 +0200 | Inst[m] | (~instrmatr@2001:470:69fc:105::1:903e) |
| 2022-05-12 04:10:41 +0200 | EvanR | scrolls up |
| 2022-05-12 04:10:58 +0200 | <energizer> | <Axman6> though, I feel like one common theme when talking about pomposition is that if you have two things of the same "type", composing them results in something also of the same "type" (using type losely here, more broad than Haskell type" |
| 2022-05-12 04:11:55 +0200 | <energizer> | which i'd usually use the word "closed" for |
| 2022-05-12 04:12:11 +0200 | <EvanR> | has types at all really covers a lot of that ground |
| 2022-05-12 04:12:13 +0200 | <energizer> | as in 'a is closed under f |
| 2022-05-12 04:13:27 +0200 | <EvanR> | a binary f algebra, or something |
| 2022-05-12 04:13:46 +0200 | Orbstheorem | (~orbstheor@2001:470:69fc:105::a56) |
| 2022-05-12 04:13:48 +0200 | <EvanR> | actually why are there two parameters |
| 2022-05-12 04:13:57 +0200 | <EvanR> | f a -> a |
| 2022-05-12 04:14:13 +0200 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) |
| 2022-05-12 04:14:52 +0200 | <EvanR> | note this doesn't cover the form for function composition |
| 2022-05-12 04:16:16 +0200 | lyiriyah[m] | (~lyiriyahm@2001:470:69fc:105::cc0) |
| 2022-05-12 04:16:50 +0200 | noiobeforebed | (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 2022-05-12 04:17:10 +0200 | nate1 | (~nate@98.45.169.16) |
| 2022-05-12 04:19:01 +0200 | kadoban | (~kadoban@user/kadoban) |
| 2022-05-12 04:20:24 +0200 | reza[m] | (~rezaphone@2001:470:69fc:105::3eda) |
| 2022-05-12 04:21:22 +0200 | ishaan[m] | (~ishaanvma@2001:470:69fc:105::1:fb72) |
| 2022-05-12 04:28:13 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Ping timeout: 256 seconds) |
| 2022-05-12 04:29:35 +0200 | jmcarthur | (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…) |
| 2022-05-12 04:30:50 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-05-12 04:33:10 +0200 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2022-05-12 04:33:44 +0200 | EvanR | (~EvanR@user/evanr) |
| 2022-05-12 04:33:54 +0200 | EvanR_ | (~EvanR@user/evanr) |
| 2022-05-12 04:33:56 +0200 | EvanR | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2022-05-12 04:34:47 +0200 | EvanR_ | (~EvanR@user/evanr) (Remote host closed the connection) |
| 2022-05-12 04:35:28 +0200 | EvanR | (~EvanR@user/evanr) |
| 2022-05-12 04:43:30 +0200 | Kaipei | (~Kaiepi@156.34.47.253) (Ping timeout: 240 seconds) |
| 2022-05-12 04:44:52 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 248 seconds) |
| 2022-05-12 04:45:05 +0200 | <Axman6> | anyone know what the state of Haskell -. WebAssembly is at the moment? |
| 2022-05-12 04:47:47 +0200 | <geekosaur> | best asked in #ghc, but work is ongoing and last I heard was still targeting 9.6 |
| 2022-05-12 04:48:22 +0200 | steven | (~steven@2600:1700:ce00:1ca0:679b:14af:bf5c:9d0d) |
| 2022-05-12 04:48:49 +0200 | <Axman6> | oh interesting, and I'm glad to hear that - so many of these projects get stuck on one GHC version and just die. I wonder if the work over the last few years to make GHC more... modular? maintainable? ... has improved things on that front at all |
| 2022-05-12 04:49:19 +0200 | <Axman6> | it'd be fantastic if GHC proper shipped with WASM support, would be great to see it as a first class target |
| 2022-05-12 04:49:41 +0200 | jargon | (~jargon@174-22-206-112.phnx.qwest.net) |
| 2022-05-12 04:50:05 +0200 | <geekosaur> | milestone for 9.6 indeed shows wasm |
| 2022-05-12 04:50:13 +0200 | <Axman6> | D: |
| 2022-05-12 04:51:05 +0200 | <Axman6> | I didn't realise its development was that closely tied to GHC's development, that's great news |
| 2022-05-12 04:51:19 +0200 | <steven> | hello, I have a package versioning question. I just became the maintainer for microlens and I'm trying to upgrade it to support mtl-2.3. I see that mtl 2.3 has removed the type classes for ListT and ErrorT. microlens-mtl defines instances for these classes, so my thinking is to remove the instances, increase the lower-bound on the mtl dependency to |
| 2022-05-12 04:51:20 +0200 | <steven> | 2.3 and release a new major version with these changes. Is that the correct thing to do, or is there a better way? |
| 2022-05-12 04:51:24 +0200 | <geekosaur> | https://gitlab.haskell.org/ghc/ghc/-/milestones/375 fwiw |
| 2022-05-12 04:52:13 +0200 | <Axman6> | steven: my first thought is to use CPP to define those instances when mtl is in a version range where they exist |
| 2022-05-12 04:53:47 +0200 | <c_wraith> | ugh. that just ruins the docs. |
| 2022-05-12 04:54:21 +0200 | <c_wraith> | instances that only exist sometimes really are annoying. |
| 2022-05-12 04:54:43 +0200 | <steven> | ah yes that's an option too |
| 2022-05-12 04:55:21 +0200 | <steven> | but I wonder if it can result in explosion? e.g. over time the project could accumulate lots of checks for different versions |
| 2022-05-12 04:55:22 +0200 | <c_wraith> | please have the existence of an instance vary based on package version rather than a build-time check of some sort. |
| 2022-05-12 04:55:55 +0200 | <steven> | yeah, I prefer not to resort to CPP but I'm new to this so I want to understand what others usually do first |
| 2022-05-12 04:56:23 +0200 | <c_wraith> | It's a rare situation. Instances don't usually go away after having been around for decades. |
| 2022-05-12 04:56:25 +0200 | <steven> | and also if I'm using CPP, how do I decide when to stop supporting the old version? Seems that it becomes more arbitrary then |
| 2022-05-12 04:58:17 +0200 | <steven> | longshot maybe but does anyone know of libraries that have done the migration to mtl 2.3? I'd want to see how they did it |
| 2022-05-12 05:07:08 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-12 05:08:04 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2022-05-12 05:10:52 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-12 05:12:34 +0200 | erenyaegerdidnot | (~erenyaege@2600:1700:4010:55c0::1f) |
| 2022-05-12 05:13:46 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 05:15:48 +0200 | erenyaegerdidnot | (~erenyaege@2600:1700:4010:55c0::1f) (Client Quit) |
| 2022-05-12 05:15:49 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 256 seconds) |
| 2022-05-12 05:17:24 +0200 | searemind | (~u0_a2219@122.161.48.197) |
| 2022-05-12 05:18:22 +0200 | searemind | (~u0_a2219@122.161.48.197) (Client Quit) |
| 2022-05-12 05:20:21 +0200 | <sm> | this sounds like the kind of thing https://hackage.haskell.org/package/mtl-compat should help with but it probably isn't up to date |
| 2022-05-12 05:46:10 +0200 | nate1 | (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 2022-05-12 05:47:40 +0200 | <steven> | interesting, thank you sm. I can at least see how they're doing it |
| 2022-05-12 05:56:40 +0200 | akurilin_ | (uid322841@id-322841.ilkley.irccloud.com) |
| 2022-05-12 05:58:21 +0200 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-05-12 05:59:35 +0200 | zaquest | (~notzaques@5.130.79.72) |
| 2022-05-12 05:59:59 +0200 | dsrt^ | (~dsrt@128-092-160-234.biz.spectrum.com) |
| 2022-05-12 06:05:57 +0200 | odnes | (~odnes@5-203-212-41.pat.nym.cosmote.net) |
| 2022-05-12 06:05:58 +0200 | <steven> | The CPP fix seems simple enough so I think I will do that. Now my question is: should this be considered a minor upgrade? Technically I am removing a typeclass instance but only if the class instance is not there to begin with, so I think any breakage would be attributable to someone upgrading their mtl lower bound, not the microlens one. So I |
| 2022-05-12 06:05:59 +0200 | <steven> | think this is a minor upgrade but want to make sure this makes sense |
| 2022-05-12 06:06:28 +0200 | Kaipei | (~Kaiepi@156.34.47.253) |
| 2022-05-12 06:06:29 +0200 | <steven> | correction: only if the class* is not there (not class instance) |
| 2022-05-12 06:06:52 +0200 | jargon | (~jargon@174-22-206-112.phnx.qwest.net) (Remote host closed the connection) |
| 2022-05-12 06:08:10 +0200 | kaph | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) (Ping timeout: 240 seconds) |
| 2022-05-12 06:11:15 +0200 | shriekingnoise | (~shrieking@201.231.16.156) (Ping timeout: 276 seconds) |
| 2022-05-12 06:16:50 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-05-12 06:30:45 +0200 | rekahsoft | (~rekahsoft@bras-base-wdston4533w-grc-02-142-113-160-8.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 2022-05-12 06:30:47 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-05-12 06:32:55 +0200 | benin | (~benin@183.82.31.174) |
| 2022-05-12 06:35:33 +0200 | <Axman6> | yeah IMO it would be a minor version, if they are using a version of mtl new enough, they couldn't possibly use the instances, and microlens is just accommodating that - definitely better to have microlens keep supporting those instance if someone is using them and limiting themselves to that older versions of mtl |
| 2022-05-12 06:51:54 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-05-12 06:54:22 +0200 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-05-12 06:56:39 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 06:58:36 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 07:00:06 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 07:01:01 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-12 07:04:22 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-05-12 07:05:11 +0200 | Vajb | (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) |
| 2022-05-12 07:09:02 +0200 | <jackdk> | `ListT` and `ErrorT` specifically have been warning devs away from them for a very long time. I think you'd be within your rights to bundle up all pending nonbreaking changes, release, then raise the lower bound on `mtl` |
| 2022-05-12 07:12:35 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 07:13:30 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 07:13:42 +0200 | steven | (~steven@2600:1700:ce00:1ca0:679b:14af:bf5c:9d0d) (Ping timeout: 252 seconds) |
| 2022-05-12 07:18:05 +0200 | raym | (~raym@user/raym) (Quit: kernel update, rebooting...) |
| 2022-05-12 07:18:10 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-05-12 07:21:40 +0200 | raym | (~raym@user/raym) |
| 2022-05-12 07:24:04 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 07:28:40 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2022-05-12 07:29:03 +0200 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2022-05-12 07:35:16 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) |
| 2022-05-12 07:36:11 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Read error: Connection reset by peer) |
| 2022-05-12 07:36:24 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) |
| 2022-05-12 07:49:06 +0200 | ryanbooker | (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-12 07:52:39 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 07:53:36 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 07:57:53 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-12 07:59:32 +0200 | Guest39 | (~Guest39@50-204-42-240-static.hfc.comcastbusiness.net) |
| 2022-05-12 08:04:50 +0200 | Guest39 | (~Guest39@50-204-42-240-static.hfc.comcastbusiness.net) (Quit: Client closed) |
| 2022-05-12 08:07:13 +0200 | m1dnight | (~christoph@78-22-9-5.access.telenet.be) (Read error: Connection reset by peer) |
| 2022-05-12 08:07:42 +0200 | m1dnight | (~christoph@78-22-9-5.access.telenet.be) |
| 2022-05-12 08:10:25 +0200 | echoreply | (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 2022-05-12 08:11:17 +0200 | echoreply | (~echoreply@45.32.163.16) |
| 2022-05-12 08:13:35 +0200 | EvanR | (~EvanR@user/evanr) (Ping timeout: 260 seconds) |
| 2022-05-12 08:16:00 +0200 | mikoto-chan | (~mikoto-ch@84.199.144.234) |
| 2022-05-12 08:16:37 +0200 | EvanR | (~EvanR@user/evanr) |
| 2022-05-12 08:17:09 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 08:19:38 +0200 | EvanR_ | (~EvanR@user/evanr) |
| 2022-05-12 08:22:27 +0200 | EvanR | (~EvanR@user/evanr) (Ping timeout: 260 seconds) |
| 2022-05-12 08:25:37 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 08:28:22 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-12 08:30:31 +0200 | xkuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-05-12 08:32:20 +0200 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) |
| 2022-05-12 08:32:37 +0200 | <lechner> | Hi, a lot of folks here work with Nix. Is anyone using Guix? |
| 2022-05-12 08:33:00 +0200 | acidjnk_new | (~acidjnk@p200300d0c7068b99195ba74fc017953f.dip0.t-ipconnect.de) |
| 2022-05-12 08:33:34 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 240 seconds) |
| 2022-05-12 08:35:50 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) (Ping timeout: 240 seconds) |
| 2022-05-12 08:38:48 +0200 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) (Ping timeout: 276 seconds) |
| 2022-05-12 08:43:55 +0200 | <tomsmeding> | [exa]: I feel like the issue in your second paste is that you're not lifting the withRunInIO into m |
| 2022-05-12 08:46:39 +0200 | <dminuoso> | When I look at readCreateProcess from process-extras https://hackage.haskell.org/package/process-extras-0.7.4/docs/src/System-Process-Common.html#readC… it seems the code will block on reading stderr/stdout first, and then waitForProcess |
| 2022-05-12 08:46:47 +0200 | <dminuoso> | Is this the correct methodology? |
| 2022-05-12 08:47:12 +0200 | <dminuoso> | Or rather, when the running process exits, is it guaranteed it will close its fds 0, 1 and 2? |
| 2022-05-12 08:48:03 +0200 | <tomsmeding> | dminuoso: "it" won't, the kernel will; but they won't be closed on your side if there is some other process that is still alive that they're sharing the file descriptors with |
| 2022-05-12 08:49:25 +0200 | <[exa]> | tomsmeding: yeah I found it later, lift is the new teleport :D |
| 2022-05-12 08:49:35 +0200 | nschoe | (~quassel@178.251.84.79) |
| 2022-05-12 08:49:37 +0200 | <[exa]> | thanks for help though, it really required a bit of rubberducking :] |
| 2022-05-12 08:49:44 +0200 | <tomsmeding> | boo I just wrote it too https://paste.tomsmeding.com/2isbwy2Z |
| 2022-05-12 08:50:03 +0200 | <[exa]> | tomsmeding: I send back some positive energy |
| 2022-05-12 08:50:06 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-05-12 08:50:09 +0200 | <tomsmeding> | :D |
| 2022-05-12 08:51:54 +0200 | <dminuoso> | tomsmeding: Mmm, is there a connection to what `readProcess` does https://hackage.haskell.org/package/process-1.6.14.0/docs/src/System.Process.html#readCreateProcess |
| 2022-05-12 08:52:21 +0200 | <[exa]> | dminuoso: unixy exit() must close all open FDs |
| 2022-05-12 08:52:47 +0200 | <[exa]> | dminuoso: unless the process is terminated, at which point you might be getting sigpipes etc |
| 2022-05-12 08:53:38 +0200 | slack1256 | (~slack1256@186.11.58.142) |
| 2022-05-12 08:54:06 +0200 | <[exa]> | in your case though, the event "process dies" generates completely independent events "EOF can be read at stdout and stderr" and "status can be collected" |
| 2022-05-12 08:54:09 +0200 | <tomsmeding> | dminuoso: that one seems to wait on output and on waitForProcess in parallel |
| 2022-05-12 08:54:11 +0200 | <dminuoso> | Ahh hold on, the difference in `readProcess` is that it just defers the out reader to lazy hGetContents |
| 2022-05-12 08:54:23 +0200 | <dminuoso> | Its still the same |
| 2022-05-12 08:54:33 +0200 | <dminuoso> | Its just slightly less obvious |
| 2022-05-12 08:54:38 +0200 | <tomsmeding> | no it waits on them in parallel |
| 2022-05-12 08:54:49 +0200 | <tomsmeding> | it waits on the output in a forked thread, and waits on the process in the main thread |
| 2022-05-12 08:55:09 +0200 | <tomsmeding> | whereas the process-extras link you sent earlier waits on the output _before_ waiting on the process |
| 2022-05-12 08:55:12 +0200 | <dminuoso> | https://hackage.haskell.org/package/process-1.6.14.0/docs/src/System.Process.html#readCreateProces… |
| 2022-05-12 08:55:35 +0200 | <dminuoso> | Well yeah we should be comparing it with that I suppose |
| 2022-05-12 08:55:38 +0200 | <tomsmeding> | though the 'process' version does kind of implicitly assume that 'output' has been forced at the time the process exits :p |
| 2022-05-12 08:55:50 +0200 | <tomsmeding> | same structure, just with stderr in |
| 2022-05-12 08:55:52 +0200 | <dminuoso> | tomsmeding: Right, so Im wondering whether the order to wait in is irrelevant here |
| 2022-05-12 08:56:10 +0200 | dextaa490 | (~dextaa@user/dextaa) |
| 2022-05-12 08:56:22 +0200 | <tomsmeding> | it's not, you must allow data from stdout/stderr to flow into your program while (or before) waiting on process exit |
| 2022-05-12 08:56:27 +0200 | <tomsmeding> | because otherwise buffer full |
| 2022-05-12 08:56:45 +0200 | <tomsmeding> | personally I'd wait on both events in parallel, but not sure whether that's necessary |
| 2022-05-12 08:56:50 +0200 | <dminuoso> | Okay that makes sense, so I must at least start reading stdout before waiting, but it shouldnt matter what to *wait* on right? |
| 2022-05-12 08:57:16 +0200 | <dminuoso> | Should really look at POSIX specifications for pipes here |
| 2022-05-12 08:57:16 +0200 | <tomsmeding> | I would say that's correct |
| 2022-05-12 08:57:21 +0200 | <tomsmeding> | yeah :') |
| 2022-05-12 08:57:45 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-05-12 08:58:12 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-05-12 08:58:20 +0200 | <tomsmeding> | I see that in my playground I consume out/err in a thread while waiting on the process, which is consistent with what I think is safest -- yay me being consistent over time |
| 2022-05-12 08:58:36 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-05-12 08:59:21 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (Client Quit) |
| 2022-05-12 08:59:29 +0200 | <tomsmeding> | for the interested readers it's here, but don't use it as example code because I know less about this than the 'process' etc. authors https://github.com/tomsmeding/pastebin-haskell/blob/play/GHCPool.hs#L106 |
| 2022-05-12 08:59:55 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-05-12 09:00:21 +0200 | <dminuoso> | tomsmeding: that somewhat suggests I should start reading from stdout even before the process is created. |
| 2022-05-12 09:00:32 +0200 | <tomsmeding> | what's "that"? |
| 2022-05-12 09:01:12 +0200 | <dminuoso> | │08:56:22 tomsmeding | it's not, you must allow data from stdout/stderr to flow into your program while (or before) waiting on process exit │ barrucadu |
| 2022-05-12 09:01:23 +0200 | <tomsmeding> | nice irc window copy |
| 2022-05-12 09:01:29 +0200 | <dminuoso> | Otherwise I might have a race that in the time when the process is already created but before I read the buffers are filled up already |
| 2022-05-12 09:01:33 +0200 | <dminuoso> | Heh. |
| 2022-05-12 09:01:40 +0200 | <tomsmeding> | nobody cares about that, right? |
| 2022-05-12 09:01:40 +0200 | <dminuoso> | New weechat layout, still sorting things out |
| 2022-05-12 09:01:55 +0200 | <dminuoso> | What do you mean by nobody cares about that? |
| 2022-05-12 09:01:59 +0200 | <tomsmeding> | if buffers are full, then the process won't make progress, but do you care about that if you start emptying the buffers soon afterwards anyway |
| 2022-05-12 09:02:13 +0200 | <tomsmeding> | is it relevant that the process stalled for a very short time |
| 2022-05-12 09:02:27 +0200 | <dminuoso> | That would depend on whether the writing process handles this correctly |
| 2022-05-12 09:02:54 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-05-12 09:02:59 +0200 | <dminuoso> | If say non-blocking write on stdout was used, without the assumption that it could fail |
| 2022-05-12 09:03:12 +0200 | <tomsmeding> | then the program is ill-written lol |
| 2022-05-12 09:03:16 +0200 | <tomsmeding> | non-blocking write _can_ fail |
| 2022-05-12 09:03:21 +0200 | <dminuoso> | I guess |
| 2022-05-12 09:03:36 +0200 | <tomsmeding> | you should assume it to fail, that's the whole point of the non-blocking API |
| 2022-05-12 09:03:41 +0200 | <tomsmeding> | if you wanted non-failure, use the blocking API |
| 2022-05-12 09:04:14 +0200 | <tomsmeding> | what if you redirect the process to a file on spinning rust, and the process spams stdout as fast as it can using non-blocking writes that it doesn't check failure on |
| 2022-05-12 09:04:21 +0200 | <tomsmeding> | then the writes _will_ fill up the buffer and _will_ fail |
| 2022-05-12 09:04:29 +0200 | chele | (~chele@user/chele) |
| 2022-05-12 09:05:34 +0200 | <tomsmeding> | dminuoso: re weechat, try alt-L |
| 2022-05-12 09:06:28 +0200 | <dminuoso> | Ah nice, I did not know this key combination |
| 2022-05-12 09:06:29 +0200 | <tomsmeding> | also, you should assume that as consuming process you're not fast enough for the writing process; this might also happen on a single-core CPU where the other process gets more time slots than you |
| 2022-05-12 09:06:38 +0200 | <dminuoso> | That's very useful |
| 2022-05-12 09:06:47 +0200 | <tomsmeding> | so the situation you were worrying about can happen anyway, even if you read as soon as possible |
| 2022-05-12 09:07:03 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 2022-05-12 09:07:20 +0200 | <tomsmeding> | dminuoso: in alt-L mode weechat exits the alternate-screen I think, so it's actual wrapping text that copies nicely |
| 2022-05-12 09:07:23 +0200 | dminuoso | just wants to do image manipulation with imagemagick |
| 2022-05-12 09:07:41 +0200 | <[exa]> | y u no juicypixels |
| 2022-05-12 09:07:46 +0200 | <tomsmeding> | your client program is imagemagick? That handles writes correctly, it's too famous a program |
| 2022-05-12 09:07:49 +0200 | <dminuoso> | but we dont have any up-to-date bindings, so Im trying to figure out how to correctly invoke the binary with binary in/output |
| 2022-05-12 09:07:59 +0200 | <[exa]> | also, tmpfiles rock |
| 2022-05-12 09:08:05 +0200 | <dminuoso> | [exa]: it doesnt do all the operations I want it to do |
| 2022-05-12 09:08:12 +0200 | cawfee | (~root@2406:3003:2077:2758::babe) (Ping timeout: 260 seconds) |
| 2022-05-12 09:08:34 +0200 | <[exa]> | dminuoso: btw what about using it as a library? https://hackage.haskell.org/package/imagemagick |
| 2022-05-12 09:08:56 +0200 | <tomsmeding> | dminuoso: given your paranoia about correct reading order I was almost assuming this was some mission-critical client process that must be treated with care at all times lol |
| 2022-05-12 09:08:59 +0200 | <dminuoso> | [exa]: Not been maintained for 7 years, will only build against old versions of it |
| 2022-05-12 09:09:17 +0200 | <dminuoso> | tomsmeding: No, its actually just me writing elgato streamdeck drivers and tools! |
| 2022-05-12 09:09:23 +0200 | cawfee | (~root@2406:3003:2077:2758::babe) |
| 2022-05-12 09:09:26 +0200 | <dminuoso> | It's for a jukebox for my kid. :> |
| 2022-05-12 09:09:31 +0200 | <[exa]> | dminuoso: ah so ,_, |
| 2022-05-12 09:09:35 +0200 | <tomsmeding> | I guess that _is_ mission critical |
| 2022-05-12 09:10:00 +0200 | <dminuoso> | tomsmeding: I strike to not take shortcuts even for hobby projects. I see them as practice for writing correct and stable software. |
| 2022-05-12 09:10:12 +0200 | <dminuoso> | *strive even |
| 2022-05-12 09:10:52 +0200 | <dminuoso> | Besides, Im considering upstreaming ByteString readCreateProcess versions. There were proposals, but they were all stopped because process-extras existed. But that hasnt been maintained for a long time, so... |
| 2022-05-12 09:11:00 +0200 | <tomsmeding> | as long as it's fun, sounds like a worthy goal; I try to do the same for things that are not completely one-off |
| 2022-05-12 09:11:26 +0200 | <[exa]> | dminuoso: honestly just go for tmpfiles, images require some seeking to be loaded correctly and I assume that imagemagick is just tmpfiling the buffer anyway |
| 2022-05-12 09:11:39 +0200 | <dminuoso> | [exa]: No no! Performance! |
| 2022-05-12 09:11:50 +0200 | christiansen | (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) |
| 2022-05-12 09:12:04 +0200 | <[exa]> | dminuoso: mmap() >>> malloc() |
| 2022-05-12 09:12:07 +0200 | <dminuoso> | heh |
| 2022-05-12 09:12:21 +0200 | <[exa]> | anyway I'll need this too |
| 2022-05-12 09:12:29 +0200 | <[exa]> | let's try some c2hs |
| 2022-05-12 09:12:44 +0200 | <dminuoso> | [exa]: Im not willing to maintain this for years to come. |
| 2022-05-12 09:13:02 +0200 | <dminuoso> | Throwing binary bindings on hackage you know will be outdated a year from now is irresponsible. |
| 2022-05-12 09:13:25 +0200 | <[exa]> | I'd then assume throwing any binary bindings there is irresponsible? :D |
| 2022-05-12 09:13:59 +0200 | <dminuoso> | Well some are maintained, or work with very stable APIs that dont need much changing |
| 2022-05-12 09:14:21 +0200 | <dminuoso> | Besides, imagemagick is a very dangerous proposition to use for production software |
| 2022-05-12 09:14:35 +0200 | <dminuoso> | The kind of attack vectors this enables is crazy |
| 2022-05-12 09:15:13 +0200 | <[exa]> | yap |
| 2022-05-12 09:15:26 +0200 | <[exa]> | what's the extra transform you need that juicypixels don't do? |
| 2022-05-12 09:15:57 +0200 | <[exa]> | s/juicypixels/friday/ |
| 2022-05-12 09:16:43 +0200 | <dminuoso> | extending canvas with transparent background |
| 2022-05-12 09:16:55 +0200 | <dminuoso> | I want to generate key icons for the pressed state that become smaller |
| 2022-05-12 09:17:13 +0200 | mikoto-chan | (~mikoto-ch@84.199.144.234) (Ping timeout: 246 seconds) |
| 2022-05-12 09:17:22 +0200 | <dminuoso> | So I would resize (which I could do with JuicyPixels-extras), and extend canvas - I havent found a way to do the latter. |
| 2022-05-12 09:17:51 +0200 | <dminuoso> | Also the bitmap portions dont let me pick arbitrary headers |
| 2022-05-12 09:17:52 +0200 | <[exa]> | you make a bigger image and blit the original in the middle? |
| 2022-05-12 09:17:55 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Read error: Connection reset by peer) |
| 2022-05-12 09:18:01 +0200 | <dminuoso> | The streamdecks require a particular BMP header format that juicy pixels can only parse, but not generate |
| 2022-05-12 09:18:18 +0200 | <dminuoso> | (well the older models) |
| 2022-05-12 09:18:51 +0200 | <dminuoso> | I could probably work around *that* one by poking around in the header myself, but the extend canvas onto transparent background I cant |
| 2022-05-12 09:19:14 +0200 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 2022-05-12 09:21:14 +0200 | <tomsmeding> | does BMP even support transparency |
| 2022-05-12 09:21:18 +0200 | <[exa]> | re borders, what about `generateImage (\x y -> if inbounds x y then takefromthepicture else transparent) ? |
| 2022-05-12 09:21:23 +0200 | <[exa]> | tomsmeding: yeah they support RGBA |
| 2022-05-12 09:21:36 +0200 | <tomsmeding> | TIL |
| 2022-05-12 09:21:39 +0200 | <[exa]> | with similar level of standardization as other formats there :D |
| 2022-05-12 09:21:44 +0200 | <tomsmeding> | lol |
| 2022-05-12 09:21:59 +0200 | <[exa]> | s/formats/bmp formats/ |
| 2022-05-12 09:22:05 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) |
| 2022-05-12 09:22:26 +0200 | <[exa]> | I still get triggered when remembering the bmp palettes |
| 2022-05-12 09:22:37 +0200 | <dminuoso> | [exa]: Mmmm, maybe I really should look at JuicyPixels. |
| 2022-05-12 09:23:30 +0200 | Midjak | (~Midjak@82.66.147.146) (Ping timeout: 260 seconds) |
| 2022-05-12 09:23:38 +0200 | <[exa]> | dminuoso: honestly you're better off having a patched version of juicypixels that can write the rgba bmp than trying to invoke magick in weird ways |
| 2022-05-12 09:23:44 +0200 | <[exa]> | ^ opinionated truth |
| 2022-05-12 09:24:03 +0200 | <tomsmeding> | what is an opinionated truth |
| 2022-05-12 09:24:14 +0200 | <dminuoso> | All truth is opinionated. |
| 2022-05-12 09:24:26 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-05-12 09:24:29 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-12 09:24:44 +0200 | <[exa]> | tomsmeding: that's specified in IRC RFC no? :D |
| 2022-05-12 09:25:32 +0200 | <tomsmeding> | [exa]: /me confused |
| 2022-05-12 09:26:36 +0200 | <[exa]> | btw RGBA BMP is even exampled by wiki it seems https://en.wikipedia.org/wiki/BMP_file_format#Example_2 |
| 2022-05-12 09:27:01 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2022-05-12 09:27:03 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-05-12 09:27:07 +0200 | <dminuoso> | [exa]: I mean the performance doing this in JuicyPixels will likely be much worse. :( |
| 2022-05-12 09:27:41 +0200 | <dminuoso> | With imagemagick I get opencl with SIMD and all that sorcery |
| 2022-05-12 09:27:48 +0200 | <[exa]> | juicypixels-repa? |
| 2022-05-12 09:27:49 +0200 | <dminuoso> | But honestly, performance is not a constraint. |
| 2022-05-12 09:27:58 +0200 | <tomsmeding> | "I want to generate key icons" |
| 2022-05-12 09:28:04 +0200 | <[exa]> | (or maybe the package name is the other way around) |
| 2022-05-12 09:28:05 +0200 | <dminuoso> | :> |
| 2022-05-12 09:28:16 +0200 | <dminuoso> | tomsmeding: Not just a few, 32 of them! |
| 2022-05-12 09:28:32 +0200 | <tomsmeding> | I bet IM doesn't parallelise across images |
| 2022-05-12 09:28:45 +0200 | <dminuoso> | No, but you can simply invoke multiple IM processes on parallel! |
| 2022-05-12 09:28:57 +0200 | <tomsmeding> | how large are these images |
| 2022-05-12 09:29:11 +0200 | <dminuoso> | I gotta scale them down from 150x150ish to 96x96 or 72x72! |
| 2022-05-12 09:29:15 +0200 | <tomsmeding> | [exa]: ah |
| 2022-05-12 09:29:30 +0200 | <tomsmeding> | dminuoso: invoking the process will be more expensive than resizing the f*n image lol |
| 2022-05-12 09:29:44 +0200 | <dminuoso> | heh |
| 2022-05-12 09:29:59 +0200 | <tomsmeding> | [exa]: that 'little-endian "Win "' though |
| 2022-05-12 09:30:06 +0200 | <dminuoso> | I hope you do realize Im being a bit humorous about performance |
| 2022-05-12 09:30:11 +0200 | [exa] | remembers the negligible negligibility of opencl initialization time |
| 2022-05-12 09:30:14 +0200 | <tomsmeding> | :) |
| 2022-05-12 09:30:28 +0200 | <tomsmeding> | I do |
| 2022-05-12 09:30:38 +0200 | <[exa]> | tomsmeding: yeah all the easter eggs from M$ are cursed af |
| 2022-05-12 09:31:31 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 09:31:55 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Quit: No Ping reply in 180 seconds.) |
| 2022-05-12 09:32:11 +0200 | <dminuoso> | [exa]: mmm now if JuicyPixels-repa could give me an unboxed vector of pixel data. |
| 2022-05-12 09:32:31 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-05-12 09:32:32 +0200 | <dminuoso> | If Im using generateImage, I want maximum localicy of reference to scan the source image |
| 2022-05-12 09:32:49 +0200 | <[exa]> | dminuoso: repa is good |
| 2022-05-12 09:33:11 +0200 | <dminuoso> | Ah but wait, is Array D DIM3 Word8 |
| 2022-05-12 09:33:15 +0200 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 2022-05-12 09:33:18 +0200 | <dminuoso> | Whatever that means |
| 2022-05-12 09:33:22 +0200 | <[exa]> | that's okay |
| 2022-05-12 09:33:34 +0200 | <tomsmeding> | delayed array of dimension 3 containing Word8 values |
| 2022-05-12 09:33:36 +0200 | <[exa]> | delayed 3D array of bytes, precisely what you want |
| 2022-05-12 09:33:44 +0200 | tomsmeding | high-5's [exa] |
| 2022-05-12 09:33:52 +0200 | <dminuoso> | delayed-what-now? |
| 2022-05-12 09:33:55 +0200 | <[exa]> | then you undelay it and it computes itself very efficiently |
| 2022-05-12 09:34:06 +0200 | <tomsmeding> | delayed being it's ((Int,Int,Int) -> Word8) |
| 2022-05-12 09:34:19 +0200 | <tomsmeding> | manifest would be (Vector Word8) |
| 2022-05-12 09:34:20 +0200 | <[exa]> | it accumulates the highlevel operations you're doing with it so that it doesn't rewrite the memory everytime you do a pixel change |
| 2022-05-12 09:34:25 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-12 09:35:18 +0200 | <dminuoso> | Does that mean operations on it occur in a special monad? |
| 2022-05-12 09:35:29 +0200 | <[exa]> | no |
| 2022-05-12 09:35:52 +0200 | <dminuoso> | Okay repa is completely news to me :) |
| 2022-05-12 09:36:37 +0200 | <[exa]> | I'd say it's a bit more efficient than having mutable vectors, unless you attempt to replicate a yuge thunk chain on that, as with foldl |
| 2022-05-12 09:37:01 +0200 | <dminuoso> | Though Im wondering, if I have to first convert a Image/DynamicImage to a rep based Img, I still pay for the non-locality of reference |
| 2022-05-12 09:37:05 +0200 | <dminuoso> | I dont think much is won |
| 2022-05-12 09:37:16 +0200 | <[exa]> | and if you compile with LLVM you should actually get a bit of SIMD |
| 2022-05-12 09:37:32 +0200 | <dminuoso> | I might get some cache benefit depending if the Image allocations on the heap are packed together though |
| 2022-05-12 09:38:02 +0200 | <[exa]> | (...if you find a CPU with SIMD vectors smaller than the 32 key icons) |
| 2022-05-12 09:38:46 +0200 | <[exa]> | nah the delayed arrays are basically a few thunks pointing to unboxed arrays, and unboxed arrays are basically Vector, 1 single chunk of memory |
| 2022-05-12 09:39:46 +0200 | <tomsmeding> | dminuoso: https://hackage.haskell.org/package/repa-3.4.1.5/docs/src/Data.Array.Repa.Repr.Delayed.html#line-25 'Array D sh a' is isomorphic to '(sh, sh -> a)' |
| 2022-05-12 09:39:51 +0200 | <[exa]> | *unboxed Vector |
| 2022-05-12 09:40:24 +0200 | <dminuoso> | Well, I see that repa has this fairly cool shape polymorphic indexing. |
| 2022-05-12 09:40:27 +0200 | dextaa490 | (~dextaa@user/dextaa) (Remote host closed the connection) |
| 2022-05-12 09:40:54 +0200 | <dminuoso> | Brilliant, so I dont even notice Im working with an unboxed, row-major array of rgba data |
| 2022-05-12 09:41:25 +0200 | <[exa]> | yap repa is good |
| 2022-05-12 09:42:01 +0200 | odnes | (~odnes@5-203-212-41.pat.nym.cosmote.net) (Quit: Leaving) |
| 2022-05-12 09:42:35 +0200 | <dminuoso> | Okay so it is determined. The streamdeck missions critically depends on having unboxed delayed repa array to implement "scaling down really small icons to even-slightly-smaller icons". |
| 2022-05-12 09:42:56 +0200 | <dminuoso> | Thanks [exa], came here for unix process advice and went out with repa. |
| 2022-05-12 09:43:09 +0200 | <[exa]> | \o/ |
| 2022-05-12 09:45:49 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 09:46:21 +0200 | xaotuk | (~sasha@2a06:5b00:15fe:9b00::2) |
| 2022-05-12 09:47:44 +0200 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-05-12 09:50:45 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-05-12 09:50:46 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2022-05-12 09:52:35 +0200 | vpan | (~0@212.117.1.172) |
| 2022-05-12 09:52:56 +0200 | bahamas | (~lucian@84.232.141.55) |
| 2022-05-12 09:56:43 +0200 | slack1256 | (~slack1256@186.11.58.142) (Ping timeout: 260 seconds) |
| 2022-05-12 09:59:29 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2022-05-12 10:01:21 +0200 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-05-12 10:03:47 +0200 | mattil | (~mattil@helsinki.portalify.com) |
| 2022-05-12 10:06:15 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-05-12 10:13:41 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 2022-05-12 10:13:42 +0200 | christiansen | (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) (Quit: christiansen) |
| 2022-05-12 10:13:54 +0200 | christiansen | (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) |
| 2022-05-12 10:15:26 +0200 | comerijn | merijn |
| 2022-05-12 10:15:59 +0200 | christiansen | (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) (Read error: Connection reset by peer) |
| 2022-05-12 10:16:15 +0200 | christiansen | (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) |
| 2022-05-12 10:16:39 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 10:20:12 +0200 | mattil | (~mattil@helsinki.portalify.com) (Read error: Connection reset by peer) |
| 2022-05-12 10:20:29 +0200 | xstill- | (xstill@fimu/xstill) (Quit: Ping timeout (120 seconds)) |
| 2022-05-12 10:21:31 +0200 | xstill- | (xstill@fimu/xstill) |
| 2022-05-12 10:26:54 +0200 | ccntrq | (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) |
| 2022-05-12 10:30:19 +0200 | bahamas | (~lucian@84.232.141.55) (Ping timeout: 260 seconds) |
| 2022-05-12 10:37:36 +0200 | <tomsmeding> | yay |
| 2022-05-12 10:38:03 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-05-12 10:39:29 +0200 | phma | (~phma@2001:5b0:211b:9668:1b71:5de:d62c:3d45) (Read error: Connection reset by peer) |
| 2022-05-12 10:40:11 +0200 | phma | (~phma@host-67-44-208-35.hnremote.net) |
| 2022-05-12 10:41:51 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-05-12 10:50:13 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-12 10:50:27 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 10:51:33 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 10:55:59 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 2022-05-12 10:57:04 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2022-05-12 10:57:08 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-12 11:03:10 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 11:06:46 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 11:07:10 +0200 | king_gs | (~Thunderbi@187.201.105.54) |
| 2022-05-12 11:08:20 +0200 | dhil | (~dhil@cpc103052-sgyl39-2-0-cust260.18-2.cable.virginm.net) |
| 2022-05-12 11:10:58 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds) |
| 2022-05-12 11:11:07 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-05-12 11:11:45 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 2022-05-12 11:11:49 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-05-12 11:13:01 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-05-12 11:13:22 +0200 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-05-12 11:13:55 +0200 | odnes | (~odnes@2a02:587:440e:0:e8c:b484:c50b:a76) |
| 2022-05-12 11:14:16 +0200 | tubogram4 | (~tubogram@user/tubogram) (Quit: See ya later!) |
| 2022-05-12 11:14:30 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-05-12 11:15:47 +0200 | king_gs | (~Thunderbi@187.201.105.54) (Quit: king_gs) |
| 2022-05-12 11:17:39 +0200 | Benzi-Junior | (~BenziJuni@88-149-64-179.du.xdsl.is) |
| 2022-05-12 11:22:17 +0200 | tubogram4 | (~tubogram@user/tubogram) |
| 2022-05-12 11:30:00 +0200 | ccntrq | (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) (Quit: ccntrq) |
| 2022-05-12 11:34:54 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 11:35:33 +0200 | ccntrq | (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) |
| 2022-05-12 11:38:26 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) (Quit: WeeChat 2.8) |
| 2022-05-12 11:38:40 +0200 | ccntrq | (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) (Client Quit) |
| 2022-05-12 11:45:38 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Read error: Connection reset by peer) |
| 2022-05-12 11:45:52 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 11:47:27 +0200 | mmhat | (~mmh@2001:4090:a243:801d:ee08:6bff:fe09:5315) |
| 2022-05-12 11:53:03 +0200 | MoC | (~moc@user/moc) |
| 2022-05-12 11:54:11 +0200 | ubert | (~Thunderbi@p548c8d44.dip0.t-ipconnect.de) (Quit: ubert) |
| 2022-05-12 11:55:47 +0200 | ubert | (~Thunderbi@p200300ecdf15880b196df7e3ef276b09.dip0.t-ipconnect.de) |
| 2022-05-12 11:56:52 +0200 | michalz | (~michalz@185.246.204.126) (Ping timeout: 248 seconds) |
| 2022-05-12 12:00:26 +0200 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-05-12 12:00:52 +0200 | michalz | (~michalz@185.246.204.125) |
| 2022-05-12 12:04:34 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2022-05-12 12:09:16 +0200 | acidjnk_new | (~acidjnk@p200300d0c7068b99195ba74fc017953f.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-12 12:09:41 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-05-12 12:14:21 +0200 | kjak | (~kjak@pool-108-45-56-21.washdc.fios.verizon.net) |
| 2022-05-12 12:14:58 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 2022-05-12 12:16:23 +0200 | nishant | (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) |
| 2022-05-12 12:17:17 +0200 | nishant | (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) (Leaving) |
| 2022-05-12 12:17:22 +0200 | nishant | (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) |
| 2022-05-12 12:17:30 +0200 | nishant | (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) (Leaving) |
| 2022-05-12 12:18:08 +0200 | xaotuk | (~sasha@2a06:5b00:15fe:9b00::2) (Ping timeout: 260 seconds) |
| 2022-05-12 12:19:55 +0200 | xaotuk | (~sasha@net108-32-245-109.mbb.telenor.rs) |
| 2022-05-12 12:24:22 +0200 | kaph | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) |
| 2022-05-12 12:26:39 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) |
| 2022-05-12 12:28:33 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 12:30:35 +0200 | haskl | (~haskl@user/haskl) (Read error: Connection reset by peer) |
| 2022-05-12 12:33:03 +0200 | haskl | (~haskl@user/haskl) |
| 2022-05-12 12:39:10 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-05-12 12:44:12 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds) |
| 2022-05-12 12:44:19 +0200 | w1gz | (~weechat@2a03:b0c0:1:d0::1123:1) |
| 2022-05-12 12:46:18 +0200 | MoC | (~moc@user/moc) (Quit: Konversation terminated!) |
| 2022-05-12 12:46:18 +0200 | dsrt^ | (~dsrt@128-092-160-234.biz.spectrum.com) (Remote host closed the connection) |
| 2022-05-12 12:47:56 +0200 | odnes | (~odnes@2a02:587:440e:0:e8c:b484:c50b:a76) (Remote host closed the connection) |
| 2022-05-12 12:52:53 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-05-12 12:53:41 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-05-12 12:54:10 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2022-05-12 12:57:30 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 276 seconds) |
| 2022-05-12 13:00:43 +0200 | acidjnk_new | (~acidjnk@p200300d0c7068b9978922ec24d0737b7.dip0.t-ipconnect.de) |
| 2022-05-12 13:02:03 +0200 | xff0x | (~xff0x@125x102x200x106.ap125.ftth.ucom.ne.jp) (Ping timeout: 276 seconds) |
| 2022-05-12 13:07:39 +0200 | MajorBiscuit | (~MajorBisc@c-001-013-046.client.tudelft.eduvpn.nl) |
| 2022-05-12 13:08:20 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-12 13:08:32 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) |
| 2022-05-12 13:08:56 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 13:09:27 +0200 | w1gz | (~weechat@2a03:b0c0:1:d0::1123:1) (Quit: w1gz) |
| 2022-05-12 13:09:42 +0200 | w1gz | (~weechat@2a03:b0c0:1:d0::1123:1) |
| 2022-05-12 13:10:48 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-12 13:13:31 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-05-12 13:19:12 +0200 | tired | (~tired@user/tired) (Read error: Connection reset by peer) |
| 2022-05-12 13:19:35 +0200 | tired | (~tired@user/tired) |
| 2022-05-12 13:22:32 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (Ping timeout: 250 seconds) |
| 2022-05-12 13:22:43 +0200 | ddb | (~ddb@2607:5300:203:9993::196) (Ping timeout: 260 seconds) |
| 2022-05-12 13:22:50 +0200 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 2022-05-12 13:23:39 +0200 | ddb | (~ddb@2607:5300:203:9993::196) |
| 2022-05-12 13:24:45 +0200 | bahamas | (~lucian@86.120.77.115) |
| 2022-05-12 13:27:01 +0200 | mmhat | (~mmh@2001:4090:a243:801d:ee08:6bff:fe09:5315) (Quit: WeeChat 3.5) |
| 2022-05-12 13:30:32 +0200 | xaotuk | (~sasha@net108-32-245-109.mbb.telenor.rs) (Ping timeout: 252 seconds) |
| 2022-05-12 13:30:41 +0200 | odnes | (~odnes@2a02:587:e901:3110::ec9) |
| 2022-05-12 13:33:10 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 240 seconds) |
| 2022-05-12 13:33:15 +0200 | MajorBiscuit | (~MajorBisc@c-001-013-046.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.4) |
| 2022-05-12 13:34:36 +0200 | mattil | (~mattil@helsinki.portalify.com) |
| 2022-05-12 13:36:55 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Ping timeout: 246 seconds) |
| 2022-05-12 13:44:19 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) |
| 2022-05-12 13:47:18 +0200 | xff0x | (~xff0x@b133147.ppp.asahi-net.or.jp) |
| 2022-05-12 13:50:00 +0200 | bliminse | (~bliminse@host86-164-128-238.range86-164.btcentralplus.com) (Quit: leaving) |
| 2022-05-12 13:53:38 +0200 | bliminse | (~bliminse@host86-164-128-238.range86-164.btcentralplus.com) |
| 2022-05-12 13:57:39 +0200 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) |
| 2022-05-12 14:09:39 +0200 | odnes | (~odnes@2a02:587:e901:3110::ec9) (Ping timeout: 260 seconds) |
| 2022-05-12 14:09:57 +0200 | odnes | (~odnes@2a02:587:e901:3110::ec9) |
| 2022-05-12 14:15:15 +0200 | odnes | (~odnes@2a02:587:e901:3110::ec9) (Ping timeout: 260 seconds) |
| 2022-05-12 14:15:29 +0200 | Alex_test_ | (~al_test@178.34.163.35) |
| 2022-05-12 14:17:27 +0200 | Alex_test | (~al_test@178.34.163.35) (Ping timeout: 276 seconds) |
| 2022-05-12 14:30:33 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 14:30:46 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-05-12 14:34:39 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 14:35:33 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) |
| 2022-05-12 14:35:42 +0200 | <apache2> | I'm writing a function that operates on/in a State monad and I take an argument which is a Map. I want to fold over the map (k,v) elements with each element updating my State |
| 2022-05-12 14:36:34 +0200 | <apache2> | I currently have a foldM which mostly does what I want except it folds over the (v) in the Map rather than (key,v) |
| 2022-05-12 14:36:58 +0200 | gurkenglas | (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Remote host closed the connection) |
| 2022-05-12 14:37:14 +0200 | <apache2> | Data.Map seems to have a `fold` (over the values) and `foldWithKeys` over both key,value. Is there a way to get foldM to use the latter? |
| 2022-05-12 14:37:46 +0200 | <geekosaur> | isn't foldM just some variant of sequence . fold? |
| 2022-05-12 14:37:52 +0200 | <geekosaur> | @src foldM |
| 2022-05-12 14:37:52 +0200 | <lambdabot> | foldM _ a [] = return a |
| 2022-05-12 14:37:52 +0200 | <lambdabot> | foldM f a (x:xs) = f a x >>= \fax -> foldM f fax xs |
| 2022-05-12 14:37:59 +0200 | <geekosaur> | mm, maybe not |
| 2022-05-12 14:38:08 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 14:40:04 +0200 | <apache2> | I can use Map.foldWithKeys and manually make sure to pass in the State and 'return' from in there, I was just wondering if there was a more idiomatic way to achieve this |
| 2022-05-12 14:42:34 +0200 | <tomsmeding> | apache2: foldM over Map.assocs? |
| 2022-05-12 14:43:10 +0200 | <apache2> | tomsmeding: that works, thanks |
| 2022-05-12 14:44:04 +0200 | kaph | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) (Read error: Connection reset by peer) |
| 2022-05-12 14:44:07 +0200 | kaph_ | (~kaph@net-2-42-128-205.cust.vodafonedsl.it) |
| 2022-05-12 14:45:27 +0200 | odnes | (~odnes@2a02:587:e901:3110::273) |
| 2022-05-12 14:48:30 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) (Ping timeout: 265 seconds) |
| 2022-05-12 14:48:40 +0200 | bahamas | (~lucian@86.120.77.115) (Ping timeout: 246 seconds) |
| 2022-05-12 14:48:56 +0200 | superbil | (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 2022-05-12 14:49:50 +0200 | bahamas | (~lucian@86.120.77.115) |
| 2022-05-12 14:52:45 +0200 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2022-05-12 14:59:03 +0200 | mattil | (~mattil@helsinki.portalify.com) (Remote host closed the connection) |
| 2022-05-12 15:00:14 +0200 | ehllie | (~ehllie@217-67-208-66.itsa.net.pl) |
| 2022-05-12 15:09:51 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-12 15:10:55 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 15:12:48 +0200 | [Leary] | (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) (Ping timeout: 252 seconds) |
| 2022-05-12 15:13:07 +0200 | bahamas | (~lucian@86.120.77.115) (Quit: Lost terminal) |
| 2022-05-12 15:14:25 +0200 | xaotuk | (~sasha@net108-32-245-109.mbb.telenor.rs) |
| 2022-05-12 15:14:50 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-05-12 15:15:15 +0200 | ub | (~Thunderbi@p200300ecdf15880b09d618bc8a498343.dip0.t-ipconnect.de) |
| 2022-05-12 15:17:22 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-05-12 15:19:26 +0200 | acidjnk_new | (~acidjnk@p200300d0c7068b9978922ec24d0737b7.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-05-12 15:26:02 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 15:26:57 +0200 | slack1256 | (~slack1256@186.11.61.206) |
| 2022-05-12 15:30:37 +0200 | slac79575 | (~slack1256@191.125.227.220) |
| 2022-05-12 15:33:30 +0200 | slack1256 | (~slack1256@186.11.61.206) (Ping timeout: 276 seconds) |
| 2022-05-12 15:35:42 +0200 | Alex_test_ | Alex_test |
| 2022-05-12 15:40:27 +0200 | __monty__ | (~toonn@user/toonn) |
| 2022-05-12 15:41:08 +0200 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-05-12 15:52:38 +0200 | Henson | (~kvirc@107-179-133-201.cpe.teksavvy.com) |
| 2022-05-12 15:53:14 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-05-12 15:54:30 +0200 | <Henson> | I'm trying to do some CPU profiling on a program. I've run "stack build --profile" and run the executable with "+RTS -p -RTS" to generate a .prof output file. In one run of the program it uses 250% of the CPU power for 2 minutes, then in another uses 250% for about 15 seconds, then 60% for the rest of the time up to 2 minutes. I'm trying to figure out what's different between the two runs.... |
| 2022-05-12 15:54:50 +0200 | ehllie | (~ehllie@217-67-208-66.itsa.net.pl) (Quit: Connection closed) |
| 2022-05-12 15:55:24 +0200 | <Henson> | because the CPU usage is VERY different. However from the profile run, there seems to be pretty much no difference. The main summary at the top indicates pretty much no difference between the various usage centres. I would expect a glaring difference based on the very different CPU loads in the two runs. Does anybody have any suggestions? |
| 2022-05-12 15:56:41 +0200 | <merijn> | Henson: Some intuition based wild-ass guessing: Is your code using the threaded runtime? How many capabilities are you running? And have you ran with "+RTS -sstderr" yet? |
| 2022-05-12 15:56:51 +0200 | <Henson> | it's also very difficult to compare different runs. Everything is output as text, the first three columns contain duplicate values, and the unique SRC column isn't consistent across multiple runs, making inter-run comparison very kludgy and difficult. |
| 2022-05-12 15:57:07 +0200 | <Henson> | merijn: yes, it's threaded, with 4 capabilities |
| 2022-05-12 15:57:18 +0200 | <Henson> | merijn: I haven't run with sstderr yet |
| 2022-05-12 15:57:32 +0200 | <merijn> | Henson: Also: https://mpickering.github.io/posts/2019-11-07-hs-speedscope.html :) |
| 2022-05-12 15:57:38 +0200 | <merijn> | (for making profiles more readable) |
| 2022-05-12 15:57:42 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 15:59:24 +0200 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2022-05-12 16:01:56 +0200 | <Henson> | merijn: I see "-sstderr" produces the same thing as "-s". I have run with "-s" before, but didn't run it as a comparison between the two very different runs. I'll give that a try and see if it's helpful. I'll also look into the speedscope tool. |
| 2022-05-12 16:02:46 +0200 | <Henson> | merijn: will running threaded with multiple capabilities cause any problems or difficulties in time profiling? |
| 2022-05-12 16:05:23 +0200 | <merijn> | Henson: But what does -s report? What's your productivity |
| 2022-05-12 16:05:54 +0200 | <merijn> | Henson: Not so much difficulties profiling, but it can get you some nasty regressions in GC performance |
| 2022-05-12 16:07:39 +0200 | <Henson> | merijn: good question about the productivity, I'm not sure. I'll have to run it again with "-s" to find out the difference between the two. |
| 2022-05-12 16:08:15 +0200 | <merijn> | Henson: What was productivity on the last run? |
| 2022-05-12 16:08:34 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 16:09:19 +0200 | <Henson> | merijn: I'm not sure, I wasn't looking for that statistic, so I didn't even read the number when it was on the screen. I'll rerun the program and get back to you on it. |
| 2022-05-12 16:10:05 +0200 | odnes | (~odnes@2a02:587:e901:3110::273) (Quit: Leaving) |
| 2022-05-12 16:10:45 +0200 | <merijn> | Henson: When you have performance issues, productivity is one of the first numbers you should look at :) |
| 2022-05-12 16:11:12 +0200 | <merijn> | To see if it's in a sane ballpark or not |
| 2022-05-12 16:13:24 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 16:16:09 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.5) |
| 2022-05-12 16:20:43 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-05-12 16:24:45 +0200 | [Leary] | (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) |
| 2022-05-12 16:27:01 +0200 | frost | (~frost@user/frost) (Quit: Client closed) |
| 2022-05-12 16:29:29 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-05-12 16:30:08 +0200 | xaotuk | (~sasha@net108-32-245-109.mbb.telenor.rs) (Ping timeout: 260 seconds) |
| 2022-05-12 16:31:01 +0200 | vicfred | (~vicfred@user/vicfred) (Quit: Leaving) |
| 2022-05-12 16:32:31 +0200 | <Henson> | merijn: well, the productivity in both cases is pretty high. 95.4% for the case with the high CPU load, and 89.2% for the case with the low CPU load. |
| 2022-05-12 16:32:45 +0200 | <Henson> | merijn: I'll try using the speedscope tool to see if that sheds any light on things |
| 2022-05-12 16:32:50 +0200 | Pickchea | (~private@user/pickchea) (Ping timeout: 240 seconds) |
| 2022-05-12 16:33:54 +0200 | <Henson> | merijn: GC seconds for both cases are pretty much the same, but the MUT time is quite different. The high CPU case is higher, and the low CPU case is lower. I don't think that's too surprising. The question is why is the low CPU case so much lower. |
| 2022-05-12 16:34:54 +0200 | <Henson> | merijn: I suspect it's because something is crashing when I overwhelm the system, but the thing that is crashing is not the thing that SHOULD be using up the most CPU power, as that continues to function. But the thing that should be using up no CPU power all in the fully loaded case is what I suspect is crashing. |
| 2022-05-12 16:35:11 +0200 | <tomsmeding> | Henson: you say you're running with 4 capabilities; are you also running 4 jobs, and do those jobs allocate memory as they go? |
| 2022-05-12 16:35:17 +0200 | vysn | (~vysn@user/vysn) |
| 2022-05-12 16:36:06 +0200 | <tomsmeding> | try also running with one capability more than you're actually using, the scheduler needs a thread to do its stuff once in a while and if you busy-loop all the threads, it never gets a chance |
| 2022-05-12 16:36:37 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) |
| 2022-05-12 16:36:51 +0200 | xaotuk | (~sasha@net108-32-245-109.mbb.telenor.rs) |
| 2022-05-12 16:36:59 +0200 | <Henson> | tomsmeding: the "-s" output reports that there are about 13 tasks (I'm assuming those are parallel tasks, right)? There is a LOT of memory allocation going on in both cases, as the program is consuming and processing 750 MB/s of data from two high-speed cameras. |
| 2022-05-12 16:37:25 +0200 | <tomsmeding> | right, that makes it less likely that it's this |
| 2022-05-12 16:37:54 +0200 | <tomsmeding> | I've had a similar situation before, where I ran with -N8 and started 8 computations with forkIO, and then 7 ran and the 8th only started when the others were finished |
| 2022-05-12 16:38:09 +0200 | <Henson> | I'll try running with more tasks just to see what happens |
| 2022-05-12 16:41:20 +0200 | Vajb | (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) (Read error: Connection reset by peer) |
| 2022-05-12 16:41:44 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-05-12 16:42:47 +0200 | <Henson> | tomsmeding: hmm, well that seems to be it! Running with -N4 (the number of CPUs) causes the high CPU to manifest. Running with -N5 or higher the CPU load is WAY lower (250% versus 60%) |
| 2022-05-12 16:43:08 +0200 | <tomsmeding> | Henson: so with -N5 you're always in the slow case? |
| 2022-05-12 16:43:28 +0200 | <Henson> | tomsmeding: with -N8 or -N16 is reports ridiculous numbers for the MUT and GC times |
| 2022-05-12 16:43:54 +0200 | <Henson> | tomsmeding: the low CPU case. The software still functions, it's just the CPU load is much lower. |
| 2022-05-12 16:44:12 +0200 | <tomsmeding> | setting -N much higher than the number of cores shouldn't be useful, but I've seen people recommending ncores+1 |
| 2022-05-12 16:44:30 +0200 | <davean> | Henson: I've not read up, but have you avoided parallel GC? |
| 2022-05-12 16:44:46 +0200 | <tomsmeding> | (i.e. +RTS -qg) |
| 2022-05-12 16:44:55 +0200 | <tomsmeding> | or +RTS --nonmoving-gc |
| 2022-05-12 16:45:26 +0200 | <Henson> | is there an issue with parallel GC? I read a year or so ago that parallel GC had issues in the past but that they had mostly been fixed |
| 2022-05-12 16:45:39 +0200 | slac79575 | slack1256 |
| 2022-05-12 16:46:02 +0200 | <tomsmeding> | it has different behaviour and somewhat different use cases where it works well, so it's usually worth trying both |
| 2022-05-12 16:46:04 +0200 | <davean> | Henson: Its not an "issue" its that when you have small garbage theres more cordination than progress - inherently. |
| 2022-05-12 16:47:23 +0200 | <Henson> | I wasn't saying that the GC numbers were ridiculous because they were believable, they were like negative 17 trillion seconds for a program that ran for 10 seconds |
| 2022-05-12 16:47:39 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-05-12 16:47:50 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-05-12 16:47:51 +0200 | <Henson> | GC time -5447168.964s ( 0.063s elapsed) |
| 2022-05-12 16:47:59 +0200 | <tomsmeding> | lol |
| 2022-05-12 16:48:11 +0200 | <tomsmeding> | I wonder whether that's an overflow |
| 2022-05-12 16:48:16 +0200 | <Henson> | it was balanced out by the MUT, though: MUT time 5447174.517s ( 3.255s elapsed) |
| 2022-05-12 16:48:18 +0200 | <Henson> | :-) |
| 2022-05-12 16:48:22 +0200 | <tomsmeding> | :') |
| 2022-05-12 16:48:26 +0200 | <davean> | Thats not sane. |
| 2022-05-12 16:48:34 +0200 | <Henson> | haha |
| 2022-05-12 16:48:35 +0200 | <tomsmeding> | merijn: ^ |
| 2022-05-12 16:48:50 +0200 | <davean> | I've never seen anything like that - I . . . that shouldn't be an overflow either. Do you have clock issues? |
| 2022-05-12 16:48:51 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-05-12 16:49:03 +0200 | <davean> | like that makes no sense |
| 2022-05-12 16:49:17 +0200 | <davean> | I mean it shouldn't be a clock issue either to be clear |
| 2022-05-12 16:49:19 +0200 | <tomsmeding> | that's more than 2 months worth of negative seconds |
| 2022-05-12 16:49:25 +0200 | xaotuk | (~sasha@net108-32-245-109.mbb.telenor.rs) (Ping timeout: 256 seconds) |
| 2022-05-12 16:49:50 +0200 | <tomsmeding> | I like how the report clarifies the amount of elapsed time, which _is_ sane |
| 2022-05-12 16:50:21 +0200 | <Henson> | with -N16 it's even worse: GC time 6018330949.191s ( 0.130s elapsed) MUT time 0.000s ( 9.963s elapsed) |
| 2022-05-12 16:50:38 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-12 16:50:42 +0200 | <Henson> | davean: I don't think I have system clock issues |
| 2022-05-12 16:50:53 +0200 | <tomsmeding> | Henson: ghc version? if this is reproducible that sounds like an RTS bug lol |
| 2022-05-12 16:51:14 +0200 | <Henson> | tomsmeding: 8.10.7 |
| 2022-05-12 16:51:36 +0200 | <davean> | Hum, well I certainly never saw that on that version but I don't remember much about 8.10 anymore its so old. |
| 2022-05-12 16:51:57 +0200 | <tomsmeding> | davean: most of haskell users are still on 8.10.7 |
| 2022-05-12 16:52:03 +0200 | <davean> | tomsmeding: They're weird then |
| 2022-05-12 16:52:14 +0200 | <tomsmeding> | each of the subsequent versions has _some_ issue on some platform |
| 2022-05-12 16:52:27 +0200 | <tomsmeding> | 8.10.7 is the latest that's universally okay |
| 2022-05-12 16:52:39 +0200 | geekosaur | wonders if the rec for ncores+1 is just cargo-culting the old make "use -jcores+1" thing, which shouldn't apply to ghc anyway |
| 2022-05-12 16:52:47 +0200 | <tomsmeding> | if not, argue with maerwald to move the 'recommended' tag to a later version |
| 2022-05-12 16:54:09 +0200 | <davean> | tomsmeding: I mean I'd say 8.10 has issues on systems too - its just they're not the issues I guess you care about. |
| 2022-05-12 16:55:01 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
| 2022-05-12 16:55:16 +0200 | <Henson> | disabling parallel garbage collection with the "-gq" option does make a small difference. 0.2 GC seconds instead of 2.0 GC seconds, and and 98% productivity instead of 91% |
| 2022-05-12 16:55:25 +0200 | <tomsmeding> | -qg I hope |
| 2022-05-12 16:55:38 +0200 | <davean> | Henson: yah, it should in your case |
| 2022-05-12 16:55:53 +0200 | <davean> | Henson: you mostly want parallel GC with large amounts of live data, with a deeply connected structure |
| 2022-05-12 16:56:30 +0200 | <Henson> | davean: ok, I'll add that to my cabal file |
| 2022-05-12 16:56:47 +0200 | christiansen | (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) (Ping timeout: 256 seconds) |
| 2022-05-12 16:57:02 +0200 | <davean> | his is also part of what makes basic lists bad - esp if they're super long |
| 2022-05-12 16:58:12 +0200 | <Henson> | does anybody know why using N+1 instead of N in the RTS options gets rid of the high CPU problem? I'm not using any forkIO in my program, these are all Haskell threads. But Haskell is interacting with C++ which is spawning a couple OS threads in the camera library, but nowhere else. |
| 2022-05-12 16:58:17 +0200 | <telser> | FWIW I know of projects in industry that are still on 8.6 |
| 2022-05-12 16:58:50 +0200 | <Henson> | would this also explain why the difference between the high and low CPU cases were not showing up in the time profiling? |
| 2022-05-12 16:59:26 +0200 | <Henson> | this being some thing in GHC outside of the actual program that is causing the high CPU usage due to not enough cores to run on |
| 2022-05-12 17:00:27 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 17:03:50 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-12 17:04:13 +0200 | <slack1256> | davean: That advice you give for "when you want parallel GC", how did you get it. Did you read it somewhere? It sparked my interest. |
| 2022-05-12 17:07:00 +0200 | <Henson> | ok, it turns out that the problem was the parallel garbage collector. Using "+RTS -N" causes the high CPU load problem, but "+RTS -N -qg" does not. |
| 2022-05-12 17:08:13 +0200 | <Henson> | running with parallel garbage collection and more threads than CPU cores also helps the problem |
| 2022-05-12 17:09:46 +0200 | <Henson> | thank you very much for your help, everyone, another mystery solved! |
| 2022-05-12 17:11:15 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-05-12 17:11:36 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-05-12 17:14:00 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 260 seconds) |
| 2022-05-12 17:16:02 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 252 seconds) |
| 2022-05-12 17:17:21 +0200 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-05-12 17:19:51 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) |
| 2022-05-12 17:20:21 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) (Quit: WeeChat 2.8) |
| 2022-05-12 17:21:24 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-05-12 17:25:11 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-05-12 17:25:18 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds) |
| 2022-05-12 17:29:47 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-05-12 17:30:23 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 17:31:41 +0200 | benin | (~benin@183.82.31.174) (Quit: The Lounge - https://thelounge.chat) |
| 2022-05-12 17:32:32 +0200 | cheater | (~Username@user/cheater) (Read error: Connection reset by peer) |
| 2022-05-12 17:32:54 +0200 | <davean> | slack1256: Its inherent to the desing of GC |
| 2022-05-12 17:33:05 +0200 | <davean> | slack1256: Implimenting a GC was part of college? |
| 2022-05-12 17:33:29 +0200 | cheater | (~Username@user/cheater) |
| 2022-05-12 17:33:41 +0200 | <davean> | slack1256: Think about exactly how a GC works. It follows references from a root set |
| 2022-05-12 17:34:06 +0200 | <davean> | GHC's GC is a workstealing implimentation mind you which means when there isn't enough work to go around you'll start bouncing cache like crazy |
| 2022-05-12 17:37:01 +0200 | xff0x | (~xff0x@b133147.ppp.asahi-net.or.jp) (Ping timeout: 246 seconds) |
| 2022-05-12 17:38:02 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 252 seconds) |
| 2022-05-12 17:39:59 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-05-12 17:40:54 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 17:41:34 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 2022-05-12 17:44:01 +0200 | nschoe | (~quassel@178.251.84.79) (Ping timeout: 246 seconds) |
| 2022-05-12 17:46:00 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-12 17:50:34 +0200 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-05-12 17:51:40 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-12 17:51:55 +0200 | dextaa490 | (~dextaa@user/dextaa) |
| 2022-05-12 17:54:58 +0200 | <sm> | top starred haskell github repos: https://github.com/search?o=desc&q=language%3AHaskell+stars%3A%3E=100&ref=searchresults&s=stars&ty… |
| 2022-05-12 17:55:19 +0200 | <Franciman> | nice ty sm |
| 2022-05-12 17:55:35 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) |
| 2022-05-12 17:55:57 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 17:56:06 +0200 | <sm> | my question: how does graphql-engine, with presumably fewer direct users, get so many ? |
| 2022-05-12 17:57:27 +0200 | <sm> | and related: this and more search tools can be found at https://haskell-links.org |
| 2022-05-12 17:58:01 +0200 | xff0x | (~xff0x@b133147.ppp.asahi-net.or.jp) |
| 2022-05-12 18:02:51 +0200 | <geekosaur> | something's wrong there, xmonad has 2.5k but doesn't seem to show up at all |
| 2022-05-12 18:03:03 +0200 | <geekosaur> | (but kmonad and xmobar do) |
| 2022-05-12 18:04:16 +0200 | EvanR_ | (~EvanR@user/evanr) (Quit: Leaving) |
| 2022-05-12 18:04:58 +0200 | <slack1256> | davean: Gotcha on the workstealing part. But to me "having large amounts of live data, with a /deeply connected structure/" would mean the parallel GC would have *more* problems with trashing the other cores' cache than with a /disconnected/ structure. |
| 2022-05-12 18:05:05 +0200 | EvanR | (~EvanR@user/evanr) |
| 2022-05-12 18:05:20 +0200 | <slack1256> | That is why I wanted a reference. Probably my intuitions are wrong and that was acquired knowledge >.> . |
| 2022-05-12 18:05:58 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-05-12 18:09:50 +0200 | <davean> | slack1256: its the opposite becase it needs to follow links - thats what the processing is doing - all of what it is doing really. |
| 2022-05-12 18:10:05 +0200 | <davean> | slack1256: If you have a linked list you can't theoretically use more than a single core on it. |
| 2022-05-12 18:10:15 +0200 | <davean> | Theres only one spine to follow |
| 2022-05-12 18:10:58 +0200 | <davean> | What GC does is *copy* (or mark, depending on type) live data |
| 2022-05-12 18:11:05 +0200 | <davean> | it SPECIFICLY does not touch dead data. |
| 2022-05-12 18:11:27 +0200 | <davean> | The resident size has NOTHING to do with available work |
| 2022-05-12 18:11:33 +0200 | <davean> | slack1256: have you never implimented a GC? |
| 2022-05-12 18:11:53 +0200 | <slack1256> | Yes, I got that we follow live data and resisident size does matter, only live data size. |
| 2022-05-12 18:12:14 +0200 | <slack1256> | Nope. I know the theory from afar, mostly mark-and-sweep. |
| 2022-05-12 18:12:20 +0200 | <slack1256> | And I have read some RTS code on it. |
| 2022-05-12 18:13:50 +0200 | <geekosaur> | mm, this is even weirder. xmonad-contrib (459 stars) *does* show up |
| 2022-05-12 18:13:55 +0200 | <davean> | Yes but *how* you follow live data |
| 2022-05-12 18:14:02 +0200 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-05-12 18:14:25 +0200 | <slack1256> | Root set as you say. We follow the links from there moving to the other half of the generation. |
| 2022-05-12 18:14:36 +0200 | <davean> | Right, we *follow the links* |
| 2022-05-12 18:14:46 +0200 | <davean> | for that we need *parallel* links to enable multiple workers |
| 2022-05-12 18:15:29 +0200 | <davean> | Following a link is predicated on having followed all preceding links |
| 2022-05-12 18:15:31 +0200 | <sm> | geekosaur: hmm, github's search seems unreliable, perhaps when there's many results. I limited this one to >100 stars to get it properly sorted, maybe limiting to >1000 helps ? |
| 2022-05-12 18:15:37 +0200 | <davean> | otherwise we don't know what we're following from is live. |
| 2022-05-12 18:17:30 +0200 | <slack1256> | So you are saying that nodes in the rootset are the only real "parallelizable nodes" that we can have? |
| 2022-05-12 18:18:06 +0200 | <davean> | No, they're the initial parallelism - you can always get more parallism out of having more connected data |
| 2022-05-12 18:18:31 +0200 | <davean> | If a worker runs dry, it can steal from the queue of other workers, to get new links to follow |
| 2022-05-12 18:18:39 +0200 | <davean> | but that predicates on having a branch factor in your data |
| 2022-05-12 18:19:32 +0200 | <sm> | geekosaur: >1000 didn't help, pretty sure I remember seeing it show up in the past. That *is* weird |
| 2022-05-12 18:19:56 +0200 | <geekosaur> | I limited it to 2000. xmonad didn't show up… but yesod did |
| 2022-05-12 18:20:03 +0200 | shiraeeshi | (~shiraeesh@77.94.25.209) |
| 2022-05-12 18:20:40 +0200 | Everything | (~Everythin@37.115.210.35) |
| 2022-05-12 18:21:04 +0200 | <slack1256> | There is a problem with the connected data that you get downstream (not from the root set) if you want to parallelize though. Aren't they "physically" closer in memory given the moving GC that we use? That could trigger cache invalidation if they are closely packed and they fit on the cache line. |
| 2022-05-12 18:21:30 +0200 | <sm> | https://github.com/search?q=xmonad%2Fxmonad&type=Repositories doesn't find it either |
| 2022-05-12 18:21:30 +0200 | <geekosaur> | so something's definitely screwy with github search |
| 2022-05-12 18:21:40 +0200 | <davean> | slack1256: no |
| 2022-05-12 18:21:52 +0200 | <slack1256> | That certainly is not problem for the nursery, given that not many moving (if any) are done, but Gen1 probably is. |
| 2022-05-12 18:22:01 +0200 | <davean> | slack1256: thats a missunderstanding of how HW works, also it doesn't matter |
| 2022-05-12 18:22:21 +0200 | <davean> | Its irrelivent to parallelism |
| 2022-05-12 18:22:27 +0200 | <davean> | and its not how cache behaves |
| 2022-05-12 18:22:35 +0200 | <sm> | any github employees here who could rescue xmonad ? |
| 2022-05-12 18:22:59 +0200 | <davean> | sm: rescue? |
| 2022-05-12 18:23:02 +0200 | <davean> | what happened? |
| 2022-05-12 18:23:32 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 18:23:32 +0200 | <sm> | we have just been chatting about it |
| 2022-05-12 18:23:48 +0200 | <sm> | not showing in gihub search |
| 2022-05-12 18:23:59 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-12 18:24:08 +0200 | <Bulby[m]> | it shows up for me |
| 2022-05-12 18:24:19 +0200 | <Bulby[m]> | https://github.com/xmonad/xmonad |
| 2022-05-12 18:24:26 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 18:24:27 +0200 | <geekosaur> | search, not directly going to it |
| 2022-05-12 18:24:34 +0200 | <geekosaur> | https://github.com/search?q=xmonad%2Fxmonad&type=Repositories |
| 2022-05-12 18:24:38 +0200 | <Bulby[m]> | i did search |
| 2022-05-12 18:24:42 +0200 | <geekosaur> | it's even pinned in our org |
| 2022-05-12 18:25:01 +0200 | <lechner> | sm: i only see -contrib in the search |
| 2022-05-12 18:25:04 +0200 | <Bulby[m]> | does irc support images? |
| 2022-05-12 18:25:05 +0200 | <geekosaur> | oh wait, I wonder if that search is valid |
| 2022-05-12 18:25:13 +0200 | <geekosaur> | Bulby[m], no |
| 2022-05-12 18:25:24 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-05-12 18:25:36 +0200 | <Bulby[m]> | ok, won't try then 🙂 |
| 2022-05-12 18:25:45 +0200 | Vajb | (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) |
| 2022-05-12 18:26:18 +0200 | <Bulby[m]> | wtf ur right |
| 2022-05-12 18:26:19 +0200 | <Bulby[m]> | no xmonad core |
| 2022-05-12 18:27:01 +0200 | <geekosaur> | yeh, nor with https://github.com/search?o=desc&q=xmonad&s=stars&type=Repositories (omitting the org) |
| 2022-05-12 18:27:24 +0200 | <Bulby[m]> | `xmonad user:xmonad` doesn't show core |
| 2022-05-12 18:27:25 +0200 | <geekosaur> | somebody's indexing is busted |
| 2022-05-12 18:27:31 +0200 | <lechner> | maybe 98.1% Haskell isn't pure enough? |
| 2022-05-12 18:28:13 +0200 | <EvanR> | haskell 200 proof |
| 2022-05-12 18:28:30 +0200 | <geekosaur> | these searches aren't even considering language |
| 2022-05-12 18:28:48 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 18:29:16 +0200 | <lechner> | yeah, it does not show in regular search either, with "best match" |
| 2022-05-12 18:29:17 +0200 | romesrf | (~romes@185.5.8.134) |
| 2022-05-12 18:29:18 +0200 | <geekosaur> | o.O but this search did just introduce me to https://github.com/wouter-swierstra/xmonad (xmonad in Coq?!) |
| 2022-05-12 18:29:51 +0200 | <sm> | that's the danger of these search tools.. you find all kinds of stuff |
| 2022-05-12 18:30:01 +0200 | <lechner> | or not |
| 2022-05-12 18:30:19 +0200 | Guest|52 | (~Guest|52@c-76-23-5-70.hsd1.ut.comcast.net) |
| 2022-05-12 18:30:32 +0200 | <Bulby[m]> | I really like haskell in general... it makes work fast |
| 2022-05-12 18:31:27 +0200 | <shiraeeshi> | hey |
| 2022-05-12 18:31:44 +0200 | <shiraeeshi> | how is it going |
| 2022-05-12 18:31:56 +0200 | vysn | (~vysn@user/vysn) (Ping timeout: 260 seconds) |
| 2022-05-12 18:31:59 +0200 | <shiraeeshi> | I'm trying to follow "Advanced Track: Understanding Memory Usage with eventlog2html and ghc-debug @ZuriHac21" |
| 2022-05-12 18:32:10 +0200 | <shiraeeshi> | https://youtu.be/6Ljv5FHGXDM |
| 2022-05-12 18:32:19 +0200 | <shiraeeshi> | https://github.com/well-typed/memory-usage-zurihac-2021 |
| 2022-05-12 18:32:47 +0200 | catern | (~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407) |
| 2022-05-12 18:33:23 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 18:33:35 +0200 | <shiraeeshi> | the problem is that Cabal can't resolve dependencies when I run "cabal build tui simple debugger realworld-exe" |
| 2022-05-12 18:34:17 +0200 | <sm> | weird.. didn't there used to be a "global" gitlab instance ? I can't find it |
| 2022-05-12 18:35:18 +0200 | <shiraeeshi> | here is the error message https://paste.tomsmeding.com/cYesMoSt |
| 2022-05-12 18:36:09 +0200 | cheater | (~Username@user/cheater) (Ping timeout: 265 seconds) |
| 2022-05-12 18:36:59 +0200 | <shiraeeshi> | it's saying that it's trying base-4.13 as a dependency of aeson-lens, I checked its .cabal file and it says "base >=4.5 && <5" |
| 2022-05-12 18:37:04 +0200 | <sm> | ah, you have to sign in |
| 2022-05-12 18:37:09 +0200 | <sm> | weird |
| 2022-05-12 18:38:00 +0200 | <shiraeeshi> | the conflict is with the debugger's dependency which is "base>=4.14" |
| 2022-05-12 18:38:06 +0200 | <sm> | shiraeeshi: often it's fixed on a certain base version because of your GHC version, and the fix is to use a GHC version / stackage resolver of the same age as the project |
| 2022-05-12 18:38:25 +0200 | vicfred | (~vicfred@user/vicfred) |
| 2022-05-12 18:38:47 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-12 18:38:56 +0200 | <catern> | this is more of a Nix question, but how would I set up a nix-shell with all my haskell dependencies and then build a project? this inspired by me (knowing nothing about building Haskell) wanting to make a small contribution to https://github.com/agda/agda and seeing that it has https://github.com/agda/agda/blob/master/flake.nix#L17 which isn't actually properly set up |
| 2022-05-12 18:38:59 +0200 | <shiraeeshi> | oh, ok, let's see |
| 2022-05-12 18:40:09 +0200 | troydm1 | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-05-12 18:40:39 +0200 | <slack1256> | catern: The new an modern way is to use "nix flakes", which ship with templates for you haskell projects. |
| 2022-05-12 18:40:42 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 276 seconds) |
| 2022-05-12 18:41:06 +0200 | <slack1256> | `nix flake new -t templates#haskell-hello .` is the starting point. |
| 2022-05-12 18:42:54 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-12 18:45:35 +0200 | troydm1 | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 256 seconds) |
| 2022-05-12 18:47:17 +0200 | epolanski | (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-05-12 18:47:42 +0200 | Guest|52 | (~Guest|52@c-76-23-5-70.hsd1.ut.comcast.net) (Quit: Connection closed) |
| 2022-05-12 18:51:06 +0200 | <catern> | slack1256: ah, I see! that suggests some interesting changes, but I'm not sure how that would mesh with https://github.com/agda/agda which has a Makefile which starts by installing dependencies with cabal: https://github.com/agda/agda/blob/master/Makefile#L153-L154 |
| 2022-05-12 18:56:25 +0200 | <[Leary]> | catern: Does `nix develop` using the flake you linked not produce an environment where you can build the package? I'm not sure why it's written like that, but if you need to modify the devShell implementation, perhaps have a look at the xmonad and xmonad-contrib devShells. |
| 2022-05-12 18:59:33 +0200 | <catern> | [Leary]: the devShell definitely needs to be modified |
| 2022-05-12 19:00:12 +0200 | waleee | (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 2022-05-12 19:00:22 +0200 | <catern> | is a simple "cabal install" the thing that I should expect to work to build the package? |
| 2022-05-12 19:02:57 +0200 | Vajb | (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) (Read error: Connection reset by peer) |
| 2022-05-12 19:03:04 +0200 | <[Leary]> | catern: I think that depends on the complexity of the build. It should work with most haskell packages, but maybe not in this case. Have a look at `nix develop --help`. It shows how you can run parts of the build process that nix uses. |
| 2022-05-12 19:04:05 +0200 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-05-12 19:06:50 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-05-12 19:09:42 +0200 | moonsheep | (~user@user/moonsheep) |
| 2022-05-12 19:12:28 +0200 | fef | (~thedawn@user/thedawn) |
| 2022-05-12 19:15:11 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 19:15:49 +0200 | Everything | (~Everythin@37.115.210.35) () |
| 2022-05-12 19:17:16 +0200 | vpan | (~0@212.117.1.172) (Quit: Leaving.) |
| 2022-05-12 19:18:11 +0200 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 2022-05-12 19:19:32 +0200 | <shiraeeshi> | this is unusual |
| 2022-05-12 19:20:30 +0200 | <shiraeeshi> | downloaded dependencies won't compile: https://paste.tomsmeding.com/Zl504Nqj and https://paste.tomsmeding.com/BFlPCCaF |
| 2022-05-12 19:21:00 +0200 | <sm> | unusual, you say.. |
| 2022-05-12 19:21:26 +0200 | <sm> | this can happen when published packages have bounds that are too loose, allowing such build errors |
| 2022-05-12 19:21:39 +0200 | <sm> | there might be discussion in the packages' issue trackers |
| 2022-05-12 19:21:57 +0200 | <sm> | using stackage avoids this |
| 2022-05-12 19:23:07 +0200 | acidjnk_new | (~acidjnk@p200300d0c7068b99c0183a275a5d2a59.dip0.t-ipconnect.de) |
| 2022-05-12 19:23:13 +0200 | <shiraeeshi> | version mismatch again? |
| 2022-05-12 19:23:28 +0200 | <shiraeeshi> | here we go |
| 2022-05-12 19:24:50 +0200 | <shiraeeshi> | the project readme says: |
| 2022-05-12 19:24:52 +0200 | <shiraeeshi> | Or, alternatively, use this nix invocation to set-up the environment. |
| 2022-05-12 19:25:01 +0200 | <shiraeeshi> | nix-shell |
| 2022-05-12 19:25:43 +0200 | <texasmynsted> | I encounter this kind of problem often. I have a small snip of text like a markdown image tag and want to convert it to an HTML img tag. That is the only change, but needed _often_. |
| 2022-05-12 19:25:48 +0200 | <sm> | there's a newer https://hackage.haskell.org/package/base16-bytestring-1.0.2.0/changelog , sometimes a cabal update helps |
| 2022-05-12 19:26:13 +0200 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-05-12 19:26:14 +0200 | <sm> | pipe it through pandoc, texasmynsted |
| 2022-05-12 19:26:18 +0200 | <catern> | (lol okay I'm just going to give up on building agda and just file https://github.com/agda/agda/issues/5901 ) |
| 2022-05-12 19:26:34 +0200 | <texasmynsted> | I kind of feel like I should be using parsec to parse the markdown to an AST, then write it back out in the new format. |
| 2022-05-12 19:27:12 +0200 | moonsheep | (~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 2022-05-12 19:27:28 +0200 | <texasmynsted> | I only want to change the "selected" markdown image tag. |
| 2022-05-12 19:28:21 +0200 | <texasmynsted> | sm: hmm. Interesting. I have never thought to pipe a single tag through pandoc. |
| 2022-05-12 19:29:03 +0200 | mbuf | (~Shakthi@27.58.139.1) (Quit: Leaving) |
| 2022-05-12 19:29:06 +0200 | <texasmynsted> | It seems like that _should_ work |
| 2022-05-12 19:29:14 +0200 | <sm> | just "pandoc" works (md -> html is the default). It adds some extra tags, but options might stop those |
| 2022-05-12 19:29:38 +0200 | z812 | (~zyg@user/z812) |
| 2022-05-12 19:29:59 +0200 | <texasmynsted> | and it literally parses the text, converts it to an AST then transforms it out again. :-) |
| 2022-05-12 19:30:06 +0200 | <sm> | yup |
| 2022-05-12 19:30:29 +0200 | <sm> | but if you mean within a haskell program, then maybe one of the markdown libs is the way to go (not the pandoc lib, it is huge) |
| 2022-05-12 19:30:51 +0200 | <texasmynsted> | Mostly when editing markdown documents. |
| 2022-05-12 19:31:08 +0200 | <texasmynsted> | I can hook the solution into neovim, and other places I am sure |
| 2022-05-12 19:31:27 +0200 | <sm> | I'm in emacs, so it'd be select, C-u S-M-| pandoc |
| 2022-05-12 19:33:04 +0200 | z812 | (~zyg@user/z812) (Bye-bye!) |
| 2022-05-12 19:34:09 +0200 | econo | (uid147250@user/econo) |
| 2022-05-12 19:34:32 +0200 | <texasmynsted> | Hmm. nice |
| 2022-05-12 19:35:05 +0200 | <texasmynsted> | It _works_. Now to see how I can modify it. Maybe a filter or something? |
| 2022-05-12 19:35:43 +0200 | <texasmynsted> | It adds a figure, and I might want to have the image stand alone, and have a default width. |
| 2022-05-12 19:36:45 +0200 | <texasmynsted> | This is great. Thank you. |
| 2022-05-12 19:38:54 +0200 | <sm> | `pandoc -rmarkdown-implicit_figures` stops it adding figure tags |
| 2022-05-12 19:39:17 +0200 | <texasmynsted> | :-) |
| 2022-05-12 19:39:35 +0200 | CiaoSen | (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2022-05-12 19:39:37 +0200 | <texasmynsted> | One key is default width |
| 2022-05-12 19:41:21 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) |
| 2022-05-12 19:42:54 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Quit: ec) |
| 2022-05-12 19:43:13 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-05-12 19:43:27 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Client Quit) |
| 2022-05-12 19:43:38 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-05-12 19:45:00 +0200 | dschrempf | (~dominik@mobiledyn-62-240-134-183.mrsn.at) |
| 2022-05-12 19:45:40 +0200 | tusko | (~yeurt@user/tusko) |
| 2022-05-12 19:45:45 +0200 | <tusko> | I have question |
| 2022-05-12 19:45:51 +0200 | <tusko> | not smart |
| 2022-05-12 19:46:00 +0200 | <tusko> | What's the deal with let |
| 2022-05-12 19:46:23 +0200 | cheater | (~Username@user/cheater) |
| 2022-05-12 19:48:44 +0200 | <geekosaur[m][m]> | I don't understand the question |
| 2022-05-12 19:49:06 +0200 | <tusko> | I give examples |
| 2022-05-12 19:49:21 +0200 | <tusko> | let (_,x) = (10, "turtlebutt") in x |
| 2022-05-12 19:49:23 +0200 | <tusko> | wow |
| 2022-05-12 19:49:32 +0200 | <tusko> | , what a verbose way to index into the tuple |
| 2022-05-12 19:49:33 +0200 | alp_ | (~alp@user/alp) (Remote host closed the connection) |
| 2022-05-12 19:49:58 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-12 19:51:08 +0200 | <sm> | because I can't leave well enough alone.. and wanted to get rid of the <p></p> tags (and pandoc is haskell-related).. |
| 2022-05-12 19:51:09 +0200 | <sm> | echo '' | pandoc -rgfm -tnative | cut -c7- | sed -e 's/]$//' | pandoc -rnative |
| 2022-05-12 19:51:23 +0200 | <geekosaur[m][m]> | Tuples aren't very good, we recommend against using them |
| 2022-05-12 19:51:51 +0200 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2022-05-12 19:51:57 +0200 | <tusko> | Ok, I can get behind this. I do not use Tuples except when elements are immutable (usually). |
| 2022-05-12 19:51:59 +0200 | <romesrf> | tusko: `snd (10, "tt")` |
| 2022-05-12 19:52:13 +0200 | <romesrf> | snd :: (a,b) -> b |
| 2022-05-12 19:52:18 +0200 | <geekosaur[m][m]> | Pretty much the only thing you can do is pattern match them |
| 2022-05-12 19:52:50 +0200 | Nux32 | (~Nux@92.139.200.146.dyn.plus.net) |
| 2022-05-12 19:53:07 +0200 | <tusko> | I guess the Haskell tutorial on the website, and my general experience with functional PLs, is lead me to think "wow, this is so verbose to do such simple things" |
| 2022-05-12 19:53:13 +0200 | <geekosaur[m][m]> | Or use the canned ones, with 2-tuples only |
| 2022-05-12 19:53:15 +0200 | <dminuoso> | [exa]: Mmm, is there a way to create a generic `transparent :: Pixel a => a`? |
| 2022-05-12 19:53:35 +0200 | <dminuoso> | Or well, that wont quite work |
| 2022-05-12 19:54:15 +0200 | <dminuoso> | It'd be some kind of `transparent :: HasAlpha (PixelBaseComponent a) => Pixel a => a` |
| 2022-05-12 19:54:20 +0200 | mshiraeeshi | (~shiraeesh@109.166.56.211) |
| 2022-05-12 19:54:26 +0200 | <telser> | Usually better to have a more expressive type than a tuple. |
| 2022-05-12 19:54:50 +0200 | dextaa490 | (~dextaa@user/dextaa) (Quit: The Lounge - https://thelounge.chat) |
| 2022-05-12 19:54:59 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 260 seconds) |
| 2022-05-12 19:55:07 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 19:55:08 +0200 | <tusko> | Let me I will get you a better example |
| 2022-05-12 19:55:24 +0200 | <dminuoso> | tusko: Indexing into tuples is not a common operation. |
| 2022-05-12 19:55:59 +0200 | <sm> | tusko, some things are verbose, some are terse. Overall it's pretty good |
| 2022-05-12 19:56:02 +0200 | <tusko> | let square x = x * x in square 3 |
| 2022-05-12 19:56:08 +0200 | <tusko> | pointless |
| 2022-05-12 19:56:24 +0200 | zincy | (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) |
| 2022-05-12 19:56:34 +0200 | <geekosaur[m][m]> | Most simple examples are |
| 2022-05-12 19:56:39 +0200 | <tusko> | let (a,b) = (10,12) in a * 2 ...but why |
| 2022-05-12 19:56:45 +0200 | <sm> | sometimes people name things for clarity |
| 2022-05-12 19:56:57 +0200 | <dminuoso> | tusko: Where do you have these examples from? |
| 2022-05-12 19:56:59 +0200 | shiraeeshi | (~shiraeesh@77.94.25.209) (Ping timeout: 256 seconds) |
| 2022-05-12 19:57:00 +0200 | <dminuoso> | They are all poor examples. |
| 2022-05-12 19:57:30 +0200 | <tusko> | This is what I really had in mind, but couldn't think how to reproduce it. (I'm very new to Haskell). let _:_:c:_ = "abcd" in c |
| 2022-05-12 19:57:37 +0200 | <dminuoso> | My most frequent use of tuples arises from working with maps from the `containers` package. |
| 2022-05-12 19:57:43 +0200 | <geekosaur[m][m]> | Because we actually use them for more complicated expressions |
| 2022-05-12 19:57:48 +0200 | <dminuoso> | @let import qualified Data.Map as M |
| 2022-05-12 19:57:49 +0200 | <lambdabot> | Defined. |
| 2022-05-12 19:57:50 +0200 | <dminuoso> | :t M.assocs |
| 2022-05-12 19:57:52 +0200 | <lambdabot> | M.Map k a -> [(k, a)] |
| 2022-05-12 19:57:52 +0200 | <dminuoso> | Things like this |
| 2022-05-12 19:58:20 +0200 | <dminuoso> | Though its often more elegant to use |
| 2022-05-12 19:58:34 +0200 | <dminuoso> | % :t M.foldrWithKey |
| 2022-05-12 19:58:38 +0200 | <dminuoso> | :t M.foldrWithKey |
| 2022-05-12 19:58:39 +0200 | <lambdabot> | (k -> a -> b -> b) -> b -> M.Map k a -> b |
| 2022-05-12 19:58:47 +0200 | <geekosaur[m][m]> | But that leads beginners to focus on the complicated expressions instead of the patterns |
| 2022-05-12 19:58:48 +0200 | <dminuoso> | Which I guess is equivalent to assocs |
| 2022-05-12 19:59:08 +0200 | slack1256 | (~slack1256@191.125.227.220) (Remote host closed the connection) |
| 2022-05-12 19:59:17 +0200 | <dminuoso> | :t M.fromList |
| 2022-05-12 19:59:18 +0200 | <lambdabot> | Ord k => [(k, a)] -> M.Map k a |
| 2022-05-12 19:59:31 +0200 | slack1256 | (~slack1256@191.125.227.220) |
| 2022-05-12 19:59:50 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-05-12 20:03:00 +0200 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-05-12 20:03:58 +0200 | sm | plans to take over `@where links`, since it refers to the dead http://groups.inf.ed.ac.uk/links |
| 2022-05-12 20:05:07 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-12 20:06:23 +0200 | xkuru | (~xkuru@user/xkuru) |
| 2022-05-12 20:08:01 +0200 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-05-12 20:08:49 +0200 | pie_ | (~pie_bnc@user/pie/x-2818909) () |
| 2022-05-12 20:08:50 +0200 | kenran | (~kenran@200116b82b161c00019eb3ff6945071f.dip.versatel-1u1.de) |
| 2022-05-12 20:09:13 +0200 | pie_ | (~pie_bnc@user/pie/x-2818909) |
| 2022-05-12 20:10:30 +0200 | dschrempf | (~dominik@mobiledyn-62-240-134-183.mrsn.at) (Ping timeout: 240 seconds) |
| 2022-05-12 20:11:41 +0200 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-05-12 20:11:46 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 2022-05-12 20:12:36 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2022-05-12 20:15:57 +0200 | zincy | (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) (Remote host closed the connection) |
| 2022-05-12 20:16:28 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-05-12 20:17:50 +0200 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 240 seconds) |
| 2022-05-12 20:21:40 +0200 | zincy | (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) |
| 2022-05-12 20:23:57 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 20:24:41 +0200 | <tusko> | I want to love Haskell but its hard to get a feel for the language with this weak tutorial. |
| 2022-05-12 20:25:04 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2022-05-12 20:25:16 +0200 | <Bulby[m]> | ah haskell, a good language with a lack of documentation |
| 2022-05-12 20:25:20 +0200 | <tusko> | I know a place that had a whole product worked out in Haskell, but then the people who made it left and the new people don't know any Haskell. |
| 2022-05-12 20:25:25 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Remote host closed the connection) |
| 2022-05-12 20:25:39 +0200 | <tusko> | So, of course, they scrapped the Haskell and remade the entire project in Rust. |
| 2022-05-12 20:25:45 +0200 | HotblackDesiato | (~HotblackD@gateway/tor-sasl/hotblackdesiato) |
| 2022-05-12 20:25:47 +0200 | <Bulby[m]> | HAHAH |
| 2022-05-12 20:25:48 +0200 | <tusko> | Something about that just always seemed wrong to me. |
| 2022-05-12 20:26:26 +0200 | <Bulby[m]> | haskell is one of my favorite langs now - it's very powerful |
| 2022-05-12 20:26:33 +0200 | <Bulby[m]> | blub paradox strikes again |
| 2022-05-12 20:27:03 +0200 | <dmj`> | tusko: I've heard of Haskell projects getting scrapped for rust too ... sad. |
| 2022-05-12 20:28:12 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 20:28:44 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 20:33:04 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 2022-05-12 20:34:44 +0200 | <sm> | I'd say "lack of documentation" is not one of the problems we have at this point |
| 2022-05-12 20:35:45 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds) |
| 2022-05-12 20:36:41 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-12 20:36:53 +0200 | <sm> | and, sometimes rust is a better fit ? |
| 2022-05-12 20:37:20 +0200 | <sm> | scrapping work wastefully for the bad reasons is sad I agree |
| 2022-05-12 20:38:01 +0200 | <lechner> | "everything is a monad" is the desperate cry before they switch |
| 2022-05-12 20:39:12 +0200 | zeenk | (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Quit: Konversation terminated!) |
| 2022-05-12 20:42:29 +0200 | <lechner> | i know such a place too |
| 2022-05-12 20:43:32 +0200 | <dmj`> | "everything is a monad" ... famous last words |
| 2022-05-12 20:44:14 +0200 | <lechner> | it was voice processing, went to Java |
| 2022-05-12 20:44:21 +0200 | <davean> | Some things are only functors, some things are groups, everything is something though. |
| 2022-05-12 20:45:12 +0200 | <lechner> | it's from their prespective. only monads do something |
| 2022-05-12 20:46:30 +0200 | <Henson> | why not hire more Haskell people instead of scrapping the whole project and starting over? |
| 2022-05-12 20:47:04 +0200 | <darkling> | Haskell people are much harder to find, and if you've got nobody who already knows Haskell, you've got less knowledge of whether they're any good, too. |
| 2022-05-12 20:47:30 +0200 | <Henson> | ahh |
| 2022-05-12 20:47:48 +0200 | <darkling> | s/knowledge/certainty/ |
| 2022-05-12 20:47:52 +0200 | <telser> | Particularly if you restrict yourself geographically, which some companies do. |
| 2022-05-12 20:47:56 +0200 | <davean> | I mean Haskell people also are generally high enough skilled to have competing decent paying jobs available. |
| 2022-05-12 20:48:43 +0200 | <davean> | I litterly see places like "Oh surely we can hire a programmer for $60k", I don't know where they get *any* programmer worth hiring for that, never mind one with a given skill. |
| 2022-05-12 20:49:31 +0200 | <Henson> | Are Haskell devs difficult to come by, if you don't restrict yourself geographically and pay decently? |
| 2022-05-12 20:49:39 +0200 | <davean> | Not really |
| 2022-05-12 20:50:18 +0200 | <carbolymer> | davean: I'm not doing recruitment, but my current and past workplace struggled hard to find a good haskell dev |
| 2022-05-12 20:50:29 +0200 | <carbolymer> | idk what they did wrong, but it was hard |
| 2022-05-12 20:50:35 +0200 | <davean> | carbolymer: what did they do? |
| 2022-05-12 20:50:46 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 20:51:10 +0200 | <darkling> | Offerd $60k pa? |
| 2022-05-12 20:51:56 +0200 | <carbolymer> | pay is not bad in both places, I was satisfied |
| 2022-05-12 20:52:14 +0200 | <maerwald> | Henson: compared to? |
| 2022-05-12 20:53:00 +0200 | <davean> | Yah I just mentioned the $60k because recently I saw one of those and the "straight out of college, not even graduated yet" people I know take jobs above twice that with zero experience and no particular skill past classes. |
| 2022-05-12 20:53:10 +0200 | <davean> | So it was a particularly clear case of "uh, what?" |
| 2022-05-12 20:53:13 +0200 | slac14257 | (~slack1256@191.126.227.91) |
| 2022-05-12 20:53:18 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-05-12 20:53:31 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 20:53:33 +0200 | <Henson> | maerwald: well, compared to "we've been searching for 6 months and don't have any competent Haskell developer applications" |
| 2022-05-12 20:53:41 +0200 | <Henson> | applications -> applicants |
| 2022-05-12 20:53:56 +0200 | <maerwald> | I mean, if you're trying to outsource to some 3rd world country and pay below minimum wages, I'd guess it's hard |
| 2022-05-12 20:54:41 +0200 | <davean> | yah you won't find many undereducated 3rd world Haskell devs. |
| 2022-05-12 20:55:09 +0200 | <davean> | But honestly if you're looking in the general vein of standard, compitent programmers, I think they're easier to hire? |
| 2022-05-12 20:55:13 +0200 | <maerwald> | Although there's a fair amount of Haskellers in India and living cost there is low, but they usually know what they're worth |
| 2022-05-12 20:55:28 +0200 | <telser> | davean: I'd imagine that is highly variable based on location. I'd be surprised to find entry level positions in my area for >120k |
| 2022-05-12 20:55:54 +0200 | slack1256 | (~slack1256@191.125.227.220) (Ping timeout: 276 seconds) |
| 2022-05-12 20:55:59 +0200 | <davean> | telser: I mean that was true 10 years ago, but now? No? Everyone has gone remote - you're always competing with that |
| 2022-05-12 20:56:01 +0200 | <maerwald> | entry level in Europe is 50k €... I've seen Haskell positions in Sweden for 55-65k for seniors |
| 2022-05-12 20:56:21 +0200 | <davean> | maerwald: Yah but pay in Europe is different because costs are different. |
| 2022-05-12 20:56:34 +0200 | <davean> | (For the employees, via benefits and taxes) |
| 2022-05-12 20:56:37 +0200 | <whatsupdoc> | Wow, that's broke money |
| 2022-05-12 20:56:41 +0200 | <maerwald> | there was a Haskell position in japan for 9 million yen in Tokyo, which is a joke there |
| 2022-05-12 20:56:41 +0200 | <davean> | so thats lower but not insanely low |
| 2022-05-12 20:56:52 +0200 | <maerwald> | davean: 45% is tax here bro |
| 2022-05-12 20:57:05 +0200 | <maerwald> | even worse when you're self employed |
| 2022-05-12 20:57:13 +0200 | <davean> | maerwald: Yes, I'm aware - more if you're getting paid from an out-side-EU country. |
| 2022-05-12 20:57:42 +0200 | <maerwald> | I've been paid by SEA countries, it doesn't get better, because they pay based on your location |
| 2022-05-12 20:58:11 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-12 20:58:35 +0200 | <maerwald> | that's the new thing... salaries haven't gone global, now they pay you less, because you're living in India |
| 2022-05-12 20:59:05 +0200 | <maerwald> | not that I care much anyway |
| 2022-05-12 20:59:15 +0200 | <maerwald> | can't buy health with money |
| 2022-05-12 20:59:29 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Remote host closed the connection) |
| 2022-05-12 21:04:43 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 21:05:30 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 21:09:04 +0200 | fef | (~thedawn@user/thedawn) (Ping timeout: 240 seconds) |
| 2022-05-12 21:12:11 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 21:12:56 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 21:22:57 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 21:30:27 +0200 | MoC | (~moc@user/moc) |
| 2022-05-12 21:31:30 +0200 | merijn | (~merijn@86-86-29-250.fixed.kpn.net) |
| 2022-05-12 21:32:52 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-05-12 21:32:59 +0200 | pavonia | (~user@user/siracusa) |
| 2022-05-12 21:34:06 +0200 | <mshiraeeshi> | concerning the errors I previously posted: could the reason be that the readme of the project says that I need ghc-9.2 (and there is a link to ghc 9.2.1), but I'm building it with ghc-9.2.2 |
| 2022-05-12 21:35:47 +0200 | <mshiraeeshi> | they point to ghc-9.2.1-alpha2 |
| 2022-05-12 21:36:14 +0200 | <tomsmeding> | wasn't the Word# to Word8# shift in 9.2 |
| 2022-05-12 21:37:44 +0200 | <mshiraeeshi> | let's say I want to try ghc-9.2.1-alpha2, is there a way to install this version using ghcup? |
| 2022-05-12 21:38:03 +0200 | <maerwald> | where is that version |
| 2022-05-12 21:38:35 +0200 | <mshiraeeshi> | what do you mean? |
| 2022-05-12 21:38:40 +0200 | coot | (~coot@213.134.190.95) |
| 2022-05-12 21:38:46 +0200 | <mshiraeeshi> | or do I have to do it outside of ghcup? |
| 2022-05-12 21:38:55 +0200 | <tomsmeding> | https://downloads.haskell.org/~ghc/9.2.1-alpha2/ here, presumably |
| 2022-05-12 21:38:58 +0200 | <maerwald> | ghcup install ghc -u https://downloads.haskell.org/ghc/9.2.1-alpha2/ghc-9.2.0.20210422-x86_64-fedora27-linux.tar.xz 9.2.0.20210422 |
| 2022-05-12 21:39:00 +0200 | <maerwald> | is a workaround |
| 2022-05-12 21:39:02 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-05-12 21:39:26 +0200 | <mshiraeeshi> | ok, let me try |
| 2022-05-12 21:39:41 +0200 | <maerwald> | pre-releases can be enabled via https://www.haskell.org/ghcup/guide/#pre-release-channels ...but 9.2.1-alpha2 has not been added |
| 2022-05-12 21:39:59 +0200 | <maerwald> | is there a point? 9.2.2 is already out |
| 2022-05-12 21:40:54 +0200 | <mshiraeeshi> | I think it's got to be ghc, because they have a certain disposition of dependencies in their configs, so it should've worked in their environments |
| 2022-05-12 21:41:20 +0200 | <maerwald> | you can provide a PR to add 9.2.1 to https://github.com/haskell/ghcup-metadata/blob/master/ghcup-prereleases-0.0.7.yaml |
| 2022-05-12 21:42:16 +0200 | alp_ | (~alp@user/alp) (Remote host closed the connection) |
| 2022-05-12 21:42:42 +0200 | alp_ | (~alp@user/alp) |
| 2022-05-12 21:42:43 +0200 | <sm> | mshiraeeshi: I'd expect 9.2.2 to be good for this, and I would have to be very highly motivated (paid) to go back to an alpha |
| 2022-05-12 21:42:48 +0200 | Pickchea | (~private@user/pickchea) |
| 2022-05-12 21:42:55 +0200 | <sm> | you should probably check the issue tracker / contact the maintainer at this point |
| 2022-05-12 21:43:12 +0200 | <sm> | so they can make this more buildable |
| 2022-05-12 21:43:50 +0200 | <mshiraeeshi> | sm: but it obviously worked for those people who created the project? |
| 2022-05-12 21:44:10 +0200 | <mshiraeeshi> | I mean, the https://github.com/well-typed/memory-usage-zurihac-2021 project |
| 2022-05-12 21:44:23 +0200 | <sm> | I suppose ? |
| 2022-05-12 21:44:45 +0200 | <sm> | are you using nix ? |
| 2022-05-12 21:44:48 +0200 | <mshiraeeshi> | how can the same version of the package work and then fail to compile 7 months later? |
| 2022-05-12 21:44:59 +0200 | <mshiraeeshi> | no, no nix |
| 2022-05-12 21:45:10 +0200 | <sm> | very, very easily. It's the norm, not the exception |
| 2022-05-12 21:45:36 +0200 | <mshiraeeshi> | I also wanted to ask about nix. the readme says: "Or, alternatively, use this nix invocation to set-up the environment." |
| 2022-05-12 21:45:40 +0200 | <tomsmeding> | mshiraeeshi: that can happen if the package has loose (or nonexistent) upper bounds, and packages have been updated on hackage in the mean time |
| 2022-05-12 21:45:46 +0200 | <sm> | nix, stack, cabal.project are all attempts to make it more repeatable |
| 2022-05-12 21:45:48 +0200 | <tdammers> | the reason this can happen is because of how version bounds work, and how people use them |
| 2022-05-12 21:45:49 +0200 | <mshiraeeshi> | using "nix-shell" command |
| 2022-05-12 21:46:23 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 21:46:36 +0200 | <tomsmeding> | the difference is almost certainly not between 9.2.1-alpha2 and 9.2.2; ghc doesn't really do breaking changes (at least not like "core type is named differently") on such a minor version number change |
| 2022-05-12 21:46:58 +0200 | <tomsmeding> | you're using a different version of some dependency to get those option and Word8# errors |
| 2022-05-12 21:47:25 +0200 | <mshiraeeshi> | can I workaround this by using nix? |
| 2022-05-12 21:47:34 +0200 | <tomsmeding> | probably |
| 2022-05-12 21:47:49 +0200 | <sm> | mshiraeeshi: if you don't want to contact the maintainers, alternately you can dig in to the error messages and uplevel your haskell build ninja skills. If you want to do that (in a serious manner, not quick fixes) we can help |
| 2022-05-12 21:47:53 +0200 | <mshiraeeshi> | and let me ask a stupid question just to make sure: it doesn't mean switching to nixos right? |
| 2022-05-12 21:48:20 +0200 | <sclv> | you can use nix-as-an-environment-manager with linux or os x |
| 2022-05-12 21:48:32 +0200 | <tomsmeding> | mshiraeeshi: are you building using cabal or using stack? |
| 2022-05-12 21:48:38 +0200 | <mshiraeeshi> | cabal |
| 2022-05-12 21:48:48 +0200 | <tomsmeding> | the cabal.project lists exact versions for loads of dependencies |
| 2022-05-12 21:49:07 +0200 | <tomsmeding> | so kind of interesting that it still fails for you |
| 2022-05-12 21:49:31 +0200 | <tomsmeding> | oh heh but it also has allow-newer on a bunch of packages, never mind |
| 2022-05-12 21:49:47 +0200 | <sm> | (eg) |
| 2022-05-12 21:49:48 +0200 | <sm> | the prepare script, I believe, which presumably uses cabal.project , but notice that file doesn't specify ghc version |
| 2022-05-12 21:51:14 +0200 | <sm> | summary: it's not your fault, this project is not configured for reproducible building, so someone has to do that work |
| 2022-05-12 21:51:27 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-12 21:51:35 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Ping timeout: 252 seconds) |
| 2022-05-12 21:51:56 +0200 | <sm> | (well, unless the nix-shell route works, then maybe they get half marks) |
| 2022-05-12 21:51:57 +0200 | <sclv> | personally i would start by bumping the base16-bytestring in that cabal.project to 1.0.2.0 |
| 2022-05-12 21:52:00 +0200 | <sclv> | and seeing if that helped |
| 2022-05-12 21:52:05 +0200 | <sm> | agreed! |
| 2022-05-12 21:53:01 +0200 | <mshiraeeshi> | I tried bumping the base16-bytestring to 1.0.2.0, but then the same happened to other packages |
| 2022-05-12 21:53:24 +0200 | <sclv> | well which other packages -- some others might need bumps too! |
| 2022-05-12 21:54:38 +0200 | <mshiraeeshi> | basement, blaze-builder, base-compat |
| 2022-05-12 21:55:47 +0200 | <mshiraeeshi> | perhaps I should rewrite "allow-newer" and fix their version by introducing some upper bounds |
| 2022-05-12 21:56:20 +0200 | <sclv> | well did you try bumping the versions on some of those as well? |
| 2022-05-12 21:56:44 +0200 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-05-12 21:57:08 +0200 | <mshiraeeshi> | no, you mean just incrementing their version numbers? |
| 2022-05-12 21:57:35 +0200 | <sclv> | or removing the constraint entirely from the cabal.project file -- just commenting out the line |
| 2022-05-12 21:57:44 +0200 | <sclv> | the lines in the cabal.project just insert constraints |
| 2022-05-12 21:58:03 +0200 | <sclv> | (except for the allow-newer section, which is about lifting inherited constraints) |
| 2022-05-12 21:58:41 +0200 | <sclv> | this whole thing was always super fragile |
| 2022-05-12 21:59:01 +0200 | <sm> | aside: does cabal's allow-newer also allow older, as in stack ? |
| 2022-05-12 21:59:02 +0200 | <sclv> | if you look at the cabal.project file it wasn't even working against normal hackage, but its set to use the overrides from head.hackage |
| 2022-05-12 21:59:11 +0200 | <sclv> | sm: not afaik |
| 2022-05-12 21:59:42 +0200 | <sclv> | like it was a demo written with a specific pre-release ghc with the pre-release set of ghc base libs and a ton of other libs with custom head.hackage patches |
| 2022-05-12 22:00:06 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 22:00:35 +0200 | <texasmynsted> | sm: thank you :-) |
| 2022-05-12 22:00:38 +0200 | <sclv> | like i would almost try to comment out the entire allow-newer, repoistory, and constraints sections |
| 2022-05-12 22:00:39 +0200 | slac14257 | slack1256 |
| 2022-05-12 22:00:58 +0200 | <sclv> | and try to see what if anything i needed to put back, on an extremely case by case basis |
| 2022-05-12 22:01:33 +0200 | <sm> | texasmynsted: np :) |
| 2022-05-12 22:02:28 +0200 | _ht | (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2022-05-12 22:04:02 +0200 | <dminuoso> | [exa]: By the way, thanks! I had a strange bug with a couple images that simply, for no apparent reason, would bug out a bunch of keys on the deck. |
| 2022-05-12 22:04:14 +0200 | <dminuoso> | If I tend to the pictures with JuicyPixel they appear fine. |
| 2022-05-12 22:04:23 +0200 | <dminuoso> | No clue what imagemagick does there |
| 2022-05-12 22:07:59 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 22:08:36 +0200 | coot | (~coot@213.134.190.95) (Quit: coot) |
| 2022-05-12 22:19:34 +0200 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-05-12 22:24:55 +0200 | slac67882 | (~slack1256@186.11.63.14) |
| 2022-05-12 22:27:09 +0200 | slack1256 | (~slack1256@191.126.227.91) (Ping timeout: 256 seconds) |
| 2022-05-12 22:29:51 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 22:37:32 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-05-12 22:38:20 +0200 | zincy | (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) (Remote host closed the connection) |
| 2022-05-12 22:45:27 +0200 | Nux32 | (~Nux@92.139.200.146.dyn.plus.net) (Quit: Client closed) |
| 2022-05-12 22:48:27 +0200 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 265 seconds) |
| 2022-05-12 22:52:11 +0200 | son0p | (~ff@181.136.122.143) |
| 2022-05-12 22:53:18 +0200 | phma | (~phma@host-67-44-208-35.hnremote.net) (Read error: Connection reset by peer) |
| 2022-05-12 22:53:35 +0200 | <tomsmeding> | dminuoso: like, IM output was somehow borked / not acceptable to streamdeck? |
| 2022-05-12 22:54:14 +0200 | <dminuoso> | Yeah |
| 2022-05-12 22:54:27 +0200 | phma | (phma@2001:5b0:210d:5458:5d56:889b:9db6:9f82) |
| 2022-05-12 22:54:35 +0200 | <dminuoso> | But its essentially impossible to tell why |
| 2022-05-12 22:54:53 +0200 | <dminuoso> | Short of having the source code of the streamdeck or perhaps some magical debugging tools from their engineering team |
| 2022-05-12 22:55:00 +0200 | <tomsmeding> | no discernable difference like "full colour instead of palette-able", or "has transparency" |
| 2022-05-12 22:55:51 +0200 | <dminuoso> | Well, I had this particular image that after IM had done its thing, the image would be resized to about 30%, duplicated twice next to each other on the lower half of the key, with the upper key being filled with the image of the previously set key. |
| 2022-05-12 22:56:10 +0200 | <dminuoso> | *shrugs* |
| 2022-05-12 22:56:37 +0200 | <tomsmeding> | O.o |
| 2022-05-12 22:57:12 +0200 | <dminuoso> | And it was not a transport encoding bug, that is definitely done correctly |
| 2022-05-12 22:57:12 +0200 | <EvanR> | seems like a pretty standard effect |
| 2022-05-12 22:57:15 +0200 | <dminuoso> | heh |
| 2022-05-12 22:57:21 +0200 | <tomsmeding> | if that only happens on the streamdeck, not if you open the image normally on a computer, then yeah streamdeck needs a drink |
| 2022-05-12 22:57:46 +0200 | <dminuoso> | well its really hard to say whats going on with proprietary hardware you have no documentation for. |
| 2022-05-12 22:58:35 +0200 | <dminuoso> | Next up, I need to round those corners. Mission critical you know. |
| 2022-05-12 22:59:23 +0200 | <tomsmeding> | yes that is important |
| 2022-05-12 22:59:58 +0200 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-05-12 23:00:26 +0200 | <Bulby[m]> | https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/Control-Applicative-Combinators.… why are applicatives more prone to memory leaks |
| 2022-05-12 23:02:19 +0200 | abrar_ | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) (Quit: WeeChat 3.3) |
| 2022-05-12 23:03:01 +0200 | abrar | (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) |
| 2022-05-12 23:03:49 +0200 | <dminuoso> | But jokes aside, I dont care for figuring out the silly math of rounding these corners right now,. |
| 2022-05-12 23:04:14 +0200 | <dminuoso> | Given that this goes onto a pi via nixos, I might as well just preprocess them with imagemagick in nixos to round those corners. |
| 2022-05-12 23:05:57 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2022-05-12 23:06:13 +0200 | <zzz> | hi. i've decided to learn about type families, what they are and why they are useful. can someone give me a quick brief and point me to beginner-level resources? |
| 2022-05-12 23:06:56 +0200 | <dminuoso> | They are useful for similar reasons that functions are useful. It's nice to map things to things. |
| 2022-05-12 23:07:17 +0200 | <tomsmeding> | dminuoso: rounding corners with or without anti-aliasing? If with anti-aliasing, what is the RGB subpixel layout of your screen :> |
| 2022-05-12 23:07:44 +0200 | <dminuoso> | tomsmeding: Good question! Given that I want to do text rendering ontop, sub pixel hinting is going to be an important thing. |
| 2022-05-12 23:07:53 +0200 | <dminuoso> | Guess I better buy a microscope |
| 2022-05-12 23:07:57 +0200 | <tomsmeding> | :D |
| 2022-05-12 23:08:18 +0200 | <dminuoso> | But seriously, is there some thing to render fonts onto juicypixel images?> |
| 2022-05-12 23:08:41 +0200 | <tomsmeding> | that would need bindings to some kind of serious text rendering library |
| 2022-05-12 23:08:48 +0200 | <tomsmeding> | text rendering is Hard |
| 2022-05-12 23:08:56 +0200 | <dminuoso> | It cant be harder than caching. |
| 2022-05-12 23:09:36 +0200 | slack1256 | (~slack1256@191.126.227.67) |
| 2022-05-12 23:09:38 +0200 | <tomsmeding> | X doubt https://arstechnica.com/gadgets/2013/08/rendering-bug-crashes-os-x-and-ios-apps-with-string-of-ara… |
| 2022-05-12 23:09:40 +0200 | <dminuoso> | But perhaps once again, I might as well go the easy route and generate them via imagemagick. |
| 2022-05-12 23:09:52 +0200 | <dminuoso> | tomsmeding: to be fair, I dont want font rendering in a damn browser. |
| 2022-05-12 23:09:53 +0200 | alp_ | (~alp@user/alp) (Ping timeout: 252 seconds) |
| 2022-05-12 23:10:08 +0200 | <EvanR> | your best bet is to get a screen with display tech matching your desired shape exactly |
| 2022-05-12 23:10:15 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 23:10:23 +0200 | <tomsmeding> | dminuoso: which browser are you referring to? The thing I linked was a bug in CoreText, a system library |
| 2022-05-12 23:11:14 +0200 | <dminuoso> | tomsmeding: I think rendering is not hard if you dont need to support all writing systems and their bizarrities, and if layouting is not an issue either. |
| 2022-05-12 23:11:34 +0200 | <EvanR> | if you only need 1 resolution on 1 DPI with 1 typeface yeah |
| 2022-05-12 23:11:35 +0200 | <dminuoso> | If you constrain yourself to something like German or English, I think I can be optimistic that text rendering is mostly harmless |
| 2022-05-12 23:11:40 +0200 | <tomsmeding> | dminuoso: then it's certainly easier, but still, hinting? |
| 2022-05-12 23:11:48 +0200 | <tomsmeding> | harmless sure |
| 2022-05-12 23:11:56 +0200 | slac67882 | (~slack1256@186.11.63.14) (Ping timeout: 260 seconds) |
| 2022-05-12 23:12:23 +0200 | <EvanR> | hinting itself considered harmful, as a term |
| 2022-05-12 23:12:33 +0200 | <EvanR> | no one agrees on what it does or is |
| 2022-05-12 23:12:35 +0200 | <tomsmeding> | also anti-aliasing (which for non-ugly font rendering should really be including adapting to subpixel layout) |
| 2022-05-12 23:12:49 +0200 | <tomsmeding> | EvanR: but for small text it suddenly becomes essential |
| 2022-05-12 23:12:52 +0200 | <tomsmeding> | somehow |
| 2022-05-12 23:12:58 +0200 | <EvanR> | whatever it is, it's necessary |
| 2022-05-12 23:13:05 +0200 | <EvanR> | engineering 101 |
| 2022-05-12 23:13:48 +0200 | <EvanR> | basically it's come to mean, make text look subjectively better, without regard to context, viewer, or constraints |
| 2022-05-12 23:14:16 +0200 | <dminuoso> | I guess it becomes a question of convenience |
| 2022-05-12 23:14:17 +0200 | <EvanR> | which turns out to not make sense |
| 2022-05-12 23:14:27 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-05-12 23:14:31 +0200 | <dminuoso> | At the end I dont really need font rendering, as I could do this in another tool. |
| 2022-05-12 23:16:34 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 2022-05-12 23:20:03 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-05-12 23:21:16 +0200 | acidjnk_new | (~acidjnk@p200300d0c7068b99c0183a275a5d2a59.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2022-05-12 23:21:25 +0200 | <mshiraeeshi> | update on me trying to build https://github.com/well-typed/memory-usage-zurihac-2021 |
| 2022-05-12 23:21:43 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 23:22:07 +0200 | <mshiraeeshi> | I've commented out a lot of constraints in cabal.project file based on trial and error |
| 2022-05-12 23:22:32 +0200 | <mshiraeeshi> | and now I'm stuck on aeson and semigroups |
| 2022-05-12 23:23:09 +0200 | <mshiraeeshi> | semigroups removed Data.Semigroup.Option after version 18 |
| 2022-05-12 23:23:43 +0200 | <tomsmeding> | mshiraeeshi: Option is in base-compat-batteries:Data.Semigroup.Compat, which is included in the dep list |
| 2022-05-12 23:23:50 +0200 | <tomsmeding> | also s/Option/Maybe/g |
| 2022-05-12 23:24:07 +0200 | <mshiraeeshi> | that's why it can't build aeson-1.5.6.0 with semigroups-18.0.1 and newer: https://paste.tomsmeding.com/5CmKtj66 |
| 2022-05-12 23:24:42 +0200 | littlebobeep | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-05-12 23:24:53 +0200 | <mshiraeeshi> | but if I build it with semigroups-0.18, I get this error: https://paste.tomsmeding.com/BV60myvJ |
| 2022-05-12 23:25:21 +0200 | <mshiraeeshi> | (a lot of Ambifuous occurence of 'Semigroup' in src/Data/Semigroup.hs) |
| 2022-05-12 23:26:23 +0200 | <tomsmeding> | mshiraeeshi: clone the aeson git repo in a subdirectory, check out the 1.5.6.0 version, add that subdirectory to your cabal.project 'packages' line, build the main project, and then manually remove all the Option instances from aeson |
| 2022-05-12 23:26:28 +0200 | <mshiraeeshi> | tomsmeding: should I try to constrain aeson to a newer version? |
| 2022-05-12 23:26:39 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-05-12 23:26:44 +0200 | <tomsmeding> | mshiraeeshi: aeson 2.0 has a bunch of breaking changes, you can try but is unlikely to work |
| 2022-05-12 23:27:22 +0200 | <mshiraeeshi> | hmm, okay, let's try |
| 2022-05-12 23:32:14 +0200 | slack1256 | (~slack1256@191.126.227.67) (Ping timeout: 252 seconds) |
| 2022-05-12 23:33:42 +0200 | <sclv> | Bulby[m]: i would say applicative is not less efficient _in general_ but rather for specific parser combinators, writing them with only applicative tools rather than monadic ones means that you cannot express certain things as efficiently. |
| 2022-05-12 23:34:44 +0200 | <Bulby[m]> | interesting |
| 2022-05-12 23:35:11 +0200 | <Bulby[m]> | is there a polysemy megaparsec lib |
| 2022-05-12 23:36:39 +0200 | <sclv> | for example look at manyTill in the monad version |
| 2022-05-12 23:36:41 +0200 | <sclv> | https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/src/Control.Monad.Combinators.ht… |
| 2022-05-12 23:36:53 +0200 | <tomsmeding> | sclv: it also says "prone to memory leaks and not as efficient as their monadic counterparts" -- if that refers to expressivity, that's _really_ badly written |
| 2022-05-12 23:36:58 +0200 | <sclv> | compare that to the applicative version |
| 2022-05-12 23:36:58 +0200 | <sclv> | https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/src/Control.Applicative.Combinat… |
| 2022-05-12 23:37:07 +0200 | <sclv> | tomsmeding: its badly written |
| 2022-05-12 23:37:29 +0200 | <sclv> | the latter is cleaner but one can unwind it and see why it might be less efficient |
| 2022-05-12 23:42:37 +0200 | <sclv> | tomsmeding: or rather the point is applicative is definitionally less expressive than monadic. and _hence_ some functions written only with the toolset available to applicative are less efficient than if they were written with the full monadic toolset. |
| 2022-05-12 23:42:50 +0200 | kenran | (~kenran@200116b82b161c00019eb3ff6945071f.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 2022-05-12 23:43:00 +0200 | <sclv> | so expressivity is not the point but rather the thing that explains the performance issues being referred to |
| 2022-05-12 23:43:35 +0200 | <tomsmeding> | right, that makes sense |
| 2022-05-12 23:43:58 +0200 | odnes | (~odnes@5-203-160-39.pat.nym.cosmote.net) |
| 2022-05-12 23:44:11 +0200 | <zzz> | i'm not sure i'm understanding the concept of type families |
| 2022-05-12 23:46:41 +0200 | <mshiraeeshi> | zzz: take a look at "An introduction to typeclass metaprogramming" https://lexi-lambda.github.io/blog/2021/03/25/an-introduction-to-typeclass-metaprogramming/ |
| 2022-05-12 23:47:11 +0200 | <mshiraeeshi> | there's a section called "Type families are functions from types to types" |
| 2022-05-12 23:47:12 +0200 | <Bulby[m]> | I love type families they let me make monsters like higher kinded data |
| 2022-05-12 23:47:47 +0200 | <zzz> | mshiraeeshi: thaks |
| 2022-05-12 23:48:49 +0200 | <mshiraeeshi> | zzz: also "An Introduction to Type Level Programming" https://rebeccaskinner.net/posts/2021-08-25-introduction-to-type-level-programming.html |
| 2022-05-12 23:52:08 +0200 | <mshiraeeshi> | zzz: also "Functional Dependencies" https://www.fpcomplete.com/haskell/tutorial/fundeps/ (there's a short section called "Type families") |
| 2022-05-12 23:52:12 +0200 | <EvanR> | using type (synonym) families you can make MyFam Bool evaluate to Int during type checking |
| 2022-05-12 23:52:34 +0200 | <EvanR> | or vice versa |
| 2022-05-12 23:52:43 +0200 | xaotuk | (~sasha@net137-36-245-109.mbb.telenor.rs) |
| 2022-05-12 23:53:15 +0200 | yauhsien | (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 2022-05-12 23:53:50 +0200 | jgeerds | (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 240 seconds) |
| 2022-05-12 23:53:59 +0200 | Henson | (~kvirc@107-179-133-201.cpe.teksavvy.com) (Ping timeout: 246 seconds) |
| 2022-05-12 23:54:02 +0200 | <mshiraeeshi> | the most easy to understand is the use case described in "Functional Dependencies" |
| 2022-05-12 23:54:37 +0200 | <mshiraeeshi> | the case when you have a Reader and the associated type Env which means the Environment which the reader reads |
| 2022-05-12 23:55:01 +0200 | <mshiraeeshi> | in case of PersonReader the environment is Person |
| 2022-05-12 23:55:15 +0200 | <mshiraeeshi> | in case of Reader env, the environment is env |
| 2022-05-12 23:55:54 +0200 | <zzz> | i'm starting with that. thanks |
| 2022-05-12 23:56:38 +0200 | alx741 | (~alx741@host-181-198-243-150.netlife.ec) |
| 2022-05-12 23:58:26 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
