Logs on 2022-05-12 (liberachat/#haskell)
| 00:00:24 | × | kadobanana quits (~mud@user/kadoban) (Remote host closed the connection) |
| 00:00:49 | → | kadobanana joins (~mud@user/kadoban) |
| 00:01:12 | × | akurilin_ quits (uid322841@id-322841.ilkley.irccloud.com) (Quit: Connection closed for inactivity) |
| 00:01:35 | × | califax quits (~califax@user/califx) (Remote host closed the connection) |
| 00:02:11 | → | littlebobeep joins (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 00:03:33 | → | nate1 joins (~nate@98.45.169.16) |
| 00:05:20 | → | mud joins (~mud@user/kadoban) |
| 00:06:12 | × | kadobanana quits (~mud@user/kadoban) (Ping timeout: 276 seconds) |
| 00:09:06 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 00:11:34 | × | littlebobeep quits (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 00:14:00 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 276 seconds) |
| 00:14:45 | → | littlebobeep joins (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 00:17:49 | → | cyphase joins (~cyphase@user/cyphase) |
| 00:20:49 | → | Sweet joins (~user@s19427110.onlinehome-server.info) |
| 00:21:04 | × | littlebobeep quits (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 00:23:59 | × | machinedgod quits (~machinedg@24.105.81.50) (Ping timeout: 240 seconds) |
| 00:24:51 | → | littlebobeep joins (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 00:31:32 | → | ryanbooker joins (uid4340@id-4340.hampstead.irccloud.com) |
| 00:36:01 | × | xff0x quits (~xff0x@b133147.ppp.asahi-net.or.jp) (Ping timeout: 256 seconds) |
| 00:37:29 | → | noteness_ joins (~noteness@user/noteness) |
| 00:37:34 | × | noteness quits (~noteness@user/noteness) (Ping timeout: 240 seconds) |
| 00:37:48 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 00:38:39 | × | ManofLetters[m] quits (~manoflett@2001:470:69fc:105::3be) (Ping timeout: 240 seconds) |
| 00:38:39 | × | Ash[m] quits (~signal-wa@2001:470:69fc:105::1:2318) (Ping timeout: 240 seconds) |
| 00:38:39 | × | sm quits (~sm@plaintextaccounting/sm) (Ping timeout: 240 seconds) |
| 00:38:39 | × | jmcantrell quits (~jmcantrel@user/jmcantrell) (Ping timeout: 240 seconds) |
| 00:38:47 | × | VarikValefor[m] quits (~varikvale@2001:470:69fc:105::a5d) (Ping timeout: 240 seconds) |
| 00:38:47 | × | yoggurt[m] quits (~yoggurtma@2001:470:69fc:105::2:ba5) (Ping timeout: 252 seconds) |
| 00:38:59 | × | ozataman[m] quits (~ozatamanm@2001:470:69fc:105::1:faa0) (Ping timeout: 240 seconds) |
| 00:38:59 | × | Inst[m] quits (~instrmatr@2001:470:69fc:105::1:903e) (Ping timeout: 240 seconds) |
| 00:38:59 | × | boxscape quits (~boxscape@user/boxscape) (Ping timeout: 240 seconds) |
| 00:38:59 | × | Christoph[m] quits (~hpotsirhc@2001:470:69fc:105::2ff8) (Ping timeout: 240 seconds) |
| 00:39:00 | × | geekosaur[m][m] quits (~geekosaur@2001:470:69fc:105::2:cb7) (Ping timeout: 248 seconds) |
| 00:39:07 | × | kadoban quits (~kadoban@user/kadoban) (Ping timeout: 240 seconds) |
| 00:39:15 | × | fgaz quits (~fgaz@2001:470:69fc:105::842) (Ping timeout: 260 seconds) |
| 00:39:18 | × | amesgen[m] quits (~amesgenm]@2001:470:69fc:105::82b) (Ping timeout: 260 seconds) |
| 00:39:18 | × | lyiriyah[m] quits (~lyiriyahm@2001:470:69fc:105::cc0) (Ping timeout: 260 seconds) |
| 00:39:18 | × | RajatVerma[m] quits (~rajatvmat@2001:470:69fc:105::1:fb34) (Ping timeout: 260 seconds) |
| 00:39:18 | × | jinsun_ quits (~jinsun@user/jinsun) (Ping timeout: 260 seconds) |
| 00:39:18 | × | maralorn quits (~maralorn@2001:470:69fc:105::251) (Ping timeout: 260 seconds) |
| 00:39:18 | × | juhp[m] quits (~juhpmatri@2001:470:69fc:105::6e9) (Ping timeout: 260 seconds) |
| 00:39:18 | × | vaibhavsagar[m] quits (~vaibhavsa@2001:470:69fc:105::ffe) (Ping timeout: 260 seconds) |
| 00:39:18 | × | hughjfchen[m] quits (~hughjfche@2001:470:69fc:105::c29d) (Ping timeout: 252 seconds) |
| 00:39:18 | × | Andy[m] quits (~anparrama@2001:470:69fc:105::1:6826) (Ping timeout: 252 seconds) |
| 00:39:19 | × | Bulby[m] quits (~bulbyvrma@2001:470:69fc:105::1:fe0a) (Ping timeout: 252 seconds) |
| 00:39:19 | × | jneira[m] quits (~jneiramat@2001:470:69fc:105::d729) (Ping timeout: 252 seconds) |
| 00:39:19 | × | DemiMarieObenour quits (~alwayscur@2001:470:69fc:105::4886) (Ping timeout: 252 seconds) |
| 00:39:19 | × | ongy[m] quits (~ongymatri@2001:470:69fc:105::5018) (Ping timeout: 252 seconds) |
| 00:39:19 | × | vestige[m] quits (~vestigema@2001:470:69fc:105::1:f9dd) (Ping timeout: 252 seconds) |
| 00:39:19 | × | smichel17[m] quits (~smichel17@2001:470:69fc:105::2d32) (Ping timeout: 240 seconds) |
| 00:39:19 | × | sjanssen quits (~sjanssenm@2001:470:69fc:105::1:61d8) (Ping timeout: 256 seconds) |
| 00:39:19 | × | reza[m] quits (~rezaphone@2001:470:69fc:105::3eda) (Ping timeout: 256 seconds) |
| 00:39:19 | × | alexfmpe[m] quits (~alexfmpem@2001:470:69fc:105::38ba) (Ping timeout: 256 seconds) |
| 00:39:19 | × | sekun[m] quits (~hsekmatri@2001:470:69fc:105::d18f) (Ping timeout: 256 seconds) |
| 00:39:19 | × | Guillaum[m] quits (~guiboumat@2001:470:69fc:105::1:72ac) (Ping timeout: 256 seconds) |
| 00:39:19 | × | moats quits (~oats@user/oats) (Ping timeout: 256 seconds) |
| 00:39:19 | × | yosef36 quits (~yosefweis@2001:470:69fc:105::1:e501) (Ping timeout: 256 seconds) |
| 00:39:19 | × | ericson2314 quits (~ericson23@2001:470:69fc:105::70c) (Ping timeout: 256 seconds) |
| 00:39:20 | × | Orbstheorem quits (~orbstheor@2001:470:69fc:105::a56) (Ping timeout: 256 seconds) |
| 00:39:20 | × | oak- quits (~oakuniver@2001:470:69fc:105::fcd) (Ping timeout: 248 seconds) |
| 00:39:20 | × | rsify quits (~rsify@2001:470:69fc:105::1:fd44) (Ping timeout: 248 seconds) |
| 00:39:20 | × | SridharRatnakuma quits (~sridmatri@2001:470:69fc:105::1c2) (Ping timeout: 248 seconds) |
| 00:39:20 | × | sibnull[m] quits (~sibnullma@2001:470:69fc:105::1:1291) (Ping timeout: 248 seconds) |
| 00:39:20 | × | maerwald[m] quits (~maerwaldm@2001:470:69fc:105::1ee) (Ping timeout: 248 seconds) |
| 00:39:20 | × | abastro[m] quits (~abastroma@2001:470:69fc:105::1:e119) (Ping timeout: 248 seconds) |
| 00:39:20 | × | Matthew|m quits (~arathorn@2001:470:69fc:105::1f) (Ping timeout: 248 seconds) |
| 00:39:21 | × | cdsmith quits (~cdsmithma@2001:470:69fc:105::284) (Ping timeout: 248 seconds) |
| 00:39:32 | × | ormaaj quits (~ormaaj@user/ormaaj) (Ping timeout: 248 seconds) |
| 00:39:32 | × | ArshiaAghaei[m] quits (~arshiaagh@2001:470:69fc:105::1:c382) (Ping timeout: 248 seconds) |
| 00:39:32 | × | Frikraaa[m] quits (~odirfjohr@2001:470:69fc:105::1:f483) (Ping timeout: 248 seconds) |
| 00:39:32 | × | AdityaAlok[m] quits (~mradityaa@2001:470:69fc:105::1:ee36) (Ping timeout: 248 seconds) |
| 00:39:32 | × | ishaan[m] quits (~ishaanvma@2001:470:69fc:105::1:fb72) (Ping timeout: 248 seconds) |
| 00:39:39 | × | july541[m] quits (~july541ma@2001:470:69fc:105::1:e416) (Ping timeout: 240 seconds) |
| 00:39:50 | × | dyniec[m] quits (~dyniecmat@2001:470:69fc:105::2:a85) (Ping timeout: 260 seconds) |
| 00:39:50 | × | Las[m] quits (~lasmatrix@2001:470:69fc:105::74e) (Ping timeout: 260 seconds) |
| 00:39:50 | × | Pikachu[m] quits (~pychaumat@2001:470:69fc:105::2:1ce) (Ping timeout: 260 seconds) |
| 00:39:50 | × | shlevy[m] quits (~shlevymat@2001:470:69fc:105::1:d3b1) (Ping timeout: 260 seconds) |
| 00:39:50 | × | Yehoshua quits (~yehoshua@2001:470:69fc:105::1:593f) (Ping timeout: 260 seconds) |
| 00:39:50 | × | zfnmxt quits (~zfnmxtzfn@2001:470:69fc:105::2b32) (Ping timeout: 260 seconds) |
| 00:39:51 | × | Tisoxin quits (~ikosit@user/ikosit) (Ping timeout: 252 seconds) |
| 00:39:53 | × | pareto-optimal-d quits (~pareto-op@2001:470:69fc:105::1:b61f) (Ping timeout: 260 seconds) |
| 00:39:53 | × | noiobeforebed quits (~noiobefor@2001:470:69fc:105::1:3c2d) (Ping timeout: 260 seconds) |
| 00:39:53 | × | Artem[m] quits (~artemtype@2001:470:69fc:105::75b) (Ping timeout: 260 seconds) |
| 00:39:53 | × | peddie quits (~peddie@2001:470:69fc:105::25d) (Ping timeout: 260 seconds) |
| 00:39:53 | × | Deide quits (~deide@user/deide) (Ping timeout: 260 seconds) |
| 00:39:53 | × | psydroid quits (~psydroid@user/psydroid) (Ping timeout: 260 seconds) |
| 00:39:53 | × | siraben quits (~siraben@user/siraben) (Ping timeout: 260 seconds) |
| 00:39:53 | × | schuelermine[m] quits (~schuelerm@user/schuelermine) (Ping timeout: 248 seconds) |
| 00:39:53 | × | fendor[m] quits (~fendormat@2001:470:69fc:105::fcbd) (Ping timeout: 256 seconds) |
| 00:41:22 | × | Benzi-Junior quits (~BenziJuni@88-149-64-179.du.xdsl.is) (Ping timeout: 246 seconds) |
| 00:42:30 | → | Benzi-Junior joins (~BenziJuni@dsl-149-64-179.hive.is) |
| 00:42:49 | → | comerijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 00:43:28 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
| 00:47:24 | × | Benzi-Junior quits (~BenziJuni@dsl-149-64-179.hive.is) (Ping timeout: 240 seconds) |
| 00:47:51 | × | shailangsa_ quits (~shailangs@host86-186-127-233.range86-186.btcentralplus.com) () |
| 00:47:57 | → | jmcarthur joins (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) |
| 00:53:36 | × | sagax quits (~sagax_nb@user/sagax) (Remote host closed the connection) |
| 01:03:45 | → | vicfred joins (~vicfred@user/vicfred) |
| 01:06:46 | → | frost joins (~frost@user/frost) |
| 01:08:26 | → | RajatVerma[m] joins (~rajatvmat@2001:470:69fc:105::1:fb34) |
| 01:10:33 | → | VarikValefor[m] joins (~varikvale@2001:470:69fc:105::a5d) |
| 01:10:50 | × | mtjm quits (~mutantmel@2604:a880:2:d0::208b:d001) (Remote host closed the connection) |
| 01:10:51 | × | albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 01:11:36 | → | amesgen[m] joins (~amesgenm]@2001:470:69fc:105::82b) |
| 01:11:37 | → | lyiriyah[m] joins (~lyiriyahm@2001:470:69fc:105::cc0) |
| 01:11:56 | → | mtjm joins (~mutantmel@2604:a880:2:d0::208b:d001) |
| 01:12:19 | → | sm joins (~sm@plaintextaccounting/sm) |
| 01:12:30 | × | alp_ quits (~alp@user/alp) (Ping timeout: 260 seconds) |
| 01:13:14 | → | jinsun_ joins (~jinsun@user/jinsun) |
| 01:13:17 | → | DemiMarieObenour joins (~alwayscur@2001:470:69fc:105::4886) |
| 01:13:51 | → | jmcantrell joins (~jmcantrel@user/jmcantrell) |
| 01:14:01 | → | yoggurt[m] joins (~yoggurtma@2001:470:69fc:105::2:ba5) |
| 01:15:02 | → | juhp[m] joins (~juhpmatri@2001:470:69fc:105::6e9) |
| 01:15:08 | → | vaibhavsagar[m] joins (~vaibhavsa@2001:470:69fc:105::ffe) |
| 01:15:10 | → | maralorn joins (~maralorn@2001:470:69fc:105::251) |
| 01:15:57 | → | fgaz joins (~fgaz@2001:470:69fc:105::842) |
| 01:16:47 | → | kadoban joins (~kadoban@user/kadoban) |
| 01:16:58 | → | albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 01:17:17 | → | Ash[m] joins (~signal-wa@2001:470:69fc:105::1:2318) |
| 01:17:23 | → | vestige[m] joins (~vestigema@2001:470:69fc:105::1:f9dd) |
| 01:17:26 | → | ManofLetters[m] joins (~manoflett@2001:470:69fc:105::3be) |
| 01:18:58 | → | xff0x joins (~xff0x@125x102x200x106.ap125.ftth.ucom.ne.jp) |
| 01:19:51 | → | Guillaum[m] joins (~guiboumat@2001:470:69fc:105::1:72ac) |
| 01:20:35 | → | inversed_ joins (~inversed@176.248.27.211) |
| 01:20:35 | × | ubert1 quits (~Thunderbi@p200300ecdf158806117918b760ecf219.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 01:20:47 | × | inversed quits (~inversed@176.248.27.211) (Ping timeout: 256 seconds) |
| 01:21:42 | → | psydroid joins (~psydroid@user/psydroid) |
| 01:22:14 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 01:22:21 | → | Orbstheorem joins (~orbstheor@2001:470:69fc:105::a56) |
| 01:22:44 | × | dextaa49 quits (~dextaa@user/dextaa) (Remote host closed the connection) |
| 01:22:57 | → | cdsmith joins (~cdsmithma@2001:470:69fc:105::284) |
| 01:26:23 | → | noiobeforebed joins (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 01:26:32 | → | yosef36 joins (~yosefweis@2001:470:69fc:105::1:e501) |
| 01:27:55 | → | geekosaur[m][m] joins (~geekosaur@2001:470:69fc:105::2:cb7) |
| 01:28:02 | → | reza[m] joins (~rezaphone@2001:470:69fc:105::3eda) |
| 01:28:39 | × | son0p quits (~ff@181.136.122.143) (Ping timeout: 240 seconds) |
| 01:29:17 | → | shailangsa joins (~shailangs@host86-186-127-233.range86-186.btcentralplus.com) |
| 01:29:50 | → | sekun[m] joins (~hsekmatri@2001:470:69fc:105::d18f) |
| 01:30:16 | → | ishaan[m] joins (~ishaanvma@2001:470:69fc:105::1:fb72) |
| 01:31:21 | → | rekahsoft joins (~rekahsoft@bras-base-wdston4533w-grc-02-142-113-160-8.dsl.bell.ca) |
| 01:32:42 | → | ArshiaAghaei[m] joins (~arshiaagh@2001:470:69fc:105::1:c382) |
| 01:32:42 | → | hughjfchen[m] joins (~hughjfche@2001:470:69fc:105::c29d) |
| 01:32:59 | → | sagax joins (~sagax_nb@user/sagax) |
| 01:33:17 | → | boxscape joins (~boxscape@user/boxscape) |
| 01:33:56 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 01:35:01 | → | Matthew|m joins (~arathorn@2001:470:69fc:105::1f) |
| 01:35:12 | → | AdityaAlok[m] joins (~mradityaa@2001:470:69fc:105::1:ee36) |
| 01:35:29 | → | Christoph[m] joins (~hpotsirhc@2001:470:69fc:105::2ff8) |
| 01:37:35 | → | Bulby[m] joins (~bulbyvrma@2001:470:69fc:105::1:fe0a) |
| 01:38:11 | × | nate1 quits (~nate@98.45.169.16) (Ping timeout: 252 seconds) |
| 01:38:21 | × | codaraxis quits (~codaraxis@user/codaraxis) (Ping timeout: 256 seconds) |
| 01:38:21 | → | schuelermine[m] joins (~schuelerm@user/schuelermine) |
| 01:38:56 | → | Andy[m] joins (~anparrama@2001:470:69fc:105::1:6826) |
| 01:39:03 | → | alexfmpe[m] joins (~alexfmpem@2001:470:69fc:105::38ba) |
| 01:39:21 | → | ericson2314 joins (~ericson23@2001:470:69fc:105::70c) |
| 01:40:02 | → | jneira[m] joins (~jneiramat@2001:470:69fc:105::d729) |
| 01:40:09 | → | ormaaj joins (~ormaaj@user/ormaaj) |
| 01:40:19 | → | sjanssen joins (~sjanssenm@2001:470:69fc:105::1:61d8) |
| 01:40:36 | → | ozataman[m] joins (~ozatamanm@2001:470:69fc:105::1:faa0) |
| 01:44:21 | → | Inst[m] joins (~instrmatr@2001:470:69fc:105::1:903e) |
| 01:44:22 | → | Artem[m] joins (~artemtype@2001:470:69fc:105::75b) |
| 01:46:55 | <monochrom> | Late to the conversation, but indeed a forall in a negative position is usually inside parentheses, too. Perfect. |
| 01:47:11 | × | feliix42 quits (~felix@gibbs.uberspace.de) (Quit: ZNC 1.8.2 - https://znc.in) |
| 01:47:25 | → | feliix42 joins (~felix@gibbs.uberspace.de) |
| 01:48:07 | × | noiobeforebed quits (~noiobefor@2001:470:69fc:105::1:3c2d) (Ping timeout: 250 seconds) |
| 01:48:08 | × | Orbstheorem quits (~orbstheor@2001:470:69fc:105::a56) (Ping timeout: 250 seconds) |
| 01:48:08 | × | lyiriyah[m] quits (~lyiriyahm@2001:470:69fc:105::cc0) (Ping timeout: 250 seconds) |
| 01:48:08 | × | amesgen[m] quits (~amesgenm]@2001:470:69fc:105::82b) (Ping timeout: 250 seconds) |
| 01:48:24 | × | reza[m] quits (~rezaphone@2001:470:69fc:105::3eda) (Ping timeout: 250 seconds) |
| 01:48:25 | × | kadoban quits (~kadoban@user/kadoban) (Ping timeout: 250 seconds) |
| 01:48:37 | × | Inst[m] quits (~instrmatr@2001:470:69fc:105::1:903e) (Ping timeout: 240 seconds) |
| 01:48:38 | × | ishaan[m] quits (~ishaanvma@2001:470:69fc:105::1:fb72) (Ping timeout: 240 seconds) |
| 01:48:46 | → | Deide joins (~deide@user/deide) |
| 01:49:22 | → | fendor[m] joins (~fendormat@2001:470:69fc:105::fcbd) |
| 01:49:46 | → | Frikraaa[m] joins (~odirfjohr@2001:470:69fc:105::1:f483) |
| 01:49:49 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 01:50:53 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 01:51:19 | × | jao quits (~mail@cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net) (Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)) |
| 01:52:14 | → | ongy[m] joins (~ongymatri@2001:470:69fc:105::5018) |
| 01:53:28 | × | slac91684 quits (~slack1256@186.11.61.142) (Ping timeout: 246 seconds) |
| 01:53:33 | → | moats joins (~oats@user/oats) |
| 01:54:07 | → | Pikachu[m] joins (~pychaumat@2001:470:69fc:105::2:1ce) |
| 01:55:30 | → | andrey__ joins (~andrey@p200300dbcf15e00051e3a882b5958800.dip0.t-ipconnect.de) |
| 01:55:41 | → | zfnmxt joins (~zfnmxtzfn@2001:470:69fc:105::2b32) |
| 01:55:47 | → | peddie joins (~peddie@2001:470:69fc:105::25d) |
| 01:56:14 | → | siraben joins (~siraben@user/siraben) |
| 01:56:15 | → | smichel17[m] joins (~smichel17@2001:470:69fc:105::2d32) |
| 01:57:48 | × | andrey_ quits (~andrey@p200300dbcf0a9400bb18378afbd4165e.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 01:57:49 | → | sibnull[m] joins (~sibnullma@2001:470:69fc:105::1:1291) |
| 01:58:11 | → | abastro[m] joins (~abastroma@2001:470:69fc:105::1:e119) |
| 01:58:25 | → | bahamas joins (~lucian@84.232.141.55) |
| 01:58:33 | → | Las[m] joins (~lasmatrix@2001:470:69fc:105::74e) |
| 01:59:05 | → | rsify joins (~rsify@2001:470:69fc:105::1:fd44) |
| 01:59:46 | → | shlevy[m] joins (~shlevymat@2001:470:69fc:105::1:d3b1) |
| 02:01:12 | → | dyniec[m] joins (~dyniecmat@2001:470:69fc:105::2:a85) |
| 02:01:53 | → | pareto-optimal-d joins (~pareto-op@2001:470:69fc:105::1:b61f) |
| 02:02:39 | → | maerwald[m] joins (~maerwaldm@2001:470:69fc:105::1ee) |
| 02:04:23 | <energizer> | is there a good document that says what 'composition' means? |
| 02:04:25 | × | bahamas quits (~lucian@84.232.141.55) (Ping timeout: 256 seconds) |
| 02:05:00 | → | SridharRatnakuma joins (~sridmatri@2001:470:69fc:105::1c2) |
| 02:05:12 | → | oak- joins (~oakuniver@2001:470:69fc:105::fcd) |
| 02:05:18 | <Axman6> | it means whatever you want it to mean when you use it. I composed my lunch with myself using the `eat` function |
| 02:06:14 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Ping timeout: 252 seconds) |
| 02:06:20 | <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" |
| 02:06:30 | → | july541[m] joins (~july541ma@2001:470:69fc:105::1:e416) |
| 02:06:31 | <Axman6> | composition too* |
| 02:06:35 | <EvanR> | the cat class has a meow method, so you can compose cat with meow, to get... IO? |
| 02:07:08 | → | Tisoxin joins (~ikosit@user/ikosit) |
| 02:07:30 | <Axman6> | so, we can compose functions to get more functions |
| 02:07:49 | <Axman6> | we can compose monadic actions to get new monadic actions |
| 02:08:14 | → | Yehoshua joins (~yehoshua@2001:470:69fc:105::1:593f) |
| 02:08:18 | <EvanR> | lego bricks of the appropriate type combine to form a bigger lego |
| 02:08:35 | <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. |
| 02:09:03 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 02:09:03 | → | finn_elija joins (~finn_elij@user/finn-elija/x-0085643) |
| 02:09:03 | finn_elija | is now known as FinnElija |
| 02:09:11 | <energizer> | that "more nuanced level" sounds like it means "denotational semantics" |
| 02:09:26 | <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 |
| 02:09:46 | <monochrom> | Yes that's one purpose of denotational semantics. |
| 02:10:12 | <energizer> | EvanR: that's the `f a a -> a` signature that Axman6 was talking about |
| 02:10:30 | → | Inst[m] joins (~instrmatr@2001:470:69fc:105::1:903e) |
| 02:10:41 | EvanR | scrolls up |
| 02:10:58 | <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" |
| 02:11:55 | <energizer> | which i'd usually use the word "closed" for |
| 02:12:11 | <EvanR> | has types at all really covers a lot of that ground |
| 02:12:13 | <energizer> | as in 'a is closed under f |
| 02:13:27 | <EvanR> | a binary f algebra, or something |
| 02:13:46 | → | Orbstheorem joins (~orbstheor@2001:470:69fc:105::a56) |
| 02:13:48 | <EvanR> | actually why are there two parameters |
| 02:13:57 | <EvanR> | f a -> a |
| 02:14:13 | → | amesgen[m] joins (~amesgenm]@2001:470:69fc:105::82b) |
| 02:14:52 | <EvanR> | note this doesn't cover the form for function composition |
| 02:16:16 | → | lyiriyah[m] joins (~lyiriyahm@2001:470:69fc:105::cc0) |
| 02:16:50 | → | noiobeforebed joins (~noiobefor@2001:470:69fc:105::1:3c2d) |
| 02:17:10 | → | nate1 joins (~nate@98.45.169.16) |
| 02:19:01 | → | kadoban joins (~kadoban@user/kadoban) |
| 02:20:24 | → | reza[m] joins (~rezaphone@2001:470:69fc:105::3eda) |
| 02:21:22 | → | ishaan[m] joins (~ishaanvma@2001:470:69fc:105::1:fb72) |
| 02:28:13 | × | gurkenglas quits (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Ping timeout: 256 seconds) |
| 02:29:35 | × | jmcarthur quits (~jmcarthur@c-73-29-224-10.hsd1.nj.comcast.net) (Quit: My MacBook Air has gone to sleep. ZZZzzz…) |
| 02:30:50 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 02:33:10 | × | EvanR quits (~EvanR@user/evanr) (Remote host closed the connection) |
| 02:33:44 | → | EvanR joins (~EvanR@user/evanr) |
| 02:33:54 | → | EvanR_ joins (~EvanR@user/evanr) |
| 02:33:56 | × | EvanR quits (~EvanR@user/evanr) (Remote host closed the connection) |
| 02:34:47 | × | EvanR_ quits (~EvanR@user/evanr) (Remote host closed the connection) |
| 02:35:28 | → | EvanR joins (~EvanR@user/evanr) |
| 02:43:30 | × | Kaipei quits (~Kaiepi@156.34.47.253) (Ping timeout: 240 seconds) |
| 02:44:52 | × | waleee quits (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) (Ping timeout: 248 seconds) |
| 02:45:05 | <Axman6> | anyone know what the state of Haskell -. WebAssembly is at the moment? |
| 02:47:47 | <geekosaur> | best asked in #ghc, but work is ongoing and last I heard was still targeting 9.6 |
| 02:48:22 | → | steven joins (~steven@2600:1700:ce00:1ca0:679b:14af:bf5c:9d0d) |
| 02:48:49 | <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 |
| 02:49:19 | <Axman6> | it'd be fantastic if GHC proper shipped with WASM support, would be great to see it as a first class target |
| 02:49:41 | → | jargon joins (~jargon@174-22-206-112.phnx.qwest.net) |
| 02:50:05 | <geekosaur> | milestone for 9.6 indeed shows wasm |
| 02:50:13 | <Axman6> | D: |
| 02:51:05 | <Axman6> | I didn't realise its development was that closely tied to GHC's development, that's great news |
| 02:51:19 | <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 |
| 02:51:20 | <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? |
| 02:51:24 | <geekosaur> | https://gitlab.haskell.org/ghc/ghc/-/milestones/375 fwiw |
| 02:52:13 | <Axman6> | steven: my first thought is to use CPP to define those instances when mtl is in a version range where they exist |
| 02:53:47 | <c_wraith> | ugh. that just ruins the docs. |
| 02:54:21 | <c_wraith> | instances that only exist sometimes really are annoying. |
| 02:54:43 | <steven> | ah yes that's an option too |
| 02:55:21 | <steven> | but I wonder if it can result in explosion? e.g. over time the project could accumulate lots of checks for different versions |
| 02:55:22 | <c_wraith> | please have the existence of an instance vary based on package version rather than a build-time check of some sort. |
| 02:55:55 | <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 |
| 02:56:23 | <c_wraith> | It's a rare situation. Instances don't usually go away after having been around for decades. |
| 02:56:25 | <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 |
| 02:58:17 | <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 |
| 03:07:08 | → | azimut_ joins (~azimut@gateway/tor-sasl/azimut) |
| 03:08:04 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 03:10:52 | → | bahamas joins (~lucian@84.232.141.55) |
| 03:12:34 | → | erenyaegerdidnot joins (~erenyaege@2600:1700:4010:55c0::1f) |
| 03:13:46 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 03:15:48 | × | erenyaegerdidnot quits (~erenyaege@2600:1700:4010:55c0::1f) (Client Quit) |
| 03:15:49 | × | bahamas quits (~lucian@84.232.141.55) (Ping timeout: 256 seconds) |
| 03:17:24 | → | searemind joins (~u0_a2219@122.161.48.197) |
| 03:18:22 | × | searemind quits (~u0_a2219@122.161.48.197) (Client Quit) |
| 03:20:21 | <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 |
| 03:46:10 | × | nate1 quits (~nate@98.45.169.16) (Ping timeout: 240 seconds) |
| 03:47:40 | <steven> | interesting, thank you sm. I can at least see how they're doing it |
| 03:56:40 | → | akurilin_ joins (uid322841@id-322841.ilkley.irccloud.com) |
| 03:58:21 | × | zaquest quits (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 03:59:35 | → | zaquest joins (~notzaques@5.130.79.72) |
| 03:59:59 | → | dsrt^ joins (~dsrt@128-092-160-234.biz.spectrum.com) |
| 04:05:57 | → | odnes joins (~odnes@5-203-212-41.pat.nym.cosmote.net) |
| 04:05:58 | <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 |
| 04:05:59 | <steven> | think this is a minor upgrade but want to make sure this makes sense |
| 04:06:28 | → | Kaipei joins (~Kaiepi@156.34.47.253) |
| 04:06:29 | <steven> | correction: only if the class* is not there (not class instance) |
| 04:06:52 | × | jargon quits (~jargon@174-22-206-112.phnx.qwest.net) (Remote host closed the connection) |
| 04:08:10 | × | kaph quits (~kaph@net-2-42-128-205.cust.vodafonedsl.it) (Ping timeout: 240 seconds) |
| 04:11:15 | × | shriekingnoise quits (~shrieking@201.231.16.156) (Ping timeout: 276 seconds) |
| 04:16:50 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 04:30:45 | × | rekahsoft quits (~rekahsoft@bras-base-wdston4533w-grc-02-142-113-160-8.dsl.bell.ca) (Ping timeout: 276 seconds) |
| 04:30:47 | → | takuan joins (~takuan@178-116-218-225.access.telenet.be) |
| 04:32:55 | → | benin joins (~benin@183.82.31.174) |
| 04:35:33 | <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 |
| 04:51:54 | × | [itchyjunk] quits (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 04:54:22 | → | shriekingnoise joins (~shrieking@201.231.16.156) |
| 04:56:39 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 04:58:36 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 05:00:06 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 05:01:01 | → | coot joins (~coot@213.134.190.95) |
| 05:04:22 | × | Vajb quits (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 05:05:11 | → | Vajb joins (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) |
| 05:09:02 | <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` |
| 05:12:35 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 05:13:30 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 05:13:42 | × | steven quits (~steven@2600:1700:ce00:1ca0:679b:14af:bf5c:9d0d) (Ping timeout: 252 seconds) |
| 05:18:05 | × | raym quits (~raym@user/raym) (Quit: kernel update, rebooting...) |
| 05:18:10 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 05:21:40 | → | raym joins (~raym@user/raym) |
| 05:24:04 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 05:28:40 | × | jpds quits (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 05:29:03 | → | jpds joins (~jpds@gateway/tor-sasl/jpds) |
| 05:35:16 | → | zeenk joins (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) |
| 05:36:11 | × | zeenk quits (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Read error: Connection reset by peer) |
| 05:36:24 | → | zeenk joins (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) |
| 05:49:06 | × | ryanbooker quits (uid4340@id-4340.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 05:52:39 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 05:53:36 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 05:57:53 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 05:59:32 | → | Guest39 joins (~Guest39@50-204-42-240-static.hfc.comcastbusiness.net) |
| 06:04:50 | × | Guest39 quits (~Guest39@50-204-42-240-static.hfc.comcastbusiness.net) (Quit: Client closed) |
| 06:07:13 | × | m1dnight quits (~christoph@78-22-9-5.access.telenet.be) (Read error: Connection reset by peer) |
| 06:07:42 | → | m1dnight joins (~christoph@78-22-9-5.access.telenet.be) |
| 06:10:25 | × | echoreply quits (~echoreply@45.32.163.16) (Quit: WeeChat 2.8) |
| 06:11:17 | → | echoreply joins (~echoreply@45.32.163.16) |
| 06:13:35 | × | EvanR quits (~EvanR@user/evanr) (Ping timeout: 260 seconds) |
| 06:16:00 | → | mikoto-chan joins (~mikoto-ch@84.199.144.234) |
| 06:16:37 | → | EvanR joins (~EvanR@user/evanr) |
| 06:17:09 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 06:19:38 | → | EvanR_ joins (~EvanR@user/evanr) |
| 06:22:27 | × | EvanR quits (~EvanR@user/evanr) (Ping timeout: 260 seconds) |
| 06:25:37 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 06:28:22 | → | alp_ joins (~alp@user/alp) |
| 06:30:31 | × | xkuru quits (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 06:32:20 | → | adanwan_ joins (~adanwan@gateway/tor-sasl/adanwan) |
| 06:32:37 | <lechner> | Hi, a lot of folks here work with Nix. Is anyone using Guix? |
| 06:33:00 | → | acidjnk_new joins (~acidjnk@p200300d0c7068b99195ba74fc017953f.dip0.t-ipconnect.de) |
| 06:33:34 | × | adanwan quits (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 240 seconds) |
| 06:35:50 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Ping timeout: 240 seconds) |
| 06:38:48 | × | Ram-Z quits (~Ram-Z@li1814-254.members.linode.com) (Ping timeout: 276 seconds) |
| 06:43:55 | <tomsmeding> | [exa]: I feel like the issue in your second paste is that you're not lifting the withRunInIO into m |
| 06:46:39 | <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#readCreateProcessWithExitCode it seems the code will block on reading stderr/stdout first, and then waitForProcess |
| 06:46:47 | <dminuoso> | Is this the correct methodology? |
| 06:47:12 | <dminuoso> | Or rather, when the running process exits, is it guaranteed it will close its fds 0, 1 and 2? |
| 06:48:03 | <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 |
| 06:49:25 | <[exa]> | tomsmeding: yeah I found it later, lift is the new teleport :D |
| 06:49:35 | → | nschoe joins (~quassel@178.251.84.79) |
| 06:49:37 | <[exa]> | thanks for help though, it really required a bit of rubberducking :] |
| 06:49:44 | <tomsmeding> | boo I just wrote it too https://paste.tomsmeding.com/2isbwy2Z |
| 06:50:03 | <[exa]> | tomsmeding: I send back some positive energy |
| 06:50:06 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 06:50:09 | <tomsmeding> | :D |
| 06:51:54 | <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 |
| 06:52:21 | <[exa]> | dminuoso: unixy exit() must close all open FDs |
| 06:52:47 | <[exa]> | dminuoso: unless the process is terminated, at which point you might be getting sigpipes etc |
| 06:53:38 | → | slack1256 joins (~slack1256@186.11.58.142) |
| 06:54:06 | <[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" |
| 06:54:09 | <tomsmeding> | dminuoso: that one seems to wait on output and on waitForProcess in parallel |
| 06:54:11 | <dminuoso> | Ahh hold on, the difference in `readProcess` is that it just defers the out reader to lazy hGetContents |
| 06:54:23 | <dminuoso> | Its still the same |
| 06:54:33 | <dminuoso> | Its just slightly less obvious |
| 06:54:38 | <tomsmeding> | no it waits on them in parallel |
| 06:54:49 | <tomsmeding> | it waits on the output in a forked thread, and waits on the process in the main thread |
| 06:55:09 | <tomsmeding> | whereas the process-extras link you sent earlier waits on the output _before_ waiting on the process |
| 06:55:12 | <dminuoso> | https://hackage.haskell.org/package/process-1.6.14.0/docs/src/System.Process.html#readCreateProcessWithExitCode |
| 06:55:35 | <dminuoso> | Well yeah we should be comparing it with that I suppose |
| 06:55:38 | <tomsmeding> | though the 'process' version does kind of implicitly assume that 'output' has been forced at the time the process exits :p |
| 06:55:50 | <tomsmeding> | same structure, just with stderr in |
| 06:55:52 | <dminuoso> | tomsmeding: Right, so Im wondering whether the order to wait in is irrelevant here |
| 06:56:10 | → | dextaa490 joins (~dextaa@user/dextaa) |
| 06: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 |
| 06:56:27 | <tomsmeding> | because otherwise buffer full |
| 06:56:45 | <tomsmeding> | personally I'd wait on both events in parallel, but not sure whether that's necessary |
| 06:56:50 | <dminuoso> | Okay that makes sense, so I must at least start reading stdout before waiting, but it shouldnt matter what to *wait* on right? |
| 06:57:16 | <dminuoso> | Should really look at POSIX specifications for pipes here |
| 06:57:16 | <tomsmeding> | I would say that's correct |
| 06:57:21 | <tomsmeding> | yeah :') |
| 06:57:45 | × | Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 06:58:12 | → | superbil joins (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 06:58:20 | <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 |
| 06:58:36 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 06:59:21 | × | superbil quits (~superbil@1-34-176-171.hinet-ip.hinet.net) (Client Quit) |
| 06:59:29 | <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 |
| 06:59:55 | → | superbil joins (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 07:00:21 | <dminuoso> | tomsmeding: that somewhat suggests I should start reading from stdout even before the process is created. |
| 07:00:32 | <tomsmeding> | what's "that"? |
| 07:01:12 | <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 |
| 07:01:23 | <tomsmeding> | nice irc window copy |
| 07:01:29 | <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 |
| 07:01:33 | <dminuoso> | Heh. |
| 07:01:40 | <tomsmeding> | nobody cares about that, right? |
| 07:01:40 | <dminuoso> | New weechat layout, still sorting things out |
| 07:01:55 | <dminuoso> | What do you mean by nobody cares about that? |
| 07:01:59 | <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 |
| 07:02:13 | <tomsmeding> | is it relevant that the process stalled for a very short time |
| 07:02:27 | <dminuoso> | That would depend on whether the writing process handles this correctly |
| 07:02:54 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 07:02:59 | <dminuoso> | If say non-blocking write on stdout was used, without the assumption that it could fail |
| 07:03:12 | <tomsmeding> | then the program is ill-written lol |
| 07:03:16 | <tomsmeding> | non-blocking write _can_ fail |
| 07:03:21 | <dminuoso> | I guess |
| 07:03:36 | <tomsmeding> | you should assume it to fail, that's the whole point of the non-blocking API |
| 07:03:41 | <tomsmeding> | if you wanted non-failure, use the blocking API |
| 07:04:14 | <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 |
| 07:04:21 | <tomsmeding> | then the writes _will_ fill up the buffer and _will_ fail |
| 07:04:29 | → | chele joins (~chele@user/chele) |
| 07:05:34 | <tomsmeding> | dminuoso: re weechat, try alt-L |
| 07:06:28 | <dminuoso> | Ah nice, I did not know this key combination |
| 07:06:29 | <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 |
| 07:06:38 | <dminuoso> | That's very useful |
| 07:06:47 | <tomsmeding> | so the situation you were worrying about can happen anyway, even if you read as soon as possible |
| 07:07:03 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.or.comcast.net) (Quit: zzz) |
| 07:07:20 | <tomsmeding> | dminuoso: in alt-L mode weechat exits the alternate-screen I think, so it's actual wrapping text that copies nicely |
| 07:07:23 | dminuoso | just wants to do image manipulation with imagemagick |
| 07:07:41 | <[exa]> | y u no juicypixels |
| 07:07:46 | <tomsmeding> | your client program is imagemagick? That handles writes correctly, it's too famous a program |
| 07:07:49 | <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 |
| 07:07:59 | <[exa]> | also, tmpfiles rock |
| 07:08:05 | <dminuoso> | [exa]: it doesnt do all the operations I want it to do |
| 07:08:12 | × | cawfee quits (~root@2406:3003:2077:2758::babe) (Ping timeout: 260 seconds) |
| 07:08:34 | <[exa]> | dminuoso: btw what about using it as a library? https://hackage.haskell.org/package/imagemagick |
| 07:08:56 | <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 |
| 07:08:59 | <dminuoso> | [exa]: Not been maintained for 7 years, will only build against old versions of it |
| 07:09:17 | <dminuoso> | tomsmeding: No, its actually just me writing elgato streamdeck drivers and tools! |
| 07:09:23 | → | cawfee joins (~root@2406:3003:2077:2758::babe) |
| 07:09:26 | <dminuoso> | It's for a jukebox for my kid. :> |
| 07:09:31 | <[exa]> | dminuoso: ah so ,_, |
| 07:09:35 | <tomsmeding> | I guess that _is_ mission critical |
| 07:10:00 | <dminuoso> | tomsmeding: I strike to not take shortcuts even for hobby projects. I see them as practice for writing correct and stable software. |
| 07:10:12 | <dminuoso> | *strive even |
| 07:10:52 | <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... |
| 07:11:00 | <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 |
| 07:11:26 | <[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 |
| 07:11:39 | <dminuoso> | [exa]: No no! Performance! |
| 07:11:50 | → | christiansen joins (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) |
| 07:12:04 | <[exa]> | dminuoso: mmap() >>> malloc() |
| 07:12:07 | <dminuoso> | heh |
| 07:12:21 | <[exa]> | anyway I'll need this too |
| 07:12:29 | <[exa]> | let's try some c2hs |
| 07:12:44 | <dminuoso> | [exa]: Im not willing to maintain this for years to come. |
| 07:13:02 | <dminuoso> | Throwing binary bindings on hackage you know will be outdated a year from now is irresponsible. |
| 07:13:25 | <[exa]> | I'd then assume throwing any binary bindings there is irresponsible? :D |
| 07:13:59 | <dminuoso> | Well some are maintained, or work with very stable APIs that dont need much changing |
| 07:14:21 | <dminuoso> | Besides, imagemagick is a very dangerous proposition to use for production software |
| 07:14:35 | <dminuoso> | The kind of attack vectors this enables is crazy |
| 07:15:13 | <[exa]> | yap |
| 07:15:26 | <[exa]> | what's the extra transform you need that juicypixels don't do? |
| 07:15:57 | <[exa]> | s/juicypixels/friday/ |
| 07:16:43 | <dminuoso> | extending canvas with transparent background |
| 07:16:55 | <dminuoso> | I want to generate key icons for the pressed state that become smaller |
| 07:17:13 | × | mikoto-chan quits (~mikoto-ch@84.199.144.234) (Ping timeout: 246 seconds) |
| 07:17:22 | <dminuoso> | So I would resize (which I could do with JuicyPixels-extras), and extend canvas - I havent found a way to do the latter. |
| 07:17:51 | <dminuoso> | Also the bitmap portions dont let me pick arbitrary headers |
| 07:17:52 | <[exa]> | you make a bigger image and blit the original in the middle? |
| 07:17:55 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Read error: Connection reset by peer) |
| 07:18:01 | <dminuoso> | The streamdecks require a particular BMP header format that juicy pixels can only parse, but not generate |
| 07:18:18 | <dminuoso> | (well the older models) |
| 07:18:51 | <dminuoso> | I could probably work around *that* one by poking around in the header myself, but the extend canvas onto transparent background I cant |
| 07:19:14 | → | Ram-Z joins (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 07:21:14 | <tomsmeding> | does BMP even support transparency |
| 07:21:18 | <[exa]> | re borders, what about `generateImage (\x y -> if inbounds x y then takefromthepicture else transparent) ? |
| 07:21:23 | <[exa]> | tomsmeding: yeah they support RGBA |
| 07:21:36 | <tomsmeding> | TIL |
| 07:21:39 | <[exa]> | with similar level of standardization as other formats there :D |
| 07:21:44 | <tomsmeding> | lol |
| 07:21:59 | <[exa]> | s/formats/bmp formats/ |
| 07:22:05 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) |
| 07:22:26 | <[exa]> | I still get triggered when remembering the bmp palettes |
| 07:22:37 | <dminuoso> | [exa]: Mmmm, maybe I really should look at JuicyPixels. |
| 07:23:30 | × | Midjak quits (~Midjak@82.66.147.146) (Ping timeout: 260 seconds) |
| 07:23:38 | <[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 |
| 07:23:44 | <[exa]> | ^ opinionated truth |
| 07:24:03 | <tomsmeding> | what is an opinionated truth |
| 07:24:14 | <dminuoso> | All truth is opinionated. |
| 07:24:26 | × | Sgeo quits (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 07:24:29 | → | mikoto-chan joins (~mikoto-ch@213.177.151.239) |
| 07:24:44 | <[exa]> | tomsmeding: that's specified in IRC RFC no? :D |
| 07:25:32 | <tomsmeding> | [exa]: /me confused |
| 07:26:36 | <[exa]> | btw RGBA BMP is even exampled by wiki it seems https://en.wikipedia.org/wiki/BMP_file_format#Example_2 |
| 07:27:01 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 07:27:03 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 07:27:07 | <dminuoso> | [exa]: I mean the performance doing this in JuicyPixels will likely be much worse. :( |
| 07:27:41 | <dminuoso> | With imagemagick I get opencl with SIMD and all that sorcery |
| 07:27:48 | <[exa]> | juicypixels-repa? |
| 07:27:49 | <dminuoso> | But honestly, performance is not a constraint. |
| 07:27:58 | <tomsmeding> | "I want to generate key icons" |
| 07:28:04 | <[exa]> | (or maybe the package name is the other way around) |
| 07:28:05 | <dminuoso> | :> |
| 07:28:16 | <dminuoso> | tomsmeding: Not just a few, 32 of them! |
| 07:28:32 | <tomsmeding> | I bet IM doesn't parallelise across images |
| 07:28:45 | <dminuoso> | No, but you can simply invoke multiple IM processes on parallel! |
| 07:28:57 | <tomsmeding> | how large are these images |
| 07:29:11 | <dminuoso> | I gotta scale them down from 150x150ish to 96x96 or 72x72! |
| 07:29:15 | <tomsmeding> | [exa]: ah |
| 07:29:30 | <tomsmeding> | dminuoso: invoking the process will be more expensive than resizing the f*n image lol |
| 07:29:44 | <dminuoso> | heh |
| 07:29:59 | <tomsmeding> | [exa]: that 'little-endian "Win "' though |
| 07:30:06 | <dminuoso> | I hope you do realize Im being a bit humorous about performance |
| 07:30:11 | [exa] | remembers the negligible negligibility of opencl initialization time |
| 07:30:14 | <tomsmeding> | :) |
| 07:30:28 | <tomsmeding> | I do |
| 07:30:38 | <[exa]> | tomsmeding: yeah all the easter eggs from M$ are cursed af |
| 07:31:31 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 07:31:55 | × | mrmonday quits (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Quit: No Ping reply in 180 seconds.) |
| 07:32:11 | <dminuoso> | [exa]: mmm now if JuicyPixels-repa could give me an unboxed vector of pixel data. |
| 07:32:31 | × | mikoto-chan quits (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 07:32:32 | <dminuoso> | If Im using generateImage, I want maximum localicy of reference to scan the source image |
| 07:32:49 | <[exa]> | dminuoso: repa is good |
| 07:33:11 | <dminuoso> | Ah but wait, is Array D DIM3 Word8 |
| 07:33:15 | → | mrmonday joins (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 07:33:18 | <dminuoso> | Whatever that means |
| 07:33:22 | <[exa]> | that's okay |
| 07:33:34 | <tomsmeding> | delayed array of dimension 3 containing Word8 values |
| 07:33:36 | <[exa]> | delayed 3D array of bytes, precisely what you want |
| 07:33:44 | tomsmeding | high-5's [exa] |
| 07:33:52 | <dminuoso> | delayed-what-now? |
| 07:33:55 | <[exa]> | then you undelay it and it computes itself very efficiently |
| 07:34:06 | <tomsmeding> | delayed being it's ((Int,Int,Int) -> Word8) |
| 07:34:19 | <tomsmeding> | manifest would be (Vector Word8) |
| 07:34:20 | <[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 |
| 07:34:25 | → | mikoto-chan joins (~mikoto-ch@213.177.151.239) |
| 07:35:18 | <dminuoso> | Does that mean operations on it occur in a special monad? |
| 07:35:29 | <[exa]> | no |
| 07:35:52 | <dminuoso> | Okay repa is completely news to me :) |
| 07:36:37 | <[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 |
| 07:37:01 | <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 |
| 07:37:05 | <dminuoso> | I dont think much is won |
| 07:37:16 | <[exa]> | and if you compile with LLVM you should actually get a bit of SIMD |
| 07:37:32 | <dminuoso> | I might get some cache benefit depending if the Image allocations on the heap are packed together though |
| 07:38:02 | <[exa]> | (...if you find a CPU with SIMD vectors smaller than the 32 key icons) |
| 07:38:46 | <[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 |
| 07:39:46 | <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)' |
| 07:39:51 | <[exa]> | *unboxed Vector |
| 07:40:24 | <dminuoso> | Well, I see that repa has this fairly cool shape polymorphic indexing. |
| 07:40:27 | × | dextaa490 quits (~dextaa@user/dextaa) (Remote host closed the connection) |
| 07:40:54 | <dminuoso> | Brilliant, so I dont even notice Im working with an unboxed, row-major array of rgba data |
| 07:41:25 | <[exa]> | yap repa is good |
| 07:42:01 | × | odnes quits (~odnes@5-203-212-41.pat.nym.cosmote.net) (Quit: Leaving) |
| 07:42:35 | <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". |
| 07:42:56 | <dminuoso> | Thanks [exa], came here for unix process advice and went out with repa. |
| 07:43:09 | <[exa]> | \o/ |
| 07:45:49 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 07:46:21 | → | xaotuk joins (~sasha@2a06:5b00:15fe:9b00::2) |
| 07:47:44 | → | machinedgod joins (~machinedg@24.105.81.50) |
| 07:50:45 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 07:50:46 | → | kuribas joins (~user@ip-188-118-57-242.reverse.destiny.be) |
| 07:52:35 | → | vpan joins (~0@212.117.1.172) |
| 07:52:56 | → | bahamas joins (~lucian@84.232.141.55) |
| 07:56:43 | × | slack1256 quits (~slack1256@186.11.58.142) (Ping timeout: 260 seconds) |
| 07:59:29 | → | cfricke joins (~cfricke@user/cfricke) |
| 08:01:21 | × | shriekingnoise quits (~shrieking@201.231.16.156) (Quit: Quit) |
| 08:03:47 | → | mattil joins (~mattil@helsinki.portalify.com) |
| 08:06:15 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 08:13:41 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 08:13:42 | × | christiansen quits (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) (Quit: christiansen) |
| 08:13:54 | → | christiansen joins (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) |
| 08:15:26 | comerijn | is now known as merijn |
| 08:15:59 | × | christiansen quits (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) (Read error: Connection reset by peer) |
| 08:16:15 | → | christiansen joins (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) |
| 08:16:39 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 08:20:12 | × | mattil quits (~mattil@helsinki.portalify.com) (Read error: Connection reset by peer) |
| 08:20:29 | × | xstill- quits (xstill@fimu/xstill) (Quit: Ping timeout (120 seconds)) |
| 08:21:31 | → | xstill- joins (xstill@fimu/xstill) |
| 08:26:54 | → | ccntrq joins (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) |
| 08:30:19 | × | bahamas quits (~lucian@84.232.141.55) (Ping timeout: 260 seconds) |
| 08:37:36 | <tomsmeding> | yay |
| 08:38:03 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 08:39:29 | × | phma quits (~phma@2001:5b0:211b:9668:1b71:5de:d62c:3d45) (Read error: Connection reset by peer) |
| 08:40:11 | → | phma joins (~phma@host-67-44-208-35.hnremote.net) |
| 08:41:51 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 08:50:13 | × | coot quits (~coot@213.134.190.95) (Quit: coot) |
| 08:50:27 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 08:51:33 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 08:55:59 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 08:57:04 | × | azimut_ quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 08:57:08 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 09:03:10 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 09:06:46 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 09:07:10 | → | king_gs joins (~Thunderbi@187.201.105.54) |
| 09:08:20 | → | dhil joins (~dhil@cpc103052-sgyl39-2-0-cust260.18-2.cable.virginm.net) |
| 09:10:58 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds) |
| 09:11:07 | → | CiaoSen joins (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 09:11:45 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 09:11:49 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 09:13:01 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 09:13:22 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 09:13:55 | → | odnes joins (~odnes@2a02:587:440e:0:e8c:b484:c50b:a76) |
| 09:14:16 | × | tubogram4 quits (~tubogram@user/tubogram) (Quit: See ya later!) |
| 09:14:30 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 09:15:47 | × | king_gs quits (~Thunderbi@187.201.105.54) (Quit: king_gs) |
| 09:17:39 | → | Benzi-Junior joins (~BenziJuni@88-149-64-179.du.xdsl.is) |
| 09:22:17 | → | tubogram4 joins (~tubogram@user/tubogram) |
| 09:30:00 | × | ccntrq quits (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) (Quit: ccntrq) |
| 09:34:54 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 09:35:33 | → | ccntrq joins (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) |
| 09:38:26 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) (Quit: WeeChat 2.8) |
| 09:38:40 | × | ccntrq quits (~Thunderbi@exit-1.rz.nue.de.mhd.medondo.com) (Client Quit) |
| 09:45:38 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Read error: Connection reset by peer) |
| 09:45:52 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 09:47:27 | → | mmhat joins (~mmh@2001:4090:a243:801d:ee08:6bff:fe09:5315) |
| 09:53:03 | → | MoC joins (~moc@user/moc) |
| 09:54:11 | × | ubert quits (~Thunderbi@p548c8d44.dip0.t-ipconnect.de) (Quit: ubert) |
| 09:55:47 | → | ubert joins (~Thunderbi@p200300ecdf15880b196df7e3ef276b09.dip0.t-ipconnect.de) |
| 09:56:52 | × | michalz quits (~michalz@185.246.204.126) (Ping timeout: 248 seconds) |
| 10:00:26 | × | econo quits (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 10:00:52 | → | michalz joins (~michalz@185.246.204.125) |
| 10:04:34 | × | azimut quits (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 10:09:16 | × | acidjnk_new quits (~acidjnk@p200300d0c7068b99195ba74fc017953f.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 10:09:41 | × | CiaoSen quits (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 10:14:21 | → | kjak joins (~kjak@pool-108-45-56-21.washdc.fios.verizon.net) |
| 10:14:58 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.5) |
| 10:16:23 | → | nishant joins (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) |
| 10:17:17 | ← | nishant parts (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) (Leaving) |
| 10:17:22 | → | nishant joins (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) |
| 10:17:30 | ← | nishant parts (~Nishant@2405:201:f005:c02f:1e85:5bce:e8d6:bf31) (Leaving) |
| 10:18:08 | × | xaotuk quits (~sasha@2a06:5b00:15fe:9b00::2) (Ping timeout: 260 seconds) |
| 10:19:55 | → | xaotuk joins (~sasha@net108-32-245-109.mbb.telenor.rs) |
| 10:24:22 | → | kaph joins (~kaph@net-2-42-128-205.cust.vodafonedsl.it) |
| 10:26:39 | → | gurkenglas joins (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) |
| 10:28:33 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 10:30:35 | × | haskl quits (~haskl@user/haskl) (Read error: Connection reset by peer) |
| 10:33:03 | → | haskl joins (~haskl@user/haskl) |
| 10:39:10 | → | CiaoSen joins (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 10:44:12 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 240 seconds) |
| 10:44:19 | → | w1gz joins (~weechat@2a03:b0c0:1:d0::1123:1) |
| 10:46:18 | × | MoC quits (~moc@user/moc) (Quit: Konversation terminated!) |
| 10:46:18 | × | dsrt^ quits (~dsrt@128-092-160-234.biz.spectrum.com) (Remote host closed the connection) |
| 10:47:56 | × | odnes quits (~odnes@2a02:587:440e:0:e8c:b484:c50b:a76) (Remote host closed the connection) |
| 10:52:53 | → | Lord_of_Life_ joins (~Lord@user/lord-of-life/x-2819915) |
| 10:53:41 | × | Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 10:54:10 | Lord_of_Life_ | is now known as Lord_of_Life |
| 10:57:30 | × | jmdaemon quits (~jmdaemon@user/jmdaemon) (Ping timeout: 276 seconds) |
| 11:00:43 | → | acidjnk_new joins (~acidjnk@p200300d0c7068b9978922ec24d0737b7.dip0.t-ipconnect.de) |
| 11:02:03 | × | xff0x quits (~xff0x@125x102x200x106.ap125.ftth.ucom.ne.jp) (Ping timeout: 276 seconds) |
| 11:07:39 | → | MajorBiscuit joins (~MajorBisc@c-001-013-046.client.tudelft.eduvpn.nl) |
| 11:08:20 | → | coot joins (~coot@213.134.190.95) |
| 11:08:32 | → | jgeerds joins (~jgeerds@d53604b0.access.ecotel.net) |
| 11:08:56 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 11:09:27 | × | w1gz quits (~weechat@2a03:b0c0:1:d0::1123:1) (Quit: w1gz) |
| 11:09:42 | → | w1gz joins (~weechat@2a03:b0c0:1:d0::1123:1) |
| 11:10:48 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 11:13:31 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 11:19:12 | × | tired quits (~tired@user/tired) (Read error: Connection reset by peer) |
| 11:19:35 | → | tired joins (~tired@user/tired) |
| 11:22:32 | × | kawzeg quits (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (Ping timeout: 250 seconds) |
| 11:22:43 | × | ddb quits (~ddb@2607:5300:203:9993::196) (Ping timeout: 260 seconds) |
| 11:22:50 | → | kawzeg joins (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 11:23:39 | → | ddb joins (~ddb@2607:5300:203:9993::196) |
| 11:24:45 | → | bahamas joins (~lucian@86.120.77.115) |
| 11:27:01 | × | mmhat quits (~mmh@2001:4090:a243:801d:ee08:6bff:fe09:5315) (Quit: WeeChat 3.5) |
| 11:30:32 | × | xaotuk quits (~sasha@net108-32-245-109.mbb.telenor.rs) (Ping timeout: 252 seconds) |
| 11:30:41 | → | odnes joins (~odnes@2a02:587:e901:3110::ec9) |
| 11:33:10 | × | jgeerds quits (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 240 seconds) |
| 11:33:15 | × | MajorBiscuit quits (~MajorBisc@c-001-013-046.client.tudelft.eduvpn.nl) (Quit: WeeChat 3.4) |
| 11:34:36 | → | mattil joins (~mattil@helsinki.portalify.com) |
| 11:36:55 | × | gurkenglas quits (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Ping timeout: 246 seconds) |
| 11:44:19 | → | lortabac joins (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) |
| 11:47:18 | → | xff0x joins (~xff0x@b133147.ppp.asahi-net.or.jp) |
| 11:50:00 | × | bliminse quits (~bliminse@host86-164-128-238.range86-164.btcentralplus.com) (Quit: leaving) |
| 11:53:38 | → | bliminse joins (~bliminse@host86-164-128-238.range86-164.btcentralplus.com) |
| 11:57:39 | → | epolanski joins (uid312403@id-312403.helmsley.irccloud.com) |
| 12:09:39 | × | odnes quits (~odnes@2a02:587:e901:3110::ec9) (Ping timeout: 260 seconds) |
| 12:09:57 | → | odnes joins (~odnes@2a02:587:e901:3110::ec9) |
| 12:15:15 | × | odnes quits (~odnes@2a02:587:e901:3110::ec9) (Ping timeout: 260 seconds) |
| 12:15:29 | → | Alex_test_ joins (~al_test@178.34.163.35) |
| 12:17:27 | × | Alex_test quits (~al_test@178.34.163.35) (Ping timeout: 276 seconds) |
| 12:30:33 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 12:30:46 | → | Pickchea joins (~private@user/pickchea) |
| 12:34:39 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 12:35:33 | → | gurkenglas joins (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) |
| 12:35:42 | <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 |
| 12:36:34 | <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) |
| 12:36:58 | × | gurkenglas quits (~gurkengla@dslb-084-057-085-111.084.057.pools.vodafone-ip.de) (Remote host closed the connection) |
| 12:37:14 | <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? |
| 12:37:46 | <geekosaur> | isn't foldM just some variant of sequence . fold? |
| 12:37:52 | <geekosaur> | @src foldM |
| 12:37:52 | <lambdabot> | foldM _ a [] = return a |
| 12:37:52 | <lambdabot> | foldM f a (x:xs) = f a x >>= \fax -> foldM f fax xs |
| 12:37:59 | <geekosaur> | mm, maybe not |
| 12:38:08 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 12:40:04 | <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 |
| 12:42:34 | <tomsmeding> | apache2: foldM over Map.assocs? |
| 12:43:10 | <apache2> | tomsmeding: that works, thanks |
| 12:44:04 | × | kaph quits (~kaph@net-2-42-128-205.cust.vodafonedsl.it) (Read error: Connection reset by peer) |
| 12:44:07 | → | kaph_ joins (~kaph@net-2-42-128-205.cust.vodafonedsl.it) |
| 12:45:27 | → | odnes joins (~odnes@2a02:587:e901:3110::273) |
| 12:48:30 | × | superbil quits (~superbil@1-34-176-171.hinet-ip.hinet.net) (Ping timeout: 265 seconds) |
| 12:48:40 | × | bahamas quits (~lucian@86.120.77.115) (Ping timeout: 246 seconds) |
| 12:48:56 | → | superbil joins (~superbil@1-34-176-171.hinet-ip.hinet.net) |
| 12:49:50 | → | bahamas joins (~lucian@86.120.77.115) |
| 12:52:45 | → | szkl joins (uid110435@id-110435.uxbridge.irccloud.com) |
| 12:59:03 | × | mattil quits (~mattil@helsinki.portalify.com) (Remote host closed the connection) |
| 13:00:14 | → | ehllie joins (~ehllie@217-67-208-66.itsa.net.pl) |
| 13:09:51 | × | CiaoSen quits (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 13:10:55 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 13:12:48 | × | [Leary] quits (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) (Ping timeout: 252 seconds) |
| 13:13:07 | × | bahamas quits (~lucian@86.120.77.115) (Quit: Lost terminal) |
| 13:14:25 | → | xaotuk joins (~sasha@net108-32-245-109.mbb.telenor.rs) |
| 13:14:50 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 13:15:15 | → | ub joins (~Thunderbi@p200300ecdf15880b09d618bc8a498343.dip0.t-ipconnect.de) |
| 13:17:22 | → | [itchyjunk] joins (~itchyjunk@user/itchyjunk/x-7353470) |
| 13:19:26 | × | acidjnk_new quits (~acidjnk@p200300d0c7068b9978922ec24d0737b7.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 13:26:02 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 13:26:57 | → | slack1256 joins (~slack1256@186.11.61.206) |
| 13:30:37 | → | slac79575 joins (~slack1256@191.125.227.220) |
| 13:33:30 | × | slack1256 quits (~slack1256@186.11.61.206) (Ping timeout: 276 seconds) |
| 13:35:42 | Alex_test_ | is now known as Alex_test |
| 13:40:27 | → | __monty__ joins (~toonn@user/toonn) |
| 13:41:08 | → | shriekingnoise joins (~shrieking@201.231.16.156) |
| 13:52:38 | → | Henson joins (~kvirc@107-179-133-201.cpe.teksavvy.com) |
| 13:53:14 | × | pavonia quits (~user@user/siracusa) (Quit: Bye!) |
| 13:54:30 | <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.... |
| 13:54:50 | × | ehllie quits (~ehllie@217-67-208-66.itsa.net.pl) (Quit: Connection closed) |
| 13:55:24 | <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? |
| 13:56:41 | <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? |
| 13:56:51 | <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. |
| 13:57:07 | <Henson> | merijn: yes, it's threaded, with 4 capabilities |
| 13:57:18 | <Henson> | merijn: I haven't run with sstderr yet |
| 13:57:32 | <merijn> | Henson: Also: https://mpickering.github.io/posts/2019-11-07-hs-speedscope.html :) |
| 13:57:38 | <merijn> | (for making profiles more readable) |
| 13:57:42 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 13:59:24 | → | bontaq joins (~user@ool-45779fe5.dyn.optonline.net) |
| 14:01:56 | <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. |
| 14:02:46 | <Henson> | merijn: will running threaded with multiple capabilities cause any problems or difficulties in time profiling? |
| 14:05:23 | <merijn> | Henson: But what does -s report? What's your productivity |
| 14:05:54 | <merijn> | Henson: Not so much difficulties profiling, but it can get you some nasty regressions in GC performance |
| 14:07:39 | <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. |
| 14:08:15 | <merijn> | Henson: What was productivity on the last run? |
| 14:08:34 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 14:09:19 | <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. |
| 14:10:05 | × | odnes quits (~odnes@2a02:587:e901:3110::273) (Quit: Leaving) |
| 14:10:45 | <merijn> | Henson: When you have performance issues, productivity is one of the first numbers you should look at :) |
| 14:11:12 | <merijn> | To see if it's in a sane ballpark or not |
| 14:13:24 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 14:16:09 | × | cfricke quits (~cfricke@user/cfricke) (Quit: WeeChat 3.5) |
| 14:20:43 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 14:24:45 | → | [Leary] joins (~Leary]@122-58-228-205-vdsl.sparkbb.co.nz) |
| 14:27:01 | × | frost quits (~frost@user/frost) (Quit: Client closed) |
| 14:29:29 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 14:30:08 | × | xaotuk quits (~sasha@net108-32-245-109.mbb.telenor.rs) (Ping timeout: 260 seconds) |
| 14:31:01 | × | vicfred quits (~vicfred@user/vicfred) (Quit: Leaving) |
| 14:32:31 | <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. |
| 14:32:45 | <Henson> | merijn: I'll try using the speedscope tool to see if that sheds any light on things |
| 14:32:50 | × | Pickchea quits (~private@user/pickchea) (Ping timeout: 240 seconds) |
| 14:33:54 | <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. |
| 14:34:54 | <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. |
| 14:35:11 | <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? |
| 14:35:17 | → | vysn joins (~vysn@user/vysn) |
| 14:36:06 | <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 |
| 14:36:37 | → | jgeerds joins (~jgeerds@d53604b0.access.ecotel.net) |
| 14:36:51 | → | xaotuk joins (~sasha@net108-32-245-109.mbb.telenor.rs) |
| 14:36:59 | <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. |
| 14:37:25 | <tomsmeding> | right, that makes it less likely that it's this |
| 14:37:54 | <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 |
| 14:38:09 | <Henson> | I'll try running with more tasks just to see what happens |
| 14:41:20 | × | Vajb quits (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) (Read error: Connection reset by peer) |
| 14:41:44 | → | Vajb joins (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 14:42:47 | <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%) |
| 14:43:08 | <tomsmeding> | Henson: so with -N5 you're always in the slow case? |
| 14:43:28 | <Henson> | tomsmeding: with -N8 or -N16 is reports ridiculous numbers for the MUT and GC times |
| 14:43:54 | <Henson> | tomsmeding: the low CPU case. The software still functions, it's just the CPU load is much lower. |
| 14:44:12 | <tomsmeding> | setting -N much higher than the number of cores shouldn't be useful, but I've seen people recommending ncores+1 |
| 14:44:30 | <davean> | Henson: I've not read up, but have you avoided parallel GC? |
| 14:44:46 | <tomsmeding> | (i.e. +RTS -qg) |
| 14:44:55 | <tomsmeding> | or +RTS --nonmoving-gc |
| 14:45:26 | <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 |
| 14:45:39 | slac79575 | is now known as slack1256 |
| 14:46:02 | <tomsmeding> | it has different behaviour and somewhat different use cases where it works well, so it's usually worth trying both |
| 14:46:04 | <davean> | Henson: Its not an "issue" its that when you have small garbage theres more cordination than progress - inherently. |
| 14:47:23 | <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 |
| 14:47:39 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 14:47:50 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 14:47:51 | <Henson> | GC time -5447168.964s ( 0.063s elapsed) |
| 14:47:59 | <tomsmeding> | lol |
| 14:48:11 | <tomsmeding> | I wonder whether that's an overflow |
| 14:48:16 | <Henson> | it was balanced out by the MUT, though: MUT time 5447174.517s ( 3.255s elapsed) |
| 14:48:18 | <Henson> | :-) |
| 14:48:22 | <tomsmeding> | :') |
| 14:48:26 | <davean> | Thats not sane. |
| 14:48:34 | <Henson> | haha |
| 14:48:35 | <tomsmeding> | merijn: ^ |
| 14:48:50 | <davean> | I've never seen anything like that - I . . . that shouldn't be an overflow either. Do you have clock issues? |
| 14:48:51 | × | mikoto-chan quits (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 14:49:03 | <davean> | like that makes no sense |
| 14:49:17 | <davean> | I mean it shouldn't be a clock issue either to be clear |
| 14:49:19 | <tomsmeding> | that's more than 2 months worth of negative seconds |
| 14:49:25 | × | xaotuk quits (~sasha@net108-32-245-109.mbb.telenor.rs) (Ping timeout: 256 seconds) |
| 14:49:50 | <tomsmeding> | I like how the report clarifies the amount of elapsed time, which _is_ sane |
| 14:50:21 | <Henson> | with -N16 it's even worse: GC time 6018330949.191s ( 0.130s elapsed) MUT time 0.000s ( 9.963s elapsed) |
| 14:50:38 | → | mikoto-chan joins (~mikoto-ch@213.177.151.239) |
| 14:50:42 | <Henson> | davean: I don't think I have system clock issues |
| 14:50:53 | <tomsmeding> | Henson: ghc version? if this is reproducible that sounds like an RTS bug lol |
| 14:51:14 | <Henson> | tomsmeding: 8.10.7 |
| 14:51:36 | <davean> | Hum, well I certainly never saw that on that version but I don't remember much about 8.10 anymore its so old. |
| 14:51:57 | <tomsmeding> | davean: most of haskell users are still on 8.10.7 |
| 14:52:03 | <davean> | tomsmeding: They're weird then |
| 14:52:14 | <tomsmeding> | each of the subsequent versions has _some_ issue on some platform |
| 14:52:27 | <tomsmeding> | 8.10.7 is the latest that's universally okay |
| 14:52:39 | 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 |
| 14:52:47 | <tomsmeding> | if not, argue with maerwald to move the 'recommended' tag to a later version |
| 14:54:09 | <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. |
| 14:55:01 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 246 seconds) |
| 14:55:16 | <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% |
| 14:55:25 | <tomsmeding> | -qg I hope |
| 14:55:38 | <davean> | Henson: yah, it should in your case |
| 14:55:53 | <davean> | Henson: you mostly want parallel GC with large amounts of live data, with a deeply connected structure |
| 14:56:30 | <Henson> | davean: ok, I'll add that to my cabal file |
| 14:56:47 | × | christiansen quits (~christian@83-95-137-75-dynamic.dk.customer.tdc.net) (Ping timeout: 256 seconds) |
| 14:57:02 | <davean> | his is also part of what makes basic lists bad - esp if they're super long |
| 14:58:12 | <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. |
| 14:58:17 | <telser> | FWIW I know of projects in industry that are still on 8.6 |
| 14:58:50 | <Henson> | would this also explain why the difference between the high and low CPU cases were not showing up in the time profiling? |
| 14:59:26 | <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 |
| 15:00:27 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 15:03:50 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 15:04:13 | <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. |
| 15:07:00 | <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. |
| 15:08:13 | <Henson> | running with parallel garbage collection and more threads than CPU cores also helps the problem |
| 15:09:46 | <Henson> | thank you very much for your help, everyone, another mystery solved! |
| 15:11:15 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 15:11:36 | → | FinnElija joins (~finn_elij@user/finn-elija/x-0085643) |
| 15:14:00 | × | alp_ quits (~alp@user/alp) (Ping timeout: 260 seconds) |
| 15:16:02 | × | jgeerds quits (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 252 seconds) |
| 15:17:21 | → | pretty_dumm_guy joins (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 15:19:51 | → | Tuplanolla joins (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) |
| 15:20:21 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:91c0:4831:d96e:28ee) (Quit: WeeChat 2.8) |
| 15:21:24 | × | __monty__ quits (~toonn@user/toonn) (Quit: leaving) |
| 15:25:11 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 15:25:18 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds) |
| 15:29:47 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 15:30:23 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 15:31:41 | × | benin quits (~benin@183.82.31.174) (Quit: The Lounge - https://thelounge.chat) |
| 15:32:32 | × | cheater quits (~Username@user/cheater) (Read error: Connection reset by peer) |
| 15:32:54 | <davean> | slack1256: Its inherent to the desing of GC |
| 15:33:05 | <davean> | slack1256: Implimenting a GC was part of college? |
| 15:33:29 | → | cheater joins (~Username@user/cheater) |
| 15:33:41 | <davean> | slack1256: Think about exactly how a GC works. It follows references from a root set |
| 15:34:06 | <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 |
| 15:37:01 | × | xff0x quits (~xff0x@b133147.ppp.asahi-net.or.jp) (Ping timeout: 246 seconds) |
| 15:38:02 | × | mikoto-chan quits (~mikoto-ch@213.177.151.239) (Ping timeout: 252 seconds) |
| 15:39:59 | → | mikoto-chan joins (~mikoto-ch@213.177.151.239) |
| 15:40:54 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 15:41:34 | → | _ht joins (~quassel@231-169-21-31.ftth.glasoperator.nl) |
| 15:44:01 | × | nschoe quits (~quassel@178.251.84.79) (Ping timeout: 246 seconds) |
| 15:46:00 | × | coot quits (~coot@213.134.190.95) (Quit: coot) |
| 15:50:34 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 15:51:40 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 15:51:55 | → | dextaa490 joins (~dextaa@user/dextaa) |
| 15:54:58 | <sm> | top starred haskell github repos: https://github.com/search?o=desc&q=language%3AHaskell+stars%3A%3E=100&ref=searchresults&s=stars&type=Repositories |
| 15:55:19 | <Franciman> | nice ty sm |
| 15:55:35 | → | HotblackDesiato joins (~HotblackD@gateway/tor-sasl/hotblackdesiato) |
| 15:55:57 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 15:56:06 | <sm> | my question: how does graphql-engine, with presumably fewer direct users, get so many ? |
| 15:57:27 | <sm> | and related: this and more search tools can be found at https://haskell-links.org |
| 15:58:01 | → | xff0x joins (~xff0x@b133147.ppp.asahi-net.or.jp) |
| 16:02:51 | <geekosaur> | something's wrong there, xmonad has 2.5k but doesn't seem to show up at all |
| 16:03:03 | <geekosaur> | (but kmonad and xmobar do) |
| 16:04:16 | × | EvanR_ quits (~EvanR@user/evanr) (Quit: Leaving) |
| 16:04:58 | <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. |
| 16:05:05 | → | EvanR joins (~EvanR@user/evanr) |
| 16:05:20 | <slack1256> | That is why I wanted a reference. Probably my intuitions are wrong and that was acquired knowledge >.> . |
| 16:05:58 | → | CiaoSen joins (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 16:09:50 | <davean> | slack1256: its the opposite becase it needs to follow links - thats what the processing is doing - all of what it is doing really. |
| 16:10:05 | <davean> | slack1256: If you have a linked list you can't theoretically use more than a single core on it. |
| 16:10:15 | <davean> | Theres only one spine to follow |
| 16:10:58 | <davean> | What GC does is *copy* (or mark, depending on type) live data |
| 16:11:05 | <davean> | it SPECIFICLY does not touch dead data. |
| 16:11:27 | <davean> | The resident size has NOTHING to do with available work |
| 16:11:33 | <davean> | slack1256: have you never implimented a GC? |
| 16:11:53 | <slack1256> | Yes, I got that we follow live data and resisident size does matter, only live data size. |
| 16:12:14 | <slack1256> | Nope. I know the theory from afar, mostly mark-and-sweep. |
| 16:12:20 | <slack1256> | And I have read some RTS code on it. |
| 16:13:50 | <geekosaur> | mm, this is even weirder. xmonad-contrib (459 stars) *does* show up |
| 16:13:55 | <davean> | Yes but *how* you follow live data |
| 16:14:02 | × | kuribas quits (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 16:14:25 | <slack1256> | Root set as you say. We follow the links from there moving to the other half of the generation. |
| 16:14:36 | <davean> | Right, we *follow the links* |
| 16:14:46 | <davean> | for that we need *parallel* links to enable multiple workers |
| 16:15:29 | <davean> | Following a link is predicated on having followed all preceding links |
| 16:15:31 | <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 ? |
| 16:15:37 | <davean> | otherwise we don't know what we're following from is live. |
| 16:17:30 | <slack1256> | So you are saying that nodes in the rootset are the only real "parallelizable nodes" that we can have? |
| 16:18:06 | <davean> | No, they're the initial parallelism - you can always get more parallism out of having more connected data |
| 16:18:31 | <davean> | If a worker runs dry, it can steal from the queue of other workers, to get new links to follow |
| 16:18:39 | <davean> | but that predicates on having a branch factor in your data |
| 16:19:32 | <sm> | geekosaur: >1000 didn't help, pretty sure I remember seeing it show up in the past. That *is* weird |
| 16:19:56 | <geekosaur> | I limited it to 2000. xmonad didn't show up… but yesod did |
| 16:20:03 | → | shiraeeshi joins (~shiraeesh@77.94.25.209) |
| 16:20:40 | → | Everything joins (~Everythin@37.115.210.35) |
| 16:21:04 | <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. |
| 16:21:30 | <sm> | https://github.com/search?q=xmonad%2Fxmonad&type=Repositories doesn't find it either |
| 16:21:30 | <geekosaur> | so something's definitely screwy with github search |
| 16:21:40 | <davean> | slack1256: no |
| 16:21:52 | <slack1256> | That certainly is not problem for the nursery, given that not many moving (if any) are done, but Gen1 probably is. |
| 16:22:01 | <davean> | slack1256: thats a missunderstanding of how HW works, also it doesn't matter |
| 16:22:21 | <davean> | Its irrelivent to parallelism |
| 16:22:27 | <davean> | and its not how cache behaves |
| 16:22:35 | <sm> | any github employees here who could rescue xmonad ? |
| 16:22:59 | <davean> | sm: rescue? |
| 16:23:02 | <davean> | what happened? |
| 16:23:32 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 16:23:32 | <sm> | we have just been chatting about it |
| 16:23:48 | <sm> | not showing in gihub search |
| 16:23:59 | → | alp_ joins (~alp@user/alp) |
| 16:24:08 | <Bulby[m]> | it shows up for me |
| 16:24:19 | <Bulby[m]> | https://github.com/xmonad/xmonad |
| 16:24:26 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 16:24:27 | <geekosaur> | search, not directly going to it |
| 16:24:34 | <geekosaur> | https://github.com/search?q=xmonad%2Fxmonad&type=Repositories |
| 16:24:38 | <Bulby[m]> | i did search |
| 16:24:42 | <geekosaur> | it's even pinned in our org |
| 16:25:01 | <lechner> | sm: i only see -contrib in the search |
| 16:25:04 | <Bulby[m]> | does irc support images? |
| 16:25:05 | <geekosaur> | oh wait, I wonder if that search is valid |
| 16:25:13 | <geekosaur> | Bulby[m], no |
| 16:25:24 | × | Vajb quits (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 16:25:36 | <Bulby[m]> | ok, won't try then 🙂 |
| 16:25:45 | → | Vajb joins (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) |
| 16:26:18 | <Bulby[m]> | wtf ur right |
| 16:26:19 | <Bulby[m]> | no xmonad core |
| 16:27:01 | <geekosaur> | yeh, nor with https://github.com/search?o=desc&q=xmonad&s=stars&type=Repositories (omitting the org) |
| 16:27:24 | <Bulby[m]> | `xmonad user:xmonad` doesn't show core |
| 16:27:25 | <geekosaur> | somebody's indexing is busted |
| 16:27:31 | <lechner> | maybe 98.1% Haskell isn't pure enough? |
| 16:28:13 | <EvanR> | haskell 200 proof |
| 16:28:30 | <geekosaur> | these searches aren't even considering language |
| 16:28:48 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 16:29:16 | <lechner> | yeah, it does not show in regular search either, with "best match" |
| 16:29:17 | → | romesrf joins (~romes@185.5.8.134) |
| 16:29:18 | <geekosaur> | o.O but this search did just introduce me to https://github.com/wouter-swierstra/xmonad (xmonad in Coq?!) |
| 16:29:51 | <sm> | that's the danger of these search tools.. you find all kinds of stuff |
| 16:30:01 | <lechner> | or not |
| 16:30:19 | → | Guest|52 joins (~Guest|52@c-76-23-5-70.hsd1.ut.comcast.net) |
| 16:30:32 | <Bulby[m]> | I really like haskell in general... it makes work fast |
| 16:31:27 | <shiraeeshi> | hey |
| 16:31:44 | <shiraeeshi> | how is it going |
| 16:31:56 | × | vysn quits (~vysn@user/vysn) (Ping timeout: 260 seconds) |
| 16:31:59 | <shiraeeshi> | I'm trying to follow "Advanced Track: Understanding Memory Usage with eventlog2html and ghc-debug @ZuriHac21" |
| 16:32:10 | <shiraeeshi> | https://youtu.be/6Ljv5FHGXDM |
| 16:32:19 | <shiraeeshi> | https://github.com/well-typed/memory-usage-zurihac-2021 |
| 16:32:47 | → | catern joins (~sbaugh@2604:2000:8fc0:b:a9c7:866a:bf36:3407) |
| 16:33:23 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 16:33:35 | <shiraeeshi> | the problem is that Cabal can't resolve dependencies when I run "cabal build tui simple debugger realworld-exe" |
| 16:34:17 | <sm> | weird.. didn't there used to be a "global" gitlab instance ? I can't find it |
| 16:35:18 | <shiraeeshi> | here is the error message https://paste.tomsmeding.com/cYesMoSt |
| 16:36:09 | × | cheater quits (~Username@user/cheater) (Ping timeout: 265 seconds) |
| 16:36:59 | <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" |
| 16:37:04 | <sm> | ah, you have to sign in |
| 16:37:09 | <sm> | weird |
| 16:38:00 | <shiraeeshi> | the conflict is with the debugger's dependency which is "base>=4.14" |
| 16:38:06 | <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 |
| 16:38:25 | → | vicfred joins (~vicfred@user/vicfred) |
| 16:38:47 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 16:38:56 | <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 |
| 16:38:59 | <shiraeeshi> | oh, ok, let's see |
| 16:40:09 | → | troydm1 joins (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 16:40:39 | <slack1256> | catern: The new an modern way is to use "nix flakes", which ship with templates for you haskell projects. |
| 16:40:42 | × | troydm quits (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 276 seconds) |
| 16:41:06 | <slack1256> | `nix flake new -t templates#haskell-hello .` is the starting point. |
| 16:42:54 | → | coot joins (~coot@213.134.190.95) |
| 16:45:35 | × | troydm1 quits (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 256 seconds) |
| 16:47:17 | × | epolanski quits (uid312403@id-312403.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 16:47:42 | × | Guest|52 quits (~Guest|52@c-76-23-5-70.hsd1.ut.comcast.net) (Quit: Connection closed) |
| 16:51:06 | <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 |
| 16:56:25 | <[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. |
| 16:59:33 | <catern> | [Leary]: the devShell definitely needs to be modified |
| 17:00:12 | → | waleee joins (~waleee@2001:9b0:213:7200:cc36:a556:b1e8:b340) |
| 17:00:22 | <catern> | is a simple "cabal install" the thing that I should expect to work to build the package? |
| 17:02:57 | × | Vajb quits (~Vajb@2001:999:400:9bc1:d5dd:7e53:33b:56) (Read error: Connection reset by peer) |
| 17:03:04 | <[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. |
| 17:04:05 | → | Vajb joins (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 17:06:50 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 17:09:42 | → | moonsheep joins (~user@user/moonsheep) |
| 17:12:28 | → | fef joins (~thedawn@user/thedawn) |
| 17:15:11 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 17:15:49 | ← | Everything parts (~Everythin@37.115.210.35) () |
| 17:17:16 | × | vpan quits (~0@212.117.1.172) (Quit: Leaving.) |
| 17:18:11 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 246 seconds) |
| 17:19:32 | <shiraeeshi> | this is unusual |
| 17:20:30 | <shiraeeshi> | downloaded dependencies won't compile: https://paste.tomsmeding.com/Zl504Nqj and https://paste.tomsmeding.com/BFlPCCaF |
| 17:21:00 | <sm> | unusual, you say.. |
| 17:21:26 | <sm> | this can happen when published packages have bounds that are too loose, allowing such build errors |
| 17:21:39 | <sm> | there might be discussion in the packages' issue trackers |
| 17:21:57 | <sm> | using stackage avoids this |
| 17:23:07 | → | acidjnk_new joins (~acidjnk@p200300d0c7068b99c0183a275a5d2a59.dip0.t-ipconnect.de) |
| 17:23:13 | <shiraeeshi> | version mismatch again? |
| 17:23:28 | <shiraeeshi> | here we go |
| 17:24:50 | <shiraeeshi> | the project readme says: |
| 17:24:52 | <shiraeeshi> | Or, alternatively, use this nix invocation to set-up the environment. |
| 17:25:01 | <shiraeeshi> | nix-shell |
| 17:25:43 | <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_. |
| 17:25:48 | <sm> | there's a newer https://hackage.haskell.org/package/base16-bytestring-1.0.2.0/changelog , sometimes a cabal update helps |
| 17:26:13 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 17:26:14 | <sm> | pipe it through pandoc, texasmynsted |
| 17:26:18 | <catern> | (lol okay I'm just going to give up on building agda and just file https://github.com/agda/agda/issues/5901 ) |
| 17:26:34 | <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. |
| 17:27:12 | × | moonsheep quits (~user@user/moonsheep) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)) |
| 17:27:28 | <texasmynsted> | I only want to change the "selected" markdown image tag. |
| 17:28:21 | <texasmynsted> | sm: hmm. Interesting. I have never thought to pipe a single tag through pandoc. |
| 17:29:03 | × | mbuf quits (~Shakthi@27.58.139.1) (Quit: Leaving) |
| 17:29:06 | <texasmynsted> | It seems like that _should_ work |
| 17:29:14 | <sm> | just "pandoc" works (md -> html is the default). It adds some extra tags, but options might stop those |
| 17:29:38 | → | z812 joins (~zyg@user/z812) |
| 17:29:59 | <texasmynsted> | and it literally parses the text, converts it to an AST then transforms it out again. :-) |
| 17:30:06 | <sm> | yup |
| 17:30:29 | <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) |
| 17:30:51 | <texasmynsted> | Mostly when editing markdown documents. |
| 17:31:08 | <texasmynsted> | I can hook the solution into neovim, and other places I am sure |
| 17:31:27 | <sm> | I'm in emacs, so it'd be select, C-u S-M-| pandoc |
| 17:33:04 | ← | z812 parts (~zyg@user/z812) (Bye-bye!) |
| 17:34:09 | → | econo joins (uid147250@user/econo) |
| 17:34:32 | <texasmynsted> | Hmm. nice |
| 17:35:05 | <texasmynsted> | It _works_. Now to see how I can modify it. Maybe a filter or something? |
| 17:35:43 | <texasmynsted> | It adds a figure, and I might want to have the image stand alone, and have a default width. |
| 17:36:45 | <texasmynsted> | This is great. Thank you. |
| 17:38:54 | <sm> | `pandoc -rmarkdown-implicit_figures` stops it adding figure tags |
| 17:39:17 | <texasmynsted> | :-) |
| 17:39:35 | × | CiaoSen quits (~Jura@p200300c95732ec002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 17:39:37 | <texasmynsted> | One key is default width |
| 17:41:21 | → | jgeerds joins (~jgeerds@d53604b0.access.ecotel.net) |
| 17:42:54 | × | ec quits (~ec@gateway/tor-sasl/ec) (Quit: ec) |
| 17:43:13 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 17:43:27 | × | ec quits (~ec@gateway/tor-sasl/ec) (Client Quit) |
| 17:43:38 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 17:45:00 | → | dschrempf joins (~dominik@mobiledyn-62-240-134-183.mrsn.at) |
| 17:45:40 | → | tusko joins (~yeurt@user/tusko) |
| 17:45:45 | <tusko> | I have question |
| 17:45:51 | <tusko> | not smart |
| 17:46:00 | <tusko> | What's the deal with let |
| 17:46:23 | → | cheater joins (~Username@user/cheater) |
| 17:48:44 | <geekosaur[m][m]> | I don't understand the question |
| 17:49:06 | <tusko> | I give examples |
| 17:49:21 | <tusko> | let (_,x) = (10, "turtlebutt") in x |
| 17:49:23 | <tusko> | wow |
| 17:49:32 | <tusko> | , what a verbose way to index into the tuple |
| 17:49:33 | × | alp_ quits (~alp@user/alp) (Remote host closed the connection) |
| 17:49:58 | → | alp_ joins (~alp@user/alp) |
| 17:51:08 | <sm> | because I can't leave well enough alone.. and wanted to get rid of the <p></p> tags (and pandoc is haskell-related).. |
| 17:51:09 | <sm> | echo '' | pandoc -rgfm -tnative | cut -c7- | sed -e 's/]$//' | pandoc -rnative |
| 17:51:23 | <geekosaur[m][m]> | Tuples aren't very good, we recommend against using them |
| 17:51:51 | → | whatsupdoc joins (uid509081@id-509081.hampstead.irccloud.com) |
| 17:51:57 | <tusko> | Ok, I can get behind this. I do not use Tuples except when elements are immutable (usually). |
| 17:51:59 | <romesrf> | tusko: `snd (10, "tt")` |
| 17:52:13 | <romesrf> | snd :: (a,b) -> b |
| 17:52:18 | <geekosaur[m][m]> | Pretty much the only thing you can do is pattern match them |
| 17:52:50 | → | Nux32 joins (~Nux@92.139.200.146.dyn.plus.net) |
| 17:53:07 | <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" |
| 17:53:13 | <geekosaur[m][m]> | Or use the canned ones, with 2-tuples only |
| 17:53:15 | <dminuoso> | [exa]: Mmm, is there a way to create a generic `transparent :: Pixel a => a`? |
| 17:53:35 | <dminuoso> | Or well, that wont quite work |
| 17:54:15 | <dminuoso> | It'd be some kind of `transparent :: HasAlpha (PixelBaseComponent a) => Pixel a => a` |
| 17:54:20 | → | mshiraeeshi joins (~shiraeesh@109.166.56.211) |
| 17:54:26 | <telser> | Usually better to have a more expressive type than a tuple. |
| 17:54:50 | × | dextaa490 quits (~dextaa@user/dextaa) (Quit: The Lounge - https://thelounge.chat) |
| 17:54:59 | × | alp_ quits (~alp@user/alp) (Ping timeout: 260 seconds) |
| 17:55:07 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 17:55:08 | <tusko> | Let me I will get you a better example |
| 17:55:24 | <dminuoso> | tusko: Indexing into tuples is not a common operation. |
| 17:55:59 | <sm> | tusko, some things are verbose, some are terse. Overall it's pretty good |
| 17:56:02 | <tusko> | let square x = x * x in square 3 |
| 17:56:08 | <tusko> | pointless |
| 17:56:24 | → | zincy joins (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) |
| 17:56:34 | <geekosaur[m][m]> | Most simple examples are |
| 17:56:39 | <tusko> | let (a,b) = (10,12) in a * 2 ...but why |
| 17:56:45 | <sm> | sometimes people name things for clarity |
| 17:56:57 | <dminuoso> | tusko: Where do you have these examples from? |
| 17:56:59 | × | shiraeeshi quits (~shiraeesh@77.94.25.209) (Ping timeout: 256 seconds) |
| 17:57:00 | <dminuoso> | They are all poor examples. |
| 17:57:30 | <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 |
| 17:57:37 | <dminuoso> | My most frequent use of tuples arises from working with maps from the `containers` package. |
| 17:57:43 | <geekosaur[m][m]> | Because we actually use them for more complicated expressions |
| 17:57:48 | <dminuoso> | @let import qualified Data.Map as M |
| 17:57:49 | <lambdabot> | Defined. |
| 17:57:50 | <dminuoso> | :t M.assocs |
| 17:57:52 | <lambdabot> | M.Map k a -> [(k, a)] |
| 17:57:52 | <dminuoso> | Things like this |
| 17:58:20 | <dminuoso> | Though its often more elegant to use |
| 17:58:34 | <dminuoso> | % :t M.foldrWithKey |
| 17:58:38 | <dminuoso> | :t M.foldrWithKey |
| 17:58:39 | <lambdabot> | (k -> a -> b -> b) -> b -> M.Map k a -> b |
| 17:58:47 | <geekosaur[m][m]> | But that leads beginners to focus on the complicated expressions instead of the patterns |
| 17:58:48 | <dminuoso> | Which I guess is equivalent to assocs |
| 17:59:08 | × | slack1256 quits (~slack1256@191.125.227.220) (Remote host closed the connection) |
| 17:59:17 | <dminuoso> | :t M.fromList |
| 17:59:18 | <lambdabot> | Ord k => [(k, a)] -> M.Map k a |
| 17:59:31 | → | slack1256 joins (~slack1256@191.125.227.220) |
| 17:59:50 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 18:03:00 | ← | jakalx parts (~jakalx@base.jakalx.net) (Error from remote client) |
| 18:03:58 | sm | plans to take over `@where links`, since it refers to the dead http://groups.inf.ed.ac.uk/links |
| 18:05:07 | → | alp_ joins (~alp@user/alp) |
| 18:06:23 | → | xkuru joins (~xkuru@user/xkuru) |
| 18:08:01 | → | jakalx joins (~jakalx@base.jakalx.net) |
| 18:08:49 | × | pie_ quits (~pie_bnc@user/pie/x-2818909) () |
| 18:08:50 | → | kenran joins (~kenran@200116b82b161c00019eb3ff6945071f.dip.versatel-1u1.de) |
| 18:09:13 | → | pie_ joins (~pie_bnc@user/pie/x-2818909) |
| 18:10:30 | × | dschrempf quits (~dominik@mobiledyn-62-240-134-183.mrsn.at) (Ping timeout: 240 seconds) |
| 18:11:41 | → | troydm joins (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 18:11:46 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection) |
| 18:12:36 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 18:15:57 | × | zincy quits (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) (Remote host closed the connection) |
| 18:16:28 | → | FinnElija joins (~finn_elij@user/finn-elija/x-0085643) |
| 18:17:50 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 240 seconds) |
| 18:21:40 | → | zincy joins (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) |
| 18:23:57 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 18:24:41 | <tusko> | I want to love Haskell but its hard to get a feel for the language with this weak tutorial. |
| 18:25:04 | → | azimut joins (~azimut@gateway/tor-sasl/azimut) |
| 18:25:16 | <Bulby[m]> | ah haskell, a good language with a lack of documentation |
| 18:25:20 | <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. |
| 18:25:25 | × | HotblackDesiato quits (~HotblackD@gateway/tor-sasl/hotblackdesiato) (Remote host closed the connection) |
| 18:25:39 | <tusko> | So, of course, they scrapped the Haskell and remade the entire project in Rust. |
| 18:25:45 | → | HotblackDesiato joins (~HotblackD@gateway/tor-sasl/hotblackdesiato) |
| 18:25:47 | <Bulby[m]> | HAHAH |
| 18:25:48 | <tusko> | Something about that just always seemed wrong to me. |
| 18:26:26 | <Bulby[m]> | haskell is one of my favorite langs now - it's very powerful |
| 18:26:33 | <Bulby[m]> | blub paradox strikes again |
| 18:27:03 | <dmj`> | tusko: I've heard of Haskell projects getting scrapped for rust too ... sad. |
| 18:28:12 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 18:28:44 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 18:33:04 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 246 seconds) |
| 18:34:44 | <sm> | I'd say "lack of documentation" is not one of the problems we have at this point |
| 18:35:45 | × | merijn quits (~merijn@86-86-29-250.fixed.kpn.net) (Ping timeout: 276 seconds) |
| 18:36:41 | × | coot quits (~coot@213.134.190.95) (Quit: coot) |
| 18:36:53 | <sm> | and, sometimes rust is a better fit ? |
| 18:37:20 | <sm> | scrapping work wastefully for the bad reasons is sad I agree |
| 18:38:01 | <lechner> | "everything is a monad" is the desperate cry before they switch |
| 18:39:12 | × | zeenk quits (~zeenk@2a02:2f04:a004:9b00:1efc:c1cf:378d:8b3d) (Quit: Konversation terminated!) |
| 18:42:29 | <lechner> | i know such a place too |
| 18:43:32 | <dmj`> | "everything is a monad" ... famous last words |
| 18:44:14 | <lechner> | it was voice processing, went to Java |
| 18:44:21 | <davean> | Some things are only functors, some things are groups, everything is something though. |
| 18:45:12 | <lechner> | it's from their prespective. only monads do something |
| 18:46:30 | <Henson> | why not hire more Haskell people instead of scrapping the whole project and starting over? |
| 18:47:04 | <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. |
| 18:47:30 | <Henson> | ahh |
| 18:47:48 | <darkling> | s/knowledge/certainty/ |
| 18:47:52 | <telser> | Particularly if you restrict yourself geographically, which some companies do. |
| 18:47:56 | <davean> | I mean Haskell people also are generally high enough skilled to have competing decent paying jobs available. |
| 18:48:43 | <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. |
| 18:49:31 | <Henson> | Are Haskell devs difficult to come by, if you don't restrict yourself geographically and pay decently? |
| 18:49:39 | <davean> | Not really |
| 18:50:18 | <carbolymer> | davean: I'm not doing recruitment, but my current and past workplace struggled hard to find a good haskell dev |
| 18:50:29 | <carbolymer> | idk what they did wrong, but it was hard |
| 18:50:35 | <davean> | carbolymer: what did they do? |
| 18:50:46 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 18:51:10 | <darkling> | Offerd $60k pa? |
| 18:51:56 | <carbolymer> | pay is not bad in both places, I was satisfied |
| 18:52:14 | <maerwald> | Henson: compared to? |
| 18:53:00 | <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. |
| 18:53:10 | <davean> | So it was a particularly clear case of "uh, what?" |
| 18:53:13 | → | slac14257 joins (~slack1256@191.126.227.91) |
| 18:53:18 | × | Tuplanolla quits (~Tuplanoll@91-159-68-39.elisa-laajakaista.fi) (Quit: Leaving.) |
| 18:53:31 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 18:53:33 | <Henson> | maerwald: well, compared to "we've been searching for 6 months and don't have any competent Haskell developer applications" |
| 18:53:41 | <Henson> | applications -> applicants |
| 18:53:56 | <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 |
| 18:54:41 | <davean> | yah you won't find many undereducated 3rd world Haskell devs. |
| 18:55:09 | <davean> | But honestly if you're looking in the general vein of standard, compitent programmers, I think they're easier to hire? |
| 18:55:13 | <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 |
| 18:55:28 | <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 |
| 18:55:54 | × | slack1256 quits (~slack1256@191.125.227.220) (Ping timeout: 276 seconds) |
| 18:55:59 | <davean> | telser: I mean that was true 10 years ago, but now? No? Everyone has gone remote - you're always competing with that |
| 18:56:01 | <maerwald> | entry level in Europe is 50k €... I've seen Haskell positions in Sweden for 55-65k for seniors |
| 18:56:21 | <davean> | maerwald: Yah but pay in Europe is different because costs are different. |
| 18:56:34 | <davean> | (For the employees, via benefits and taxes) |
| 18:56:37 | <whatsupdoc> | Wow, that's broke money |
| 18:56:41 | <maerwald> | there was a Haskell position in japan for 9 million yen in Tokyo, which is a joke there |
| 18:56:41 | <davean> | so thats lower but not insanely low |
| 18:56:52 | <maerwald> | davean: 45% is tax here bro |
| 18:57:05 | <maerwald> | even worse when you're self employed |
| 18:57:13 | <davean> | maerwald: Yes, I'm aware - more if you're getting paid from an out-side-EU country. |
| 18:57:42 | <maerwald> | I've been paid by SEA countries, it doesn't get better, because they pay based on your location |
| 18:58:11 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 18:58:35 | <maerwald> | that's the new thing... salaries haven't gone global, now they pay you less, because you're living in India |
| 18:59:05 | <maerwald> | not that I care much anyway |
| 18:59:15 | <maerwald> | can't buy health with money |
| 18:59:29 | × | littlebobeep quits (~alMalsamo@gateway/tor-sasl/almalsamo) (Remote host closed the connection) |
| 19:04:43 | → | littlebobeep joins (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 19:05:30 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 19:09:04 | × | fef quits (~thedawn@user/thedawn) (Ping timeout: 240 seconds) |
| 19:12:11 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 19:12:56 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 19:22:57 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 19:30:27 | → | MoC joins (~moc@user/moc) |
| 19:31:30 | → | merijn joins (~merijn@86-86-29-250.fixed.kpn.net) |
| 19:32:52 | × | albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 19:32:59 | → | pavonia joins (~user@user/siracusa) |
| 19:34:06 | <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 |
| 19:35:47 | <mshiraeeshi> | they point to ghc-9.2.1-alpha2 |
| 19:36:14 | <tomsmeding> | wasn't the Word# to Word8# shift in 9.2 |
| 19:37:44 | <mshiraeeshi> | let's say I want to try ghc-9.2.1-alpha2, is there a way to install this version using ghcup? |
| 19:38:03 | <maerwald> | where is that version |
| 19:38:35 | <mshiraeeshi> | what do you mean? |
| 19:38:40 | → | coot joins (~coot@213.134.190.95) |
| 19:38:46 | <mshiraeeshi> | or do I have to do it outside of ghcup? |
| 19:38:55 | <tomsmeding> | https://downloads.haskell.org/~ghc/9.2.1-alpha2/ here, presumably |
| 19:38:58 | <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 |
| 19:39:00 | <maerwald> | is a workaround |
| 19:39:02 | → | albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 19:39:26 | <mshiraeeshi> | ok, let me try |
| 19:39:41 | <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 |
| 19:39:59 | <maerwald> | is there a point? 9.2.2 is already out |
| 19:40:54 | <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 |
| 19:41:20 | <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 |
| 19:42:16 | × | alp_ quits (~alp@user/alp) (Remote host closed the connection) |
| 19:42:42 | → | alp_ joins (~alp@user/alp) |
| 19:42:43 | <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 |
| 19:42:48 | → | Pickchea joins (~private@user/pickchea) |
| 19:42:55 | <sm> | you should probably check the issue tracker / contact the maintainer at this point |
| 19:43:12 | <sm> | so they can make this more buildable |
| 19:43:50 | <mshiraeeshi> | sm: but it obviously worked for those people who created the project? |
| 19:44:10 | <mshiraeeshi> | I mean, the https://github.com/well-typed/memory-usage-zurihac-2021 project |
| 19:44:23 | <sm> | I suppose ? |
| 19:44:45 | <sm> | are you using nix ? |
| 19:44:48 | <mshiraeeshi> | how can the same version of the package work and then fail to compile 7 months later? |
| 19:44:59 | <mshiraeeshi> | no, no nix |
| 19:45:10 | <sm> | very, very easily. It's the norm, not the exception |
| 19:45:36 | <mshiraeeshi> | I also wanted to ask about nix. the readme says: "Or, alternatively, use this nix invocation to set-up the environment." |
| 19:45:40 | <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 |
| 19:45:46 | <sm> | nix, stack, cabal.project are all attempts to make it more repeatable |
| 19:45:48 | <tdammers> | the reason this can happen is because of how version bounds work, and how people use them |
| 19:45:49 | <mshiraeeshi> | using "nix-shell" command |
| 19:46:23 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 19:46:36 | <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 |
| 19:46:58 | <tomsmeding> | you're using a different version of some dependency to get those option and Word8# errors |
| 19:47:25 | <mshiraeeshi> | can I workaround this by using nix? |
| 19:47:34 | <tomsmeding> | probably |
| 19:47:49 | <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 |
| 19:47:53 | <mshiraeeshi> | and let me ask a stupid question just to make sure: it doesn't mean switching to nixos right? |
| 19:48:20 | <sclv> | you can use nix-as-an-environment-manager with linux or os x |
| 19:48:32 | <tomsmeding> | mshiraeeshi: are you building using cabal or using stack? |
| 19:48:38 | <mshiraeeshi> | cabal |
| 19:48:48 | <tomsmeding> | the cabal.project lists exact versions for loads of dependencies |
| 19:49:07 | <tomsmeding> | so kind of interesting that it still fails for you |
| 19:49:31 | <tomsmeding> | oh heh but it also has allow-newer on a bunch of packages, never mind |
| 19:49:47 | <sm> | (eg) |
| 19:49:48 | <sm> | the prepare script, I believe, which presumably uses cabal.project , but notice that file doesn't specify ghc version |
| 19:51:14 | <sm> | summary: it's not your fault, this project is not configured for reproducible building, so someone has to do that work |
| 19:51:27 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 19:51:35 | × | mc47 quits (~mc47@xmonad/TheMC47) (Ping timeout: 252 seconds) |
| 19:51:56 | <sm> | (well, unless the nix-shell route works, then maybe they get half marks) |
| 19:51:57 | <sclv> | personally i would start by bumping the base16-bytestring in that cabal.project to 1.0.2.0 |
| 19:52:00 | <sclv> | and seeing if that helped |
| 19:52:05 | <sm> | agreed! |
| 19:53:01 | <mshiraeeshi> | I tried bumping the base16-bytestring to 1.0.2.0, but then the same happened to other packages |
| 19:53:24 | <sclv> | well which other packages -- some others might need bumps too! |
| 19:54:38 | <mshiraeeshi> | basement, blaze-builder, base-compat |
| 19:55:47 | <mshiraeeshi> | perhaps I should rewrite "allow-newer" and fix their version by introducing some upper bounds |
| 19:56:20 | <sclv> | well did you try bumping the versions on some of those as well? |
| 19:56:44 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 19:57:08 | <mshiraeeshi> | no, you mean just incrementing their version numbers? |
| 19:57:35 | <sclv> | or removing the constraint entirely from the cabal.project file -- just commenting out the line |
| 19:57:44 | <sclv> | the lines in the cabal.project just insert constraints |
| 19:58:03 | <sclv> | (except for the allow-newer section, which is about lifting inherited constraints) |
| 19:58:41 | <sclv> | this whole thing was always super fragile |
| 19:59:01 | <sm> | aside: does cabal's allow-newer also allow older, as in stack ? |
| 19:59:02 | <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 |
| 19:59:11 | <sclv> | sm: not afaik |
| 19:59:42 | <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 |
| 20:00:06 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 20:00:35 | <texasmynsted> | sm: thank you :-) |
| 20:00:38 | <sclv> | like i would almost try to comment out the entire allow-newer, repoistory, and constraints sections |
| 20:00:39 | slac14257 | is now known as slack1256 |
| 20:00:58 | <sclv> | and try to see what if anything i needed to put back, on an extremely case by case basis |
| 20:01:33 | <sm> | texasmynsted: np :) |
| 20:02:28 | × | _ht quits (~quassel@231-169-21-31.ftth.glasoperator.nl) (Remote host closed the connection) |
| 20:04:02 | <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. |
| 20:04:14 | <dminuoso> | If I tend to the pictures with JuicyPixel they appear fine. |
| 20:04:23 | <dminuoso> | No clue what imagemagick does there |
| 20:07:59 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 20:08:36 | × | coot quits (~coot@213.134.190.95) (Quit: coot) |
| 20:19:34 | × | mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 20:24:55 | → | slac67882 joins (~slack1256@186.11.63.14) |
| 20:27:09 | × | slack1256 quits (~slack1256@191.126.227.91) (Ping timeout: 256 seconds) |
| 20:29:51 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 20:37:32 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 20:38:20 | × | zincy quits (~zincy@2a00:23c8:970c:4801:18b4:9d3:33e8:26e3) (Remote host closed the connection) |
| 20:45:27 | × | Nux32 quits (~Nux@92.139.200.146.dyn.plus.net) (Quit: Client closed) |
| 20:48:27 | × | mikoto-chan quits (~mikoto-ch@213.177.151.239) (Ping timeout: 265 seconds) |
| 20:52:11 | → | son0p joins (~ff@181.136.122.143) |
| 20:53:18 | × | phma quits (~phma@host-67-44-208-35.hnremote.net) (Read error: Connection reset by peer) |
| 20:53:35 | <tomsmeding> | dminuoso: like, IM output was somehow borked / not acceptable to streamdeck? |
| 20:54:14 | <dminuoso> | Yeah |
| 20:54:27 | → | phma joins (phma@2001:5b0:210d:5458:5d56:889b:9db6:9f82) |
| 20:54:35 | <dminuoso> | But its essentially impossible to tell why |
| 20:54:53 | <dminuoso> | Short of having the source code of the streamdeck or perhaps some magical debugging tools from their engineering team |
| 20:55:00 | <tomsmeding> | no discernable difference like "full colour instead of palette-able", or "has transparency" |
| 20:55:51 | <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. |
| 20:56:10 | <dminuoso> | *shrugs* |
| 20:56:37 | <tomsmeding> | O.o |
| 20:57:12 | <dminuoso> | And it was not a transport encoding bug, that is definitely done correctly |
| 20:57:12 | <EvanR> | seems like a pretty standard effect |
| 20:57:15 | <dminuoso> | heh |
| 20:57:21 | <tomsmeding> | if that only happens on the streamdeck, not if you open the image normally on a computer, then yeah streamdeck needs a drink |
| 20:57:46 | <dminuoso> | well its really hard to say whats going on with proprietary hardware you have no documentation for. |
| 20:58:35 | <dminuoso> | Next up, I need to round those corners. Mission critical you know. |
| 20:59:23 | <tomsmeding> | yes that is important |
| 20:59:58 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 21:00:26 | <Bulby[m]> | https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/Control-Applicative-Combinators.html why are applicatives more prone to memory leaks |
| 21:02:19 | × | abrar_ quits (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) (Quit: WeeChat 3.3) |
| 21:03:01 | → | abrar joins (~abrar@static-108-2-152-54.phlapa.fios.verizon.net) |
| 21:03:49 | <dminuoso> | But jokes aside, I dont care for figuring out the silly math of rounding these corners right now,. |
| 21:04:14 | <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. |
| 21:05:57 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 21:06:13 | <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? |
| 21:06:56 | <dminuoso> | They are useful for similar reasons that functions are useful. It's nice to map things to things. |
| 21:07:17 | <tomsmeding> | dminuoso: rounding corners with or without anti-aliasing? If with anti-aliasing, what is the RGB subpixel layout of your screen :> |
| 21:07:44 | <dminuoso> | tomsmeding: Good question! Given that I want to do text rendering ontop, sub pixel hinting is going to be an important thing. |
| 21:07:53 | <dminuoso> | Guess I better buy a microscope |
| 21:07:57 | <tomsmeding> | :D |
| 21:08:18 | <dminuoso> | But seriously, is there some thing to render fonts onto juicypixel images?> |
| 21:08:41 | <tomsmeding> | that would need bindings to some kind of serious text rendering library |
| 21:08:48 | <tomsmeding> | text rendering is Hard |
| 21:08:56 | <dminuoso> | It cant be harder than caching. |
| 21:09:36 | → | slack1256 joins (~slack1256@191.126.227.67) |
| 21:09:38 | <tomsmeding> | X doubt https://arstechnica.com/gadgets/2013/08/rendering-bug-crashes-os-x-and-ios-apps-with-string-of-arabic-characters/ |
| 21:09:40 | <dminuoso> | But perhaps once again, I might as well go the easy route and generate them via imagemagick. |
| 21:09:52 | <dminuoso> | tomsmeding: to be fair, I dont want font rendering in a damn browser. |
| 21:09:53 | × | alp_ quits (~alp@user/alp) (Ping timeout: 252 seconds) |
| 21:10:08 | <EvanR> | your best bet is to get a screen with display tech matching your desired shape exactly |
| 21:10:15 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 21:10:23 | <tomsmeding> | dminuoso: which browser are you referring to? The thing I linked was a bug in CoreText, a system library |
| 21:11:14 | <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. |
| 21:11:34 | <EvanR> | if you only need 1 resolution on 1 DPI with 1 typeface yeah |
| 21:11:35 | <dminuoso> | If you constrain yourself to something like German or English, I think I can be optimistic that text rendering is mostly harmless |
| 21:11:40 | <tomsmeding> | dminuoso: then it's certainly easier, but still, hinting? |
| 21:11:48 | <tomsmeding> | harmless sure |
| 21:11:56 | × | slac67882 quits (~slack1256@186.11.63.14) (Ping timeout: 260 seconds) |
| 21:12:23 | <EvanR> | hinting itself considered harmful, as a term |
| 21:12:33 | <EvanR> | no one agrees on what it does or is |
| 21:12:35 | <tomsmeding> | also anti-aliasing (which for non-ugly font rendering should really be including adapting to subpixel layout) |
| 21:12:49 | <tomsmeding> | EvanR: but for small text it suddenly becomes essential |
| 21:12:52 | <tomsmeding> | somehow |
| 21:12:58 | <EvanR> | whatever it is, it's necessary |
| 21:13:05 | <EvanR> | engineering 101 |
| 21:13:48 | <EvanR> | basically it's come to mean, make text look subjectively better, without regard to context, viewer, or constraints |
| 21:14:16 | <dminuoso> | I guess it becomes a question of convenience |
| 21:14:17 | <EvanR> | which turns out to not make sense |
| 21:14:27 | × | Pickchea quits (~private@user/pickchea) (Quit: Leaving) |
| 21:14:31 | <dminuoso> | At the end I dont really need font rendering, as I could do this in another tool. |
| 21:16:34 | × | littlebobeep quits (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 21:20:03 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 21:21:16 | × | acidjnk_new quits (~acidjnk@p200300d0c7068b99c0183a275a5d2a59.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 21:21:25 | <mshiraeeshi> | update on me trying to build https://github.com/well-typed/memory-usage-zurihac-2021 |
| 21:21:43 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 21:22:07 | <mshiraeeshi> | I've commented out a lot of constraints in cabal.project file based on trial and error |
| 21:22:32 | <mshiraeeshi> | and now I'm stuck on aeson and semigroups |
| 21:23:09 | <mshiraeeshi> | semigroups removed Data.Semigroup.Option after version 18 |
| 21:23:43 | <tomsmeding> | mshiraeeshi: Option is in base-compat-batteries:Data.Semigroup.Compat, which is included in the dep list |
| 21:23:50 | <tomsmeding> | also s/Option/Maybe/g |
| 21:24:07 | <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 |
| 21:24:42 | → | littlebobeep joins (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 21:24:53 | <mshiraeeshi> | but if I build it with semigroups-0.18, I get this error: https://paste.tomsmeding.com/BV60myvJ |
| 21:25:21 | <mshiraeeshi> | (a lot of Ambifuous occurence of 'Semigroup' in src/Data/Semigroup.hs) |
| 21:26:23 | <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 |
| 21:26:28 | <mshiraeeshi> | tomsmeding: should I try to constrain aeson to a newer version? |
| 21:26:39 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 21:26:44 | <tomsmeding> | mshiraeeshi: aeson 2.0 has a bunch of breaking changes, you can try but is unlikely to work |
| 21:27:22 | <mshiraeeshi> | hmm, okay, let's try |
| 21:32:14 | × | slack1256 quits (~slack1256@191.126.227.67) (Ping timeout: 252 seconds) |
| 21:33:42 | <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. |
| 21:34:44 | <Bulby[m]> | interesting |
| 21:35:11 | <Bulby[m]> | is there a polysemy megaparsec lib |
| 21:36:39 | <sclv> | for example look at manyTill in the monad version |
| 21:36:41 | <sclv> | https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/src/Control.Monad.Combinators.html#manyTill_ |
| 21:36:53 | <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 |
| 21:36:58 | <sclv> | compare that to the applicative version |
| 21:36:58 | <sclv> | https://hackage.haskell.org/package/parser-combinators-1.3.0/docs/src/Control.Applicative.Combinators.html#manyTill |
| 21:37:07 | <sclv> | tomsmeding: its badly written |
| 21:37:29 | <sclv> | the latter is cleaner but one can unwind it and see why it might be less efficient |
| 21:42:37 | <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. |
| 21:42:50 | × | kenran quits (~kenran@200116b82b161c00019eb3ff6945071f.dip.versatel-1u1.de) (Quit: WeeChat info:version) |
| 21:43:00 | <sclv> | so expressivity is not the point but rather the thing that explains the performance issues being referred to |
| 21:43:35 | <tomsmeding> | right, that makes sense |
| 21:43:58 | → | odnes joins (~odnes@5-203-160-39.pat.nym.cosmote.net) |
| 21:44:11 | <zzz> | i'm not sure i'm understanding the concept of type families |
| 21:46:41 | <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/ |
| 21:47:11 | <mshiraeeshi> | there's a section called "Type families are functions from types to types" |
| 21:47:12 | <Bulby[m]> | I love type families they let me make monsters like higher kinded data |
| 21:47:47 | <zzz> | mshiraeeshi: thaks |
| 21:48:49 | <mshiraeeshi> | zzz: also "An Introduction to Type Level Programming" https://rebeccaskinner.net/posts/2021-08-25-introduction-to-type-level-programming.html |
| 21:52:08 | <mshiraeeshi> | zzz: also "Functional Dependencies" https://www.fpcomplete.com/haskell/tutorial/fundeps/ (there's a short section called "Type families") |
| 21:52:12 | <EvanR> | using type (synonym) families you can make MyFam Bool evaluate to Int during type checking |
| 21:52:34 | <EvanR> | or vice versa |
| 21:52:43 | → | xaotuk joins (~sasha@net137-36-245-109.mbb.telenor.rs) |
| 21:53:15 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 21:53:50 | × | jgeerds quits (~jgeerds@d53604b0.access.ecotel.net) (Ping timeout: 240 seconds) |
| 21:53:59 | × | Henson quits (~kvirc@107-179-133-201.cpe.teksavvy.com) (Ping timeout: 246 seconds) |
| 21:54:02 | <mshiraeeshi> | the most easy to understand is the use case described in "Functional Dependencies" |
| 21:54:37 | <mshiraeeshi> | the case when you have a Reader and the associated type Env which means the Environment which the reader reads |
| 21:55:01 | <mshiraeeshi> | in case of PersonReader the environment is Person |
| 21:55:15 | <mshiraeeshi> | in case of Reader env, the environment is env |
| 21:55:54 | <zzz> | i'm starting with that. thanks |
| 21:56:38 | → | alx741 joins (~alx741@host-181-198-243-150.netlife.ec) |
| 21:58:26 | → | harveypwca joins (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 22:02:08 | <mshiraeeshi> | tomsmeding: "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" |
| 22:02:34 | × | noteness_ quits (~noteness@user/noteness) (Ping timeout: 240 seconds) |
| 22:02:42 | <mshiraeeshi> | I did that, I didn't even have to remove Option instances for some reason, now it gives me other errors |
| 22:03:22 | <mshiraeeshi> | cannot build attoparsec: expects Word8# but gets Word# https://paste.tomsmeding.com/UBdsvfbw |
| 22:03:25 | → | noteness joins (~noteness@user/noteness) |
| 22:03:34 | × | gehmehgeh quits (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 22:03:34 | × | stiell_ quits (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 240 seconds) |
| 22:04:00 | <mshiraeeshi> | cannot build base-compat: 'Option' is not in scope https://paste.tomsmeding.com/Yz5oO5rk |
| 22:04:04 | × | chexum quits (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds) |
| 22:04:04 | × | tusko quits (~yeurt@user/tusko) (Ping timeout: 240 seconds) |
| 22:04:20 | × | MoC quits (~moc@user/moc) (Quit: Konversation terminated!) |
| 22:04:32 | × | odnes quits (~odnes@5-203-160-39.pat.nym.cosmote.net) (Remote host closed the connection) |
| 22:04:34 | × | littlebobeep quits (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 240 seconds) |
| 22:04:35 | → | chexum joins (~quassel@gateway/tor-sasl/chexum) |
| 22:04:50 | × | alx741 quits (~alx741@host-181-198-243-150.netlife.ec) (Ping timeout: 240 seconds) |
| 22:05:34 | → | tusko joins (~yeurt@user/tusko) |
| 22:05:43 | × | michalz quits (~michalz@185.246.204.125) (Remote host closed the connection) |
| 22:05:46 | → | littlebobeep joins (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 22:05:59 | → | gehmehgeh joins (~user@user/gehmehgeh) |
| 22:07:09 | × | romesrf quits (~romes@185.5.8.134) (Quit: WeeChat 3.4.1) |
| 22:07:21 | → | stiell_ joins (~stiell@gateway/tor-sasl/stiell) |
| 22:09:49 | → | alx741 joins (~alx741@host-181-198-243-150.netlife.ec) |
| 22:11:06 | → | AlexNoo_ joins (~AlexNoo@178.34.163.35) |
| 22:11:23 | <mshiraeeshi> | but attoparsec and base-compat are already commented out in "constraints" section in cabal.project |
| 22:11:23 | <mshiraeeshi> | so I don't know what to do about it |
| 22:11:24 | × | mshiraeeshi quits (~shiraeesh@109.166.56.211) (Remote host closed the connection) |
| 22:11:41 | → | mshiraeeshi joins (~shiraeesh@109.166.56.211) |
| 22:12:53 | → | Henson joins (~kvirc@107-179-133-201.cpe.teksavvy.com) |
| 22:13:19 | <sclv> | i think you should strip out the allow-newers |
| 22:13:41 | <mshiraeeshi> | I tried that, cabal couldn't resolve dependencies |
| 22:13:41 | <sclv> | they're letting bad plans go thru (and were there to allow patched versions of existing libs from head.hackage work) |
| 22:13:44 | <sclv> | right |
| 22:13:53 | <sclv> | it is correct that cabal can't resolve dependencies |
| 22:14:04 | <sclv> | that's a problem thats often solvable |
| 22:14:10 | × | AlexNoo quits (~AlexNoo@178.34.163.35) (Ping timeout: 240 seconds) |
| 22:14:26 | <sclv> | the allow-newers allow it to "resolve" deps in a way that doesn't actually build, as you've witnessed |
| 22:16:14 | <sclv> | i'm sorry you're running into so much trouble here. its really clearly something that was intended as a snapshot to work on a very specific state of the world in dev, not as a "timeless" stable repo :-/ |
| 22:16:23 | <mshiraeeshi> | there's a conflict between aeson and base |
| 22:16:45 | <mshiraeeshi> | https://paste.tomsmeding.com/nTHzWOGU |
| 22:17:25 | <mshiraeeshi> | you mean it was only intended to work at the day of the presentation? |
| 22:17:32 | <mshiraeeshi> | that's too bad |
| 22:17:41 | <sclv> | basically -- it involves the innately unstable head.hackage |
| 22:17:52 | <sclv> | and a specific snapshot of a development version of ghc |
| 22:18:09 | <sclv> | i'm sure its salvagable but it wasn't done in such a way that it makes it easy for you or anyone else to do so |
| 22:19:02 | <zzz> | how can i make an instance of show that prints lazily like List does? |
| 22:19:51 | <zzz> | s/show/Show |
| 22:20:03 | <sclv> | the fact that aeson chose to not have compat releases between the old stuff and the new stuff doesn't help |
| 22:20:46 | <sclv> | you _might_ be able to get somewhere with "allow-newer: aeson:base" but who knows |
| 22:21:21 | <sclv> | you definitely don't want "allow-newer: base" in general |
| 22:22:19 | <mshiraeeshi> | still the conflict between aeson and base even with "allow-newer: aeson:base" |
| 22:22:33 | <yushyin> | you could try an older toolchain with older base and older ghc-prim |
| 22:23:25 | <mshiraeeshi> | you mean trying with older ghc? |
| 22:23:32 | <yushyin> | yup |
| 22:23:59 | <yushyin> | e.g. 8.10.7 |
| 22:24:09 | <sclv> | i think that this demo is specifically designed for features of the latest ghc |
| 22:24:15 | <mshiraeeshi> | tried with ghc-9.0.2, there's a conflict between base, cereal, chatter |
| 22:24:20 | <sclv> | https://github.com/well-typed/memory-usage-zurihac-2021 |
| 22:24:38 | <mshiraeeshi> | same with 8.10.7 |
| 22:25:01 | <sclv> | mshiraeeshi: you could try to vendor aeson i suppose and change its base constraint manually |
| 22:25:24 | <mshiraeeshi> | oh yeah, I forgot about that, they mention in the readme that it requires ghc-9.2 |
| 22:25:51 | × | alx741 quits (~alx741@host-181-198-243-150.netlife.ec) (Ping timeout: 276 seconds) |
| 22:26:38 | <maerwald> | https://cabal.readthedocs.io/en/3.6/cabal-project.html?highlight=optional-packages#cfg-field-optional-packages |
| 22:27:40 | → | zebrag joins (~chris@user/zebrag) |
| 22:28:02 | × | gehmehgeh quits (~user@user/gehmehgeh) (Quit: Leaving) |
| 22:28:35 | <geekosaur> | zzz, a user-defined list type Show-s lazily for me. are you trying to lazily show a strict type? I suspect that's doomed |
| 22:30:47 | <yushyin> | how did that even work? ghc-9.2.1 ships ghc-prim 8.0 but the project wants aeson ==1.5.6.0 which has dep on ghc-prim with (>=0.2 && <0.8)? |
| 22:31:25 | <geekosaur> | if I recall the start of this conversation, it was actually using alpha4 |
| 22:31:39 | <geekosaur> | which may mean ghc-prim hadn't been bumped yet |
| 22:32:28 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 22:33:03 | <yushyin> | ah yes, that could be it |
| 22:33:27 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 22:36:17 | → | ub1 joins (~Thunderbi@p548c8d44.dip0.t-ipconnect.de) |
| 22:37:13 | <zzz> | geekosaur: data List a = a ::: List deriving Show ; list x = x ::: list x -- print $ list () |
| 22:37:20 | × | ub quits (~Thunderbi@p200300ecdf15880b09d618bc8a498343.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 22:37:21 | <zzz> | what am i doing wrong geekosaur? |
| 22:37:48 | <zzz> | aside from missing an a in there |
| 22:37:52 | <geekosaur> | you have no base case |
| 22:38:05 | <geekosaur> | or equivently no end of list marker |
| 22:38:22 | <zzz> | i ommited it, but does that make a difference? |
| 22:38:35 | ub1 | is now known as ub |
| 22:38:39 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 265 seconds) |
| 22:38:40 | <geekosaur> | a list with no end is a stream, not a list |
| 22:39:11 | <geekosaur> | > Cons 5 (Cons 3 (Cons 2 undefined)) -- lazy |
| 22:39:12 | <lambdabot> | Cons 5 (Cons 3 (Cons 2 *Exception: Prelude.undefined |
| 22:39:30 | <geekosaur> | > SCons 5 (SCons 3 (SCons 2 undefined)) |
| 22:39:32 | <lambdabot> | *Exception: Prelude.undefined |
| 22:39:50 | <geekosaur> | that was the "same" List but with a strict spine |
| 22:39:59 | <zzz> | ok |
| 22:40:02 | <zzz> | still |
| 22:40:20 | <zzz> | data List a = a ::: List a | Nil deriving Show |
| 22:40:28 | <zzz> | still doesn't print lazily |
| 22:40:33 | <geekosaur> | ( data List a = Nil | Cons a (List a), vs. data SList a = SNil | SCons a !(SList a) ) |
| 22:41:04 | <geekosaur> | @undef |
| 22:41:05 | <lambdabot> | Undefined. |
| 22:41:28 | <geekosaur> | @let data List a = Nil | a ::: List a deriving Show |
| 22:41:29 | <lambdabot> | Defined. |
| 22:41:43 | <geekosaur> | @undef |
| 22:41:43 | <lambdabot> | Undefined. |
| 22:41:58 | <geekosaur> | @let data List a = Nil | a ::: List a deriving Show; infixr 6 ::: |
| 22:41:59 | <lambdabot> | Defined. |
| 22:42:11 | <geekosaur> | > 5 ::: 3 ::: 2 ::: undefined |
| 22:42:14 | <lambdabot> | 5 ::: (3 ::: (2 ::: *Exception: Prelude.undefined |
| 22:42:19 | <geekosaur> | looks lazy to me |
| 22:42:24 | <zzz> | hmm |
| 22:49:35 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 22:52:10 | × | szkl quits (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 22:52:20 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 22:52:54 | → | yauhsien joins (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) |
| 22:53:22 | → | stackdroid18 joins (14094@user/stackdroid) |
| 22:54:25 | × | mjs2600 quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 22:55:27 | <zzz> | > [1,2,undefined] |
| 22:55:29 | <lambdabot> | [1,2,*Exception: Prelude.undefined |
| 22:55:41 | <zzz> | ok something's wrong with my ghci |
| 22:56:01 | → | mjs2600 joins (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 22:57:29 | × | yauhsien quits (~yauhsien@61-231-24-3.dynamic-ip.hinet.net) (Ping timeout: 252 seconds) |
| 22:58:43 | <zzz> | *facepalm* i had -XOverloadedLists on my .ghci |
| 22:58:57 | <zzz> | i think that was it |
| 23:00:50 | × | xaotuk quits (~sasha@net137-36-245-109.mbb.telenor.rs) (Ping timeout: 240 seconds) |
| 23:01:59 | <texasmynsted> | Anybody created or know of some examples of _small_ standalone Haskell executables that use pandoc as a module/lib. A filter feels too big for a single tag. |
| 23:02:56 | × | mjs2600 quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 23:04:39 | → | mjs2600 joins (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 23:11:47 | × | mjs2600 quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 252 seconds) |
| 23:14:00 | <sm> | texasmynsted: how do you mean small ? like hakyll ? |
| 23:14:45 | × | Hash quits (~Hash@hey.howstoned.ru) (Quit: ZNC - https://znc.in) |
| 23:14:48 | → | mjs2600 joins (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 23:15:32 | <sm> | pandoc is such a heavy dependency, I go out of my way to use the binary (and maybe lua plugins) if at all possible |
| 23:16:51 | → | andrey joins (~andrey@p200300dbcf003200efdd83e940d7d35b.dip0.t-ipconnect.de) |
| 23:17:37 | <geekosaur> | hm. we used to have one but it's been rewritten |
| 23:19:02 | AlexNoo_ | is now known as AlexNoo |
| 23:19:48 | × | andrey__ quits (~andrey@p200300dbcf15e00051e3a882b5958800.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 23:21:08 | → | alp_ joins (~alp@user/alp) |
| 23:22:11 | <geekosaur> | https://github.com/xmonad/xmonad/blob/66d22417035c1e7e9ca9c9f7692b9ce5ba2991b4/util/GenerateManpage.hs |
| 23:22:57 | → | jargon joins (~jargon@174-22-206-112.phnx.qwest.net) |
| 23:24:28 | × | mjs2600 quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 260 seconds) |
| 23:26:40 | → | Hash joins (~Hash@hey.howstoned.ru) |
| 23:31:00 | × | Hash quits (~Hash@hey.howstoned.ru) (Client Quit) |
| 23:34:10 | × | dhil quits (~dhil@cpc103052-sgyl39-2-0-cust260.18-2.cable.virginm.net) (Ping timeout: 240 seconds) |
| 23:38:38 | <texasmynsted> | like MUCH smaller than hakyll. I love hakyll but it is not small. |
| 23:40:14 | <texasmynsted> | I mean small like maybe it would be a good project for me to just build a parsec parser to parse the markdown image tag, and transform it to an HTML tag directly, leaving pandoc out. |
| 23:40:19 | × | machinedgod quits (~machinedg@24.105.81.50) (Ping timeout: 260 seconds) |
| 23:41:06 | <texasmynsted> | geekosaur: ooh that is neat. |
| 23:42:20 | <texasmynsted> | I have so much to learn, but I just want to direct my efforts to result in the smallest _haskell_ solution possible. |
| 23:43:33 | × | harveypwca quits (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 23:44:09 | <texasmynsted> | Here is a gist https://github.com/xmonad/xmonad/blob/66d22417035c1e7e9ca9c9f7692b9ce5ba2991b4/util/GenerateManpage.hs |
| 23:44:25 | <texasmynsted> | sigh. Sorry pastebord did not update |
| 23:44:33 | <texasmynsted> | https://gist.github.com/mmynsted/4478021ce828979c8a4d016dd6dff609 |
| 23:45:23 | <texasmynsted> | sometimes writing stuff out like that leads me to a solution. shrug |
| 23:47:15 | → | kitty1 joins (~kitty@096-039-147-043.res.spectrum.com) |
| 23:48:06 | <sm> | I'm not quite clear on the question/problem in the paste.. you could package it as an easy shell script ? |
| 23:49:57 | → | mjs2600 joins (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 23:52:02 | <dibblego> | I wrote my own "trimmed down syntax tree" once. I wrote practice exams in it, then went out to different formats. Quick hack. |
| 23:55:59 | <texasmynsted> | shell script would work sure. |
| 23:56:33 | → | Hash joins (~Hash@hey.howstoned.ru) |
| 23:56:39 | <texasmynsted> | I plan to call it from a vim key binding and also a hammerspoon or other binding so I can do the same from outside vim. |
| 23:57:35 | <texasmynsted> | My goal is to make something small and learn how to be comfortable with small haskell things. I am trying to replace bash/regex with haskell. |
| 23:57:58 | <sm> | ah, cool |
| 23:58:11 | <sm> | have you considered a stack script ? |
| 23:58:11 | <texasmynsted> | quick hack for you dibblego Hehe |
| 23:58:23 | <sm> | that's haskell, but a single file |
| 23:58:42 | <texasmynsted> | Can I do that with cabal? |
| 23:58:48 | <texasmynsted> | I am not sure what a stack script is. |
| 23:59:00 | <EvanR> | cabal scripts are cool |
| 23:59:03 | <sm> | yes, it's not quite as good.but the same idea |
| 23:59:11 | <texasmynsted> | I know what stack is, but I use cabal rather than stack. |
| 23:59:20 | <dibblego> | yeah I needed to study, not write code |
All times are in UTC on 2022-05-12.